|
From: Robert Z. <ro...@sc...> - 2004-02-25 16:00:30
|
ri...@us... wrote: >>We need to make eledge more scalable, but find a balance with the=20 >> =20 >> >flexibility. The proposal is that we >use the struts framework, with=20 >velocity templates for the view layer, to make the application more=20 > =20 > >>scalable and maintainable. Some serious thought will need to be put int= o=20 >> =20 >> >the design to ensure a high >degree of flexibility in the end product.=20 >Any thoughts? ;) > >Agree completely with your assert. About Struts + Velocity I've found=20 >that stxx (an SF project) is a very valuable piece of the cake, it sits=20 >at the top of struts and take control, if we want to, for transforming=20 >xml data taken from the bussines layer with xsl templates at our choice=20 >(we can , for example, determine the user agent for selecting xsl=20 >templates). =20 >The good new is that it adds support for velocity too in the struts=20 >framework. > > =20 > Huh. Interesting. I took a quick look at stxx just now. I'll have to=20 look at it more in depth in a bit. I was originally just planning on using the "velocity tools"=20 extensions to velocity, which add support for struts, including all of struts 1.1 features (with=20 the newest release), including tiles, validation, and more. What do you see are the benefits=20 to using stxx vs. using "straight" struts+velocity+velocity-tools? >> 2) Somewhere in all our refactoringg, this needs to be done as wel= l.=20 >> =20 >> >We need to determine who is >going to work on what aspect. > >I'm waiting for Navigo release as you now (they have said april) to take= =20 >it, plug into EJOSA structure and eledgeizing its UI, but i'm a little=20 >low of time because a Portal project i'm working for until june. > =20 > April, eh? Ok. Well, I'll let you play with the assessment portion, then. I know that's the area that Fred Weber was most interested in... perhaps=20 you could "get together" with him on this... >=20 > =20 > >>eledge, etc.) By creating appropriate interfaces and API's, >>we can make extension much easier; in the future, to add a type >>assignment, for example, would become much easier, and would "fit" >>into the framework that eledge would already be providing. >> =20 >> > >I suggest that you inspire yourself in OKI interfaces. Maybe they're=20 >going to turn to a standard and its good to leverage their thoughts and=20 >eventually make Eledge OKI compliant in the future. It's not neccesary t= o=20 >=93copy=94 their writed methods cause we can make EledgeOKIAdaptors but = it=20 >could be good to understand and agree if convenient to their view of use= =20 >cases. > > =20 > I plan on dling the entire OKI interface specs and going through them in=20 detail. >>grade/rubric calculation. Other ideas, such as tracking >>student access, fall within IMS/SCORMS compliance, as well as here. >> =20 >> > >Look at Navigo code, surprisingly (not at all!) they are using stxx to=20 >manage native ims/scorm files, they can take that xml and transform it=20 >with xsl templates for rendering. It's good to take xml without=20 >transforming it (not even to a object model), the thing I don't like is=20 >the eventual growing complexity of xsl templates but...it's really good=20 >to have this working examples. > > =20 > I see. So... they are using stxx to go straight from IMS xml to xslt? I'm not sure I fully understand... whe you say "that xml" are you=20 referring to information created by their assessment system, stored in IMS compliant=20 xml files? Or are you referring directly to IMS xml specifications? I'll have to=20 look over the navigo project some more. After going through the OKI information, I'll be putting together 2 sets = of tcm diagrams (if you don't have tcm, http://wwwhome.cs.utwente.nl/~tcm/ is the place to get it; on windows, it requires cygwin). The first set will be "where we are" (ie, a general digram depicting classes, relationships, data/event flow, etc. In general, it will be=20 done in a struts-centric way... that is to say, to take eledge as it stands now and put it into struts, here are the actions, actionforms, and 'screens'=20 that we'll need). This first set is primarily to help everyone understand exactly where we=20 are at. (If you don't want to install tcm, I can make it available as an image=20 file or perhaps a pdf. I may also make this available via the docs page on sourceforge) The second set will reflect more of "where we want to go". I hope to get=20 a lot of input from you all on this set, so please note that whatever I send out at=20 first is, at best, a rough draft. This one will likely also be struts-centric; don't expect a true=20 UML diagram. ;) (I will, however, provide a key for understanding relationships, etc.) Robert |