> From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]] > > Hi Ovidiu, > > I'm not sure whether you are following this discussion or not, but I'm > about to refactor XScript in the following direction: > > 1. Do not store variable scopes in the XScriptManager, but as > attribute > of Context, Session, Request, or in the page itself (for page scope). > Thus, will be no (or less) memory leaks (session expires -> all > variables are cleaned up automatically). > > 2. Add request scope. > > 3. Move to DOM for variable storage. This will allow adding xpath > functionality to the logicsheet without extra re-parsing.
Are going to use JXPath as XPath engine? This will allow to store variables either as DOM or JavaBeans. I don't know much about the Xscript, but your proposal looks like the same thing from JSTL (Java Standart Tag Library). Adding an expression language to all the logicsheets that require access to data in page, request, session or app contexts would be an excellent enhancement. Does this make sense in context of XScript? Konstantin > > 4. Add XScriptSource, to allow usage of xscript variables in the > sitemap. Something similar to: > <map:generate src="xscript:session:my-doc#chapter[2]"/> > <map:generate src="xscript:first:my-style"/> > > 5. Think about making single variable storage for xscript and > webapps.session (I would like to get Carsten's comment on this also). > > Before I start modifying the code, I would like to hear your > opinion on > the decisions I took. > > > Regards, > Vadim > > > > > From: Per Kreipke [mailto:[EMAIL PROTECTED]] > > > > > > A couple of questions about XScript 'language': > > > > > > > > - I can't find much (ok, any) documentation about the history of > this > > > > component. What was/is it's purpose? I like it but it would be > nice to > > > > understand its creators' purposes. > > > > > > I am no creator, won't comment. > > > > > > > > > > - the XScriptObjectInlineXML > > > > > > You meant XScriptObjectFromURL > > > > Doh. > > > > > > object doesn't use a Resolver so it only seems > > > > to support the http protocol. Is that an oversight or by design? > > > > > > Xscript wasn't maintained well; I already fixed several > issues with > it. > > > This is just one more. > > > > Ok. > > > > > > - this seems similar to the abilities of some of the sunShine > code. > > > > > > Exactly. It overlaps with webapps.session a bit, although it is > > > different. Session context can be accessed / manipulated in > > > transformation stage only, while xscript works in > generation stage, > as > > > logicsheet. > > > > > > > > > > Does SunShine use XScript (not from my searches)? > > > > > > No. They are completely independent (atm). > > > > > > > > > > Is one or the other the > > > > prefered method for manipulating XML snippets? > > > > > > I'm thinking on unifying these two approaches; I'd like > to make them > > > share common variable space. Then, it will be two approaches, and > > > difference will be in a stage - generation vs transformation, same > > > difference we see in SQLTransformer vs ESQL logicsheet. > > > > I agree. That was going to be my next email, just setting the stage > :-) > > > > Per > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
