cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Per Kreipke" <...@onclave.com>
Subject RE: [Q] XScript...
Date Thu, 25 Jul 2002 16:01:39 GMT
Vadim,

I like your suggestions.

I have a concern that the refactoring may not apply to 2.0.3 (or 2.0.4).

Can some of the changes be made to 2.0.3 (esp #1 and #3 [where vars are
stored and their format]) and then the rest made in 2.1?

Per

> > From: Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net]
> >
> > 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:per@onclave.com]
> > >
> > > > > 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: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message