commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Libbrecht <p...@activemath.org>
Subject Re: [Jelly][RT] The purpose of the JellyContext
Date Tue, 23 Dec 2003 14:38:47 GMT
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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message