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