Re: [Eledge-developers] Eledge Goals

[Robert Z. <ro...@sc...>]

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