You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Harold Russell <hs...@yahoo.com> on 2003/06/06 12:14:20 UTC
[Jelly] Modularization: To Return A Non XMLOutput/String Object
Hi,
I've been experimenting with Jelly to determine if it
is suitable to use as a general purpose prototyping
language. First thing I was trying to do was to write
code that are "modularized." By "modularized" I meant
something like a function which has its own local
variable scope.
My first try was using a define:taglib and define:tag
tags to create my own custom tag. I can "call" this
"module" by using the tag and attributes as input
parameters. This is the closest thing that resembles a
reusable "module"/"function" as the code inside the
tag has its own variable scope.
The only problem is that when my custom tags are
evaluated, it can only return XMLOutput/String and not
any other object.
Does anyone have any advice on writing "modularized"
code in Jelly?
__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
Re: [Jelly] Modularization: To Return A Non XMLOutput/String Object
Posted by Bill Keese <bi...@tech.beacon-it.co.jp>.
I tested similar things, namely with <threads:group> and <threads:thread>.
The following works fine:
<threads:group>
<threads:thread>...</threads:thread>
</threads:group>
"thread" adds itself to "group". However, I wanted to define my own tags
like ant, <parallel> and <single>,
The usage idea was:
<parallel>
<single> ... </single>
<single> ... </single>
</parallel>
The code that didn't work was:
<define:tag name="parallel">
<threads:group var="myGroup">
<define:invokeBody/>
</threads:group>
<threads:wait group="${myGroup}"/>
</define:tag>
<define:tag name="single">
<threads:thread> ... </threads:thread>
</define:tag>
I traced through the code and it was failing because of the compile-type
ancestor function.
Bill
----- Original Message -----
From: "Paul Libbrecht" <pa...@activemath.org>
To: "Jakarta Commons Users List" <co...@jakarta.apache.org>
Sent: Tuesday, June 10, 2003 3:51 PM
Subject: Re: [Jelly] Modularization: To Return A Non XMLOutput/String Object
> Bill Keese wrote:
> > Hello Paul,
> >
> >
> >>Then maybe using TagSupport.findAncestorWithClass() would help ?
> >
> >
> > I don't think this would work because (I forget the correct terminology
> > but...) findAncestorWithClass() finds compile-time ancestors rather than
> > runtime ancestors. So in the following example, when bar calls foo, bar
is
> > not considered an ancestor of foo:
> >
> > <define:taglib uri="myLib">
> >
> > <define:tag name="foo">
> > ... I want to set a return value in bar ...
> > </define:tag>
> >
> > <define:tag name="bar">
> > <foo arg1="123"/>
> > </define:tag>
> >
> > </define:taglib>
> >
> > Instead, the ancestor of "foo" is define:taglib, or something like that.
> > Too bad! Do you agree?
> >
> > Bill
>
> That was my fear.
> Have you actually tested it ?
> The problem would be the same, I guess, with an included script...
>
> If this is the case, then we should request an extra method doing this
> job precisely. At least I presume it would be helpful...
>
> Paul
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
Re: [Jelly] Modularization: To Return A Non XMLOutput/String Object
Posted by Paul Libbrecht <pa...@activemath.org>.
Bill Keese wrote:
> Hello Paul,
>
>
>>Then maybe using TagSupport.findAncestorWithClass() would help ?
>
>
> I don't think this would work because (I forget the correct terminology
> but...) findAncestorWithClass() finds compile-time ancestors rather than
> runtime ancestors. So in the following example, when bar calls foo, bar is
> not considered an ancestor of foo:
>
> <define:taglib uri="myLib">
>
> <define:tag name="foo">
> ... I want to set a return value in bar ...
> </define:tag>
>
> <define:tag name="bar">
> <foo arg1="123"/>
> </define:tag>
>
> </define:taglib>
>
> Instead, the ancestor of "foo" is define:taglib, or something like that.
> Too bad! Do you agree?
>
> Bill
That was my fear.
Have you actually tested it ?
The problem would be the same, I guess, with an included script...
If this is the case, then we should request an extra method doing this
job precisely. At least I presume it would be helpful...
Paul
Re: [Jelly] Modularization: To Return A Non XMLOutput/String Object
Posted by Bill Keese <bi...@tech.beacon-it.co.jp>.
Hello Paul,
> Then maybe using TagSupport.findAncestorWithClass() would help ?
I don't think this would work because (I forget the correct terminology
but...) findAncestorWithClass() finds compile-time ancestors rather than
runtime ancestors. So in the following example, when bar calls foo, bar is
not considered an ancestor of foo:
<define:taglib uri="myLib">
<define:tag name="foo">
... I want to set a return value in bar ...
</define:tag>
<define:tag name="bar">
<foo arg1="123"/>
</define:tag>
</define:taglib>
Instead, the ancestor of "foo" is define:taglib, or something like that.
Too bad! Do you agree?
Bill
----- Original Message -----
From: "Paul Libbrecht" <pa...@activemath.org>
To: "Jakarta Commons Users List" <co...@jakarta.apache.org>
Sent: Monday, June 09, 2003 10:54 PM
Subject: Re: [Jelly] Modularization: To Return A Non XMLOutput/String Object
> Then maybe using TagSupport.findAncestorWithClass() would help ?
> I am not sure wether a tagscript can actually access its tag object
> (simply using "this" in jexl ?), if yes than I am pretty sure it extends
> TagSupport (and probably even MapTagSupport) so that this method is
> accessible...
>
> To me it's a kind of "rich" return value, which has the advantage of
> being transparent to such things as iteration type of parents.
> I am not sure it would work within an imported tag though... that would
> interest me!
>
> Paul
>
>
> Bill Keese wrote:
> > Note that things are a little different depending on if your functions
are
> > written in java or in jelly. If you write custom tags in Jelly (via
> > define:tagLib
> > and define:tag), then in order to set a variable in the parent context,
you
> > have
> > to do something tricky like ${context.setExport(true)} (which
> > exports
> > all variables set after this call), or something like
> > ${context.getParent().setVariable('foo', bar)}
> >
> >
> >
> >>>The only problem is that when my custom tags are
> >>>evaluated, it can only return XMLOutput/String and not
> >>>any other object.
> >
> >
> > Of course, you can encode any return information you want in
> > the XMLOutput/String return value. You can then parse this return
value
> > using xml:parse. Something like
> >
> > <x:parse var="myReturnCodeDocument">
> > <myTagLib:myTab foo="bar>
> > </x:parse>
> >
> > Then you can access the contents of myReturnCodeDocument using
> > the XPath related functions in the XML library. But it's a real hassle
to
> > do things
> > that way.
> >
> > Maybe the right approach, whenever possible, is to handle return values
the
> > same
> > way as in XSL or lisp programs. So, instead of doing things like in C:
> > a1 = func1();
> > a2 = func2();
> > a3 = func3 ( a1, a2 )
> >
> > you should do something like this:
> > func3 ( func1() , func2() )
> >
> > In Jelly the syntax is
> > <func3>
> > <arg1><func1/></arg1>
> > <arg2><func2/></arg2>
> > </func3>
> >
> > Of course, inside of func3 you may have to call xml:parse in order to
use
> > XPath to parse the input XML document:
> > <x:parse var="myInputDocument"><define:invokeBody/></x:parse>
> > <core:set var="arg1"><x:expr
> > select="$myInputDocument/arg1/*"/></core:set>
> > <core:set var="arg2"><x:expr
> > select="$myInputDocument/arg2/*"/></core:set>
> > ...
> >
> > Personally, I wish that XPath was better integrated in Jelly, basically
like
> > the
> > XSL language.
> > Then, you wouldn't have to do the intermediate step of calling xml:parse
and
> > core:set/x:expr (see example above).
> >
> > Bill
> >
> > ----- Original Message -----
> > From: "Paul Libbrecht" <pa...@activemath.org>
> > To: "Jakarta Commons Users List" <co...@jakarta.apache.org>
> > Sent: Saturday, June 07, 2003 5:53 AM
> > Subject: Re: [Jelly] Modularization: To Return A Non XMLOutput/String
Object
> >
> >
> >
> >>Harold Russell wrote:
> >>
> >>>Hi,
> >>>
> >>>I've been experimenting with Jelly to determine if it
> >>>is suitable to use as a general purpose prototyping
> >>>language. First thing I was trying to do was to write
> >>>code that are "modularized." By "modularized" I meant
> >>>something like a function which has its own local
> >>>variable scope.
> >>>
> >>>My first try was using a define:taglib and define:tag
> >>>tags to create my own custom tag. I can "call" this
> >>>"module" by using the tag and attributes as input
> >>>parameters. This is the closest thing that resembles a
> >>>reusable "module"/"function" as the code inside the
> >>>tag has its own variable scope.
> >>>
> >>>The only problem is that when my custom tags are
> >>>evaluated, it can only return XMLOutput/String and not
> >>>any other object.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
Re: [Jelly] Modularization: To Return A Non XMLOutput/String Object
Posted by Paul Libbrecht <pa...@activemath.org>.
Then maybe using TagSupport.findAncestorWithClass() would help ?
I am not sure wether a tagscript can actually access its tag object
(simply using "this" in jexl ?), if yes than I am pretty sure it extends
TagSupport (and probably even MapTagSupport) so that this method is
accessible...
To me it's a kind of "rich" return value, which has the advantage of
being transparent to such things as iteration type of parents.
I am not sure it would work within an imported tag though... that would
interest me!
Paul
Bill Keese wrote:
> Note that things are a little different depending on if your functions are
> written in java or in jelly. If you write custom tags in Jelly (via
> define:tagLib
> and define:tag), then in order to set a variable in the parent context, you
> have
> to do something tricky like ${context.setExport(true)} (which
> exports
> all variables set after this call), or something like
> ${context.getParent().setVariable('foo', bar)}
>
>
>
>>>The only problem is that when my custom tags are
>>>evaluated, it can only return XMLOutput/String and not
>>>any other object.
>
>
> Of course, you can encode any return information you want in
> the XMLOutput/String return value. You can then parse this return value
> using xml:parse. Something like
>
> <x:parse var="myReturnCodeDocument">
> <myTagLib:myTab foo="bar>
> </x:parse>
>
> Then you can access the contents of myReturnCodeDocument using
> the XPath related functions in the XML library. But it's a real hassle to
> do things
> that way.
>
> Maybe the right approach, whenever possible, is to handle return values the
> same
> way as in XSL or lisp programs. So, instead of doing things like in C:
> a1 = func1();
> a2 = func2();
> a3 = func3 ( a1, a2 )
>
> you should do something like this:
> func3 ( func1() , func2() )
>
> In Jelly the syntax is
> <func3>
> <arg1><func1/></arg1>
> <arg2><func2/></arg2>
> </func3>
>
> Of course, inside of func3 you may have to call xml:parse in order to use
> XPath to parse the input XML document:
> <x:parse var="myInputDocument"><define:invokeBody/></x:parse>
> <core:set var="arg1"><x:expr
> select="$myInputDocument/arg1/*"/></core:set>
> <core:set var="arg2"><x:expr
> select="$myInputDocument/arg2/*"/></core:set>
> ...
>
> Personally, I wish that XPath was better integrated in Jelly, basically like
> the
> XSL language.
> Then, you wouldn't have to do the intermediate step of calling xml:parse and
> core:set/x:expr (see example above).
>
> Bill
>
> ----- Original Message -----
> From: "Paul Libbrecht" <pa...@activemath.org>
> To: "Jakarta Commons Users List" <co...@jakarta.apache.org>
> Sent: Saturday, June 07, 2003 5:53 AM
> Subject: Re: [Jelly] Modularization: To Return A Non XMLOutput/String Object
>
>
>
>>Harold Russell wrote:
>>
>>>Hi,
>>>
>>>I've been experimenting with Jelly to determine if it
>>>is suitable to use as a general purpose prototyping
>>>language. First thing I was trying to do was to write
>>>code that are "modularized." By "modularized" I meant
>>>something like a function which has its own local
>>>variable scope.
>>>
>>>My first try was using a define:taglib and define:tag
>>>tags to create my own custom tag. I can "call" this
>>>"module" by using the tag and attributes as input
>>>parameters. This is the closest thing that resembles a
>>>reusable "module"/"function" as the code inside the
>>>tag has its own variable scope.
>>>
>>>The only problem is that when my custom tags are
>>>evaluated, it can only return XMLOutput/String and not
>>>any other object.
Re: [Jelly] Modularization: To Return A Non XMLOutput/String Object
Posted by Bill Keese <bi...@tech.beacon-it.co.jp>.
Here are some notes from my experiences with "return values" in Jelly.
> The way it is done into such things as jelly-swing is that the tag
> climbs the hierarchy to the first possible ancestor tag that can receive
> a result and "adds" it there.
Note that things are a little different depending on if your functions are
written in java or in jelly. If you write custom tags in Jelly (via
define:tagLib
and define:tag), then in order to set a variable in the parent context, you
have
to do something tricky like ${context.setExport(true)} (which
exports
all variables set after this call), or something like
${context.getParent().setVariable('foo', bar)}
> > The only problem is that when my custom tags are
> > evaluated, it can only return XMLOutput/String and not
> > any other object.
Of course, you can encode any return information you want in
the XMLOutput/String return value. You can then parse this return value
using xml:parse. Something like
<x:parse var="myReturnCodeDocument">
<myTagLib:myTab foo="bar>
</x:parse>
Then you can access the contents of myReturnCodeDocument using
the XPath related functions in the XML library. But it's a real hassle to
do things
that way.
Maybe the right approach, whenever possible, is to handle return values the
same
way as in XSL or lisp programs. So, instead of doing things like in C:
a1 = func1();
a2 = func2();
a3 = func3 ( a1, a2 )
you should do something like this:
func3 ( func1() , func2() )
In Jelly the syntax is
<func3>
<arg1><func1/></arg1>
<arg2><func2/></arg2>
</func3>
Of course, inside of func3 you may have to call xml:parse in order to use
XPath to parse the input XML document:
<x:parse var="myInputDocument"><define:invokeBody/></x:parse>
<core:set var="arg1"><x:expr
select="$myInputDocument/arg1/*"/></core:set>
<core:set var="arg2"><x:expr
select="$myInputDocument/arg2/*"/></core:set>
...
Personally, I wish that XPath was better integrated in Jelly, basically like
the
XSL language.
Then, you wouldn't have to do the intermediate step of calling xml:parse and
core:set/x:expr (see example above).
Bill
----- Original Message -----
From: "Paul Libbrecht" <pa...@activemath.org>
To: "Jakarta Commons Users List" <co...@jakarta.apache.org>
Sent: Saturday, June 07, 2003 5:53 AM
Subject: Re: [Jelly] Modularization: To Return A Non XMLOutput/String Object
> Harold Russell wrote:
> > Hi,
> >
> > I've been experimenting with Jelly to determine if it
> > is suitable to use as a general purpose prototyping
> > language. First thing I was trying to do was to write
> > code that are "modularized." By "modularized" I meant
> > something like a function which has its own local
> > variable scope.
> >
> > My first try was using a define:taglib and define:tag
> > tags to create my own custom tag. I can "call" this
> > "module" by using the tag and attributes as input
> > parameters. This is the closest thing that resembles a
> > reusable "module"/"function" as the code inside the
> > tag has its own variable scope.
> >
> > The only problem is that when my custom tags are
> > evaluated, it can only return XMLOutput/String and not
> > any other object.
> >
> > Does anyone have any advice on writing "modularized"
> > code in Jelly?
>
> The way it is done into such things as jelly-swing is that the tag
> climbs the hierarchy to the first possible ancestor tag that can receive
> a result and "adds" it there.
> (namely, this is how a component is added to a container).
>
> There has been a long thread however about having return values for tags.
>
> Paul
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
Re: [Jelly] Modularization: To Return A Non XMLOutput/String Object
Posted by Paul Libbrecht <pa...@activemath.org>.
Harold Russell wrote:
> Hi,
>
> I've been experimenting with Jelly to determine if it
> is suitable to use as a general purpose prototyping
> language. First thing I was trying to do was to write
> code that are "modularized." By "modularized" I meant
> something like a function which has its own local
> variable scope.
>
> My first try was using a define:taglib and define:tag
> tags to create my own custom tag. I can "call" this
> "module" by using the tag and attributes as input
> parameters. This is the closest thing that resembles a
> reusable "module"/"function" as the code inside the
> tag has its own variable scope.
>
> The only problem is that when my custom tags are
> evaluated, it can only return XMLOutput/String and not
> any other object.
>
> Does anyone have any advice on writing "modularized"
> code in Jelly?
The way it is done into such things as jelly-swing is that the tag
climbs the hierarchy to the first possible ancestor tag that can receive
a result and "adds" it there.
(namely, this is how a component is added to a container).
There has been a long thread however about having return values for tags.
Paul