You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by di...@multitask.com.au on 2003/01/11 10:37:45 UTC
[jelly] tags split up
There are few remaining taglibs to go from what I can tell.
Can we have a quick vote on what stays core (use +1 for staying core, -1
to separate taglib):
bean
DG: +1
beanshell
DG: -1
core
DG: +1
define
DG: +1
dynabean
DG: +1
junit
DG: +1
log
DG: -1
threads
DG: -1
xml
DG: -1
--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [jelly] Avalonized
Posted by Robert McIntosh <ro...@bull-enterprises.com>.
>>-- I get back the results of the script. For me, this doesn't mean the
>>XMLOutput. We are using the scripting side as an application process
>>engine. Sort of like a workflow engine, but on a smaller scale(?). So in
>>essence I want to supply some parameters, execute a script, and get back
>>some results, be they beans (usually) or other variables.
>>
>>
>
>You can create a child context per request, then all the output variables
>can be kept/stored/processed etc.
>This allows the script to output state. Or you could have your own tags to
>create special state some place etc.
>
I hadn't thought of that, not being deeply familiar with how jelly
handles its contexts. I was just going to set variables in the context
the script was given. Most of what we do is create bean instances and
invoke methods on those beans, sometimes setting the return to a
variable for the 'client' of the script. I'll look at the context more
closely though.
>
>
>
>>-- I would like to be able to load the scripts via the class loader as
>>well as URL.
>>
>>
>
>You could do the classloader bit yourself then pass in the URL or
>InputStream to JellyContext.runScript(). Using a URL is better (as it can
>find relative resources etc).
>
Good point, I didn't think of that :-)
>
>
>
>
>>To meet my requirements would be pretty simple. The only change/addition
>>I could see to Jelly itself would be the loading via classloader, but
>>that would be a small addition to the resolveURL() method (from first
>>glance) of the Jelly class.
>>
>>
>
>Agreed - you could just derive your own JellyContext and implement this
>however you wish.
>
>
>
>
>>However, I don't want to leave out other uses, such as using the
>>XMLOutput, telling the service to exucute a non-named script by
>>supplying a direct URL, etc. So for that I've come up with the following
>>possibilities:
>>
>>- public Map runNamedScript( String scriptName, Map params )
>>- public Map runURLScript( String url, Map params ) - perhaps also allow
>>a URL object to be supplied...
>>
>>That takes care of returning basic results, now for the XMLOutput side:
>>- public void outputNamedScript( String name, Map params, OutputStream
>>
>>
>out )
>
>
>>- public void outputURLScript( String url, Map params, OutputStream out )
>>
>>or something like that... I'm not sure if 'ouputXXX' are good method
>>names, but you get the idea.
>>
>>Any thoughts? Did I leave something out?
>>
>>
>
>That sounds cool. One thing we've been meaning to do is to seperate out the
>'variable scopes' from the JellyContext so its easier to plugin your own
>Scopes easier. e.g. a ServletContext scope, a HttpServletRequest scope, an
>Ant project scope etc. This could either be a Map or a Scope interface with
>a map like (maybe simpler) interface.
>
>http://jira.werken.com/secure/ViewIssue.jspa?key=JELLY-1
>
>Maybe that'd help you pass in the parameter scope and return the results
>scope or something.
>
Very interesting thought. We haven't had to deal with scoping issues
really, but I can certainly see some value in it. In our current usage,
the engine doesn't know anything about scopes (Http in particular), so
if a script writer was using the script behind a web app (we actually
have a Struts action for invoking scripts that I will convert over to
Jelly as well), we just use a naming convention for output variables.
Not very elegant, but it works. However I think having a real scoping
solution would be much better. That feature isn't on my list just yet
and I know you guys, from what I've seen, are working on packaging
issues right now, but any idea on when your scope interface might become
reality?
>
>How about creating your own JellyRunner (or JellyDispatcher) class which has
>the semantics you like and we can take a look and see how it fits together?
>
I didn't see a JellyRunner or Dispatcher in the source I got last night,
but I assume you are talking about the service class itself ? I'm
working on it now, so I can send it along soon if you like.
Thanks for the comments!
Robert
>
>James
>-------
>http://radio.weblogs.com/0112098/
>
>__________________________________________________
>Do You Yahoo!?
>Everything you'll ever need on one web page
>from News and Sport to Email and Music Charts
>http://uk.my.yahoo.com
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[jelly] Avalonized (first crack)
Posted by Robert McIntosh <ro...@bull-enterprises.com>.
James,
I've attached the source file for a first crack at the JellyService. It
hasn't been tested yet as I would like you (or someone else for that
matter) to check to see if I'm using the API's the way I should be.
Thanks,
Robert
Re: [jelly] Avalonized
Posted by James Strachan <ja...@yahoo.co.uk>.
From: "Craig R. McClanahan" <cr...@apache.org>
> On Wed, 15 Jan 2003, James Strachan wrote:
>
> > That sounds cool. One thing we've been meaning to do is to seperate out
the
> > 'variable scopes' from the JellyContext so its easier to plugin your own
> > Scopes easier. e.g. a ServletContext scope, a HttpServletRequest scope,
an
> > Ant project scope etc. This could either be a Map or a Scope interface
with
> > a map like (maybe simpler) interface.
> >
> > http://jira.werken.com/secure/ViewIssue.jspa?key=JELLY-1
> >
> > Maybe that'd help you pass in the parameter scope and return the results
> > scope or something.
> >
>
> One example of how to do this is in commons-workflow -- it separates the
> notion of Scope from the notion of Context for pluggability in exactly the
> way you describe. It's got plugins for servlet API based scopes already
> there as proof of concept.
>
>
http://jakarta.apache.org/builds/jakarta-commons/nightly/commons-workflow/
Thanks Craig I'll take another look. I've been meaning to cast my eye over
commons-workflow again to see how hard/easy it'd be to merge code together
and maybe to create a jelly-ized commons-workflow implementation.
> Wish I had time to help you play with this ...
Me too :-)
James
-------
http://radio.weblogs.com/0112098/
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [jelly] Avalonized
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 15 Jan 2003, James Strachan wrote:
> That sounds cool. One thing we've been meaning to do is to seperate out the
> 'variable scopes' from the JellyContext so its easier to plugin your own
> Scopes easier. e.g. a ServletContext scope, a HttpServletRequest scope, an
> Ant project scope etc. This could either be a Map or a Scope interface with
> a map like (maybe simpler) interface.
>
> http://jira.werken.com/secure/ViewIssue.jspa?key=JELLY-1
>
> Maybe that'd help you pass in the parameter scope and return the results
> scope or something.
>
One example of how to do this is in commons-workflow -- it separates the
notion of Scope from the notion of Context for pluggability in exactly the
way you describe. It's got plugins for servlet API based scopes already
there as proof of concept.
http://jakarta.apache.org/builds/jakarta-commons/nightly/commons-workflow/
Wish I had time to help you play with this ...
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [jelly] Avalonized
Posted by James Strachan <ja...@yahoo.co.uk>.
From: "Robert McIntosh" <ro...@bull-enterprises.com>
> I am currently working on making an Avalon based service for executing
> Jelly scripts, and was wanting to run some ideas by the current Jelly
> developers.
Sounds *great*!
> Just so you know, the reason for doing this is that the company I work
> for currently has an XML based script engine that I wrote, but it is far
> from the capabilites of Jelly and thus we want to replace ours with
> Jelly. Now, our product runs within the Avalon framework and as such we
> use Avalon's service constructs to 'get' our current script engine, so
> naturally I would like to be able to do the same with Jelly.
>
> My requirements are:
> -- I be able to call out a script by 'name'
Sounds cool
> -- I get back the results of the script. For me, this doesn't mean the
> XMLOutput. We are using the scripting side as an application process
> engine. Sort of like a workflow engine, but on a smaller scale(?). So in
> essence I want to supply some parameters, execute a script, and get back
> some results, be they beans (usually) or other variables.
You can create a child context per request, then all the output variables
can be kept/stored/processed etc.
This allows the script to output state. Or you could have your own tags to
create special state some place etc.
> -- I would like to be able to load the scripts via the class loader as
> well as URL.
You could do the classloader bit yourself then pass in the URL or
InputStream to JellyContext.runScript(). Using a URL is better (as it can
find relative resources etc).
> To meet my requirements would be pretty simple. The only change/addition
> I could see to Jelly itself would be the loading via classloader, but
> that would be a small addition to the resolveURL() method (from first
> glance) of the Jelly class.
Agreed - you could just derive your own JellyContext and implement this
however you wish.
> However, I don't want to leave out other uses, such as using the
> XMLOutput, telling the service to exucute a non-named script by
> supplying a direct URL, etc. So for that I've come up with the following
> possibilities:
>
> - public Map runNamedScript( String scriptName, Map params )
> - public Map runURLScript( String url, Map params ) - perhaps also allow
> a URL object to be supplied...
>
> That takes care of returning basic results, now for the XMLOutput side:
> - public void outputNamedScript( String name, Map params, OutputStream
out )
> - public void outputURLScript( String url, Map params, OutputStream out )
>
> or something like that... I'm not sure if 'ouputXXX' are good method
> names, but you get the idea.
>
> Any thoughts? Did I leave something out?
That sounds cool. One thing we've been meaning to do is to seperate out the
'variable scopes' from the JellyContext so its easier to plugin your own
Scopes easier. e.g. a ServletContext scope, a HttpServletRequest scope, an
Ant project scope etc. This could either be a Map or a Scope interface with
a map like (maybe simpler) interface.
http://jira.werken.com/secure/ViewIssue.jspa?key=JELLY-1
Maybe that'd help you pass in the parameter scope and return the results
scope or something.
How about creating your own JellyRunner (or JellyDispatcher) class which has
the semantics you like and we can take a look and see how it fits together?
James
-------
http://radio.weblogs.com/0112098/
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[jelly] Avalonized
Posted by Robert McIntosh <ro...@bull-enterprises.com>.
I am currently working on making an Avalon based service for executing
Jelly scripts, and was wanting to run some ideas by the current Jelly
developers.
Just so you know, the reason for doing this is that the company I work
for currently has an XML based script engine that I wrote, but it is far
from the capabilites of Jelly and thus we want to replace ours with
Jelly. Now, our product runs within the Avalon framework and as such we
use Avalon's service constructs to 'get' our current script engine, so
naturally I would like to be able to do the same with Jelly.
My requirements are:
-- I be able to call out a script by 'name'
-- I get back the results of the script. For me, this doesn't mean the
XMLOutput. We are using the scripting side as an application process
engine. Sort of like a workflow engine, but on a smaller scale(?). So in
essence I want to supply some parameters, execute a script, and get back
some results, be they beans (usually) or other variables.
-- I would like to be able to load the scripts via the class loader as
well as URL.
To meet my requirements would be pretty simple. The only change/addition
I could see to Jelly itself would be the loading via classloader, but
that would be a small addition to the resolveURL() method (from first
glance) of the Jelly class.
However, I don't want to leave out other uses, such as using the
XMLOutput, telling the service to exucute a non-named script by
supplying a direct URL, etc. So for that I've come up with the following
possibilities:
- public Map runNamedScript( String scriptName, Map params )
- public Map runURLScript( String url, Map params ) - perhaps also allow
a URL object to be supplied...
That takes care of returning basic results, now for the XMLOutput side:
- public void outputNamedScript( String name, Map params, OutputStream out )
- public void outputURLScript( String url, Map params, OutputStream out )
or something like that... I'm not sure if 'ouputXXX' are good method
names, but you get the idea.
Any thoughts? Did I leave something out?
Thanks!
Robert McIntosh
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [jelly] tags split up
Posted by James Strachan <ja...@yahoo.co.uk>.
+1 on both of your votes. So I think that leaves just core and define as
being in the core of jelly.
Since the core of Jelly is dependent on commons-logging, I am tempting to
include log in the core as its a very small, simple library and adds no new
dependency - though I guess its use is optional.
Making the junit library non-core is gonna make the build process more
complex but I agree that in principle its use is optional.
James
-------
http://radio.weblogs.com/0112098/
----- Original Message -----
From: <di...@multitask.com.au>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Saturday, January 11, 2003 11:40 PM
Subject: Re: [jelly] tags split up
> Morgan Delagrange <md...@yahoo.com> wrote on 12/01/2003 04:26:55 AM:
> > --- dion@multitask.com.au wrote:
> > > There are few remaining taglibs to go from what I
> > > can tell.
> > >
> > > Can we have a quick vote on what stays core (use +1
> > > for staying core, -1
> > > to separate taglib):
> > >
> > > bean
> > > DG: +1
> > MD: -1
> I'm happy to revert to -1 on this one.
>
> > > beanshell
> > > DG: -1
> > MD: -1
> > >
> > > core
> > > DG: +1
> > MD: +1
> > >
> > > define
> > > DG: +1
> > MD: +1
> > >
> > > dynabean
> > > DG: +1
> > MD: -1
> And this one.
>
> > > junit
> > > DG: +1
> > MD: -1
> This will be harder, but I'm willing to give it a go.
>
> > > log
> > > DG: -1
> > MD: -1
> > >
> > > threads
> > > DG: -1
> > MD: -1
> > >
> > > xml
> > > DG: -1
> > MD: -1
> >
> > I'd also like to try having the junit and xml classes
> > compiled as test classes for core. That way, core can
> > still utilize those tags for testing without including
> > them in the core distro.
> I'm not sure how we can do this, but lets see.
>
> James? You got an opinion on any of these. I realise it's the weekend
> though!
> --
> dIon Gillard, Multitask Consulting
> Blog: http://www.freeroller.net/page/dion/Weblog
> Work: http://www.multitask.com.au
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [jelly] tags split up
Posted by di...@multitask.com.au.
Morgan Delagrange <md...@yahoo.com> wrote on 12/01/2003 04:26:55 AM:
> --- dion@multitask.com.au wrote:
> > There are few remaining taglibs to go from what I
> > can tell.
> >
> > Can we have a quick vote on what stays core (use +1
> > for staying core, -1
> > to separate taglib):
> >
> > bean
> > DG: +1
> MD: -1
I'm happy to revert to -1 on this one.
> > beanshell
> > DG: -1
> MD: -1
> >
> > core
> > DG: +1
> MD: +1
> >
> > define
> > DG: +1
> MD: +1
> >
> > dynabean
> > DG: +1
> MD: -1
And this one.
> > junit
> > DG: +1
> MD: -1
This will be harder, but I'm willing to give it a go.
> > log
> > DG: -1
> MD: -1
> >
> > threads
> > DG: -1
> MD: -1
> >
> > xml
> > DG: -1
> MD: -1
>
> I'd also like to try having the junit and xml classes
> compiled as test classes for core. That way, core can
> still utilize those tags for testing without including
> them in the core distro.
I'm not sure how we can do this, but lets see.
James? You got an opinion on any of these. I realise it's the weekend
though!
--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [jelly] tags split up
Posted by Morgan Delagrange <md...@yahoo.com>.
--- dion@multitask.com.au wrote:
> There are few remaining taglibs to go from what I
> can tell.
>
> Can we have a quick vote on what stays core (use +1
> for staying core, -1
> to separate taglib):
>
> bean
> DG: +1
MD: -1
>
> beanshell
> DG: -1
MD: -1
>
> core
> DG: +1
MD: +1
>
> define
> DG: +1
MD: +1
>
> dynabean
> DG: +1
MD: -1
>
> junit
> DG: +1
MD: -1
>
> log
> DG: -1
MD: -1
>
> threads
> DG: -1
MD: -1
>
> xml
> DG: -1
MD: -1
I'd also like to try having the junit and xml classes
compiled as test classes for core. That way, core can
still utilize those tags for testing without including
them in the core distro.
- Morgan
=====
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
http://jakarta.apache.org/watchdog
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>