[Eledge-developers] RE: Eledge-developers digest, improving scalability

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

I agree that we need to find a way to make Eledge more scalable.  Going to
Struts + Velocity is probably a good idea, but Robert and Richard know much
more about this technical end than I.  One of the simple things that we can
do is to use existing resources more efficiently.  For example, when I
originally created some of the servlets I did not fully understand issues of
JDBC Connections, Statements and ResultSets, so I created many more
Connection objects than was really required.  We can economize on this by
reusing Connection objects, and we can utilize Connection pools.  Mainly,
this requires setting up some parameters in Tomcat, and going through the
code to make certain that every Connection object is explicitly closed()
when it is no longer needed by the user (and is therefore freed to the pool
for other users).  I understand that relying on the Java garbage collector
to do this is not sufficient.

Chuck

-----Original Message-----
From: ele...@li...
[mailto:ele...@li...]On Behalf Of
ele...@li...
Sent: Wednesday, February 25, 2004 9:02 PM
To: ele...@li...
Subject: Eledge-developers digest, Vol 1 #3 - 2 msgs

Send Eledge-developers mailing list submissions to
	ele...@li...

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/eledge-developers
or, via email, send a message with subject or body 'help' to
	ele...@li...

You can reach the person managing the list at
	ele...@li...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Eledge-developers digest..."

Today's Topics:

   1. Re: Eledge Goals (ri...@us...)
   2. Re: Eledge Goals (Robert Zeigler)

--__--__--

Message: 1
From: ri...@us...
Date: Wed, 25 Feb 2004 08:51:41 GMT
Subject: Re: [Eledge-developers] Eledge Goals
To: ele...@li...
Reply-To: ele...@li...

>We need to make eledge more scalable, but find a balance with the=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
>scalable and maintainable. Some serious thought will need to be put int=
o=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 =

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 =

(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.

>      2) Somewhere in all our refactoringg, this needs to be done as we=
ll.=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
>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.

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 =

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.

>grade/rubric calculation. Other ideas, such as tracking
>student access, fall within IMS/SCORMS compliance, as well as here.

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 =

the eventual growing complexity of xsl templates but...it's really good =

to have this working examples.

--__--__--

Message: 2
Date: Wed, 25 Feb 2004 08:51:16 -0700
From: Robert Zeigler <ro...@sc...>
To: ele...@li...
Subject: Re: [Eledge-developers] Eledge Goals
Reply-To: ele...@li...

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

--__--__--

_______________________________________________
Eledge-developers mailing list
Ele...@li...
https://lists.sourceforge.net/lists/listinfo/eledge-developers

End of Eledge-developers Digest