You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Carsten Ziegeler <cz...@s-und-n.de> on 2003/12/23 13:12:26 UTC
[Jelly][RT] The purpose of the JellyContext
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
Re: [Jelly][RT] The purpose of the JellyContext
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Peter Royal wrote:
> On Dec 23, 2003, at 7:12 AM, 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.
>
> yea! i'm heavily using it in cocoon and it rocks!
>
Good to know :)
> > 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.
>
> I'd call it a 'ScriptLoader' or something, but I agree with the general
> idea. There are some bugs in the tracker that deal with relative URL's
> inside a script (using the import functionality) that could be solved
> while doing such a fix.
>
> So we'd have:
> * JellyContext -> Context for the execution of a Script object
> (variable storage, resource loading, etc)
> * ScriptLoader -> Handles taglib registration and creation of Script
> objects (and immediate execution) from various sources ( URL, file, etc
> )
>
Yep.
> > In addition, a compileXX/runXX method that can directly handle
> > an InputStream instead of a URL would be very great for Cocoon.
>
> Or anything that is XMLizable (more useful for Cocoon, since you can
> hook an internal pipeline directly into a script). (I have one already,
> as well as a few other helper components, such as a compiled script
> cache, that you might find useful..)
>
Oh, yeah, XMLizable is a good idea! Thanks!
> > If you're interested I can provide a patch.
>
> patches welcome! :)
:)
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [Jelly][RT] The purpose of the JellyContext
Posted by peter royal <pr...@apache.org>.
On Dec 23, 2003, at 7:12 AM, 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.
yea! i'm heavily using it in cocoon and it rocks!
> 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.
I'd call it a 'ScriptLoader' or something, but I agree with the general
idea. There are some bugs in the tracker that deal with relative URL's
inside a script (using the import functionality) that could be solved
while doing such a fix.
So we'd have:
* JellyContext -> Context for the execution of a Script object
(variable storage, resource loading, etc)
* ScriptLoader -> Handles taglib registration and creation of Script
objects (and immediate execution) from various sources ( URL, file, etc
)
> In addition, a compileXX/runXX method that can directly handle
> an InputStream instead of a URL would be very great for Cocoon.
Or anything that is XMLizable (more useful for Cocoon, since you can
hook an internal pipeline directly into a script). (I have one already,
as well as a few other helper components, such as a compiled script
cache, that you might find useful..)
> If you're interested I can provide a patch.
patches welcome! :)
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [Jelly][RT] The purpose of the JellyContext
Posted by Robert <ro...@bull-enterprises.com>.
The original issue is at:
http://jira.werken.com/secure/ViewIssue.jspa?key=JELLY-1
and here is the start of a thread I started back in March on the subject:
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=commons-dev@jakarta.apache.org&msgId=682724
I don't have my solution available just yet as it needs a tad bit of
work on the JellyContext and tried out, but that wouldn't take a big
leap to accomplish. Along those lines I already have some scopes built
that could be ready to go, namely a default scope as well as the HTTP
scopes.
If there is more interest on this, I'll get cracking and submit a patch
for it.
- Robert
Carsten Ziegeler wrote:
> Robert wrote:
>
>>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.
>>
>
> That sounds great as I will need an extensible scope mechanism as well.
> Can you give a pointer to the issue? Is your solution available somewhere?
>
> Carsten
>
>
>>I do agree that with the context doing so much it can make things
>>confusing however.
>>
>>Robert
>>
>
>
>
>
>
> ---------------------------------------------------------------------
> 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
Re: [Jelly][RT] The purpose of the JellyContext
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Robert wrote:
> 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.
>
That sounds great as I will need an extensible scope mechanism as well.
Can you give a pointer to the issue? Is your solution available somewhere?
Carsten
> I do agree that with the context doing so much it can make things
> confusing however.
>
> Robert
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [Jelly][RT] The purpose of the JellyContext
Posted by Robert <ro...@bull-enterprises.com>.
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.
Robert
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: 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [Jelly][RT] The purpose of the JellyContext
Posted by Paul Libbrecht <pa...@activemath.org>.
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