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" <[EMAIL PROTECTED]>
To: "Jakarta Commons Users List" <[EMAIL PROTECTED]>
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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
