commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert <>
Subject Re: [Jelly][RT] The purpose of the JellyContext
Date Tue, 23 Dec 2003 22:37:12 GMT
my .02 on this one. There is an issue in Jira about moving the variable 
storage into an extensible Scope mechanism. I have a solution to this 
and asked several questions about this some time ago, but nothing was 
every done about it.

I do agree that with the context doing so much it can make things 
confusing however.


Paul Libbrecht wrote:
> Carsten,
> I sort of agree with your consideration for the mix but things aren't easy.
> I wouldn't accept something where you hand in an inputstream to be the 
> default one as relative-URL-resolution is needed.
> That same issue (namely knowing the system-id) is the bone that you 
> might bite into when trying to refactor.
> There's also an object called script which would be the best thing I 
> would consider to run jelly-scripts... whereas a context should only 
> exist as a variable storage.
> Can you try to make it along such things ?
> Such a patch has to be strongly discussed I think.
> Paul
> On 23-Dec-03, at 13:12 Uhr, Carsten Ziegeler wrote:
>> I just started to look at Jelly for using it as the main template
>> engine within Cocoon and was a little bit surprised by the
>> JellyContext class.
>> But first, Jelly is really great and provides exactly the
>> extensability I need.
>> So, back to the theme. I think the JellyContext is the context
>> the script(executed template) runs in. This is proved by the
>> run(JellyContext, XMLOutput) method of the Script interface.
>> Unfortunately, the JellyContext does a lot more. It can actually
>> parse a script, resolve URIs etc. I think this is mixing concerns.
>> You have to create a JellyContext first in order to get a script
>> and can then run the script later on with another JellyContext.
>> So, I think separating the concerns would make things easier.
>> What do you think of creating a "Parser" (whatever you call it),
>> that gets all the compileXX and runXX methods from the JellyContext
>> and leave only the context handling at the JellyContext.
>> In addition, a compileXX/runXX method that can directly handle
>> an InputStream instead of a URL would be very great for Cocoon.
>> For compatibility, I would suggest to deprecate the methods
>> at the JellyContext and remove them in a later release.
>> If you're interested I can provide a patch.
>> Carsten
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message