PROPOSAL: expression tag library

[Scott Hasse <sc...@isthmusgroup.com>]

Hi, all

I have been lurking on this list for quite a while now and want to say that
I am very impressed with the work you all have been doing.  I recently put
some work into an expression language and associated tag library that I
would like to donate to this group, if you are interested.  The tag library
is designed to promote good MVC design, and borrows many usage patterns from
XSLT and XPath, but uses Java introspection instead of paths for resolving
expressions, and errs on the side of Java where things like naming
conventions are concerned.

More information and examples are at:

http://plaza.isthmusgroup.net/exptags/intro.jsp

I am the only contributor of source, so there aren't any legal/licensing
issues.

I am getting married this week, so I will be a bit unreachable in the short
term, but will be back around the 24th of May to continue development and
see what you all have to say.  There is a chance I will be able to check
email a few times over the next couple of weeks as well, so if you have
questions, feel free to send them my way.

Are you interested in incorporating this tag library?

Scott

Re: PROPOSAL: expression tag library

[Scott Hasse <sc...@isthmusgroup.com>]

Hi, all

Comments interspersed below.
----- Original Message -----
From: "James Strachan" <ja...@yahoo.co.uk>


> Hi Scott
>
> Congratulations, both on your wedding and on a great piece of development
> work!
>
> Just a thought, how about calling it JTags? Then we'd have XTags for
working
> with XML and JTags for working with Java objects (& beans, arrays,
> Collections, Maps etc). Nice similarity there?

That would be fine

> Also seperating out the expression language from the tag library might be
> useful too - certainly Struts may find it useful, I'm sure other projects
> will as well. Maybe jakarta-commons might be a good place for the
expression
> language code to live then it could be used in various (Jakarta &
> non-Jakarta) projects - maybe Velocity / Anakia too? I can imagine it
being
> useful in tools as well such as IDEs, debuggers etc.
>
>
> Finally a couple of comments about your expression language...
>
> * I'd prefer it if you used the "/" character for the path seperator
rather
> than ".".

Yeah, I debated that one a bit myself.  The "." seems more natural to me,
but there are advantages to XPath compatibility as well.  I'd like to hear
what others think.  The "/" does avoid some naming conflicts.  However,
perhaps a better way to be able to reference Java objects with pure XPath
would be to use a data binding mechanism.

> * Relative / absolute paths and variables.
>
> One neat feature of XPath and XTags / XSLT is that by default path
> expressions are relative. So you can do things like...
>
> <xtags:forEach select="order">
>     <!-- context is now an order -->
>
>     order's id is:
>      <xtags:valueOf select="id"/>
>
>     <xtags:forEach select="item">
>         <!-- context is now an item -->
>
>         product name is:
>         <xtags:valueOf select="product/name"/>
>     </xtags:forEach>
>
> </xtags:forEach>
>
> In the above, the two <forEach> tags are relative to the 'current context'
> like in XSLT / XPath. So nested <forEach> tags can be used to efficiently
> navigate down a complex tree structure. So in XPath you can be relative
>
>     name     = name element of current context
>     /name    = name element of root context
>     $name   = name variable
>
> I don't yet see how this kind of relative navigation and lookup of
variables
> can be done in your expression language. i.e. how to specify the
difference
> between
>
> <xtags:forEach select="order">
>
>     relative customer for current order
>
>     <xtags:valueOf select="customer"/>
>
>     variable customer...
>
>     <xtags:valueOf select="$customer"/>
>
> </xtags:forEach>
>
>
> Though the scope axis might have something to do with it? Would your
> expression language be something like this?
>
> <jtags:forEach select="order">
>
>     relative customer for current order
>
>     <jtags:valueOf select="customer"/>
>
>     variable customer...
>
>     <jtags:valueOf select="page:customer"/>
>
> </jtags:forEach>
>

In this cut of the expression language, I chose to make all references
absolute.  To me, that cleared up a lot of the confusion I tend to have with
XPath.  There are two ways to access the current element in a forEach:

* the curent() function
* give the element an id, and reference it by name

The scope axis isn't meant to be a mechanism for that.

Hope that helps, now, off to Hawaii for me!

Scott

Re: PROPOSAL: expression tag library

[James Strachan <ja...@yahoo.co.uk>]

Hi Scott

Congratulations, both on your wedding and on a great piece of development
work!

> I have been lurking on this list for quite a while now and want to say
that
> I am very impressed with the work you all have been doing.  I recently put
> some work into an expression language and associated tag library that I
> would like to donate to this group, if you are interested.  The tag
library
> is designed to promote good MVC design, and borrows many usage patterns
from
> XSLT and XPath, but uses Java introspection instead of paths for resolving
> expressions, and errs on the side of Java where things like naming
> conventions are concerned.
>
> More information and examples are at:
>
> http://plaza.isthmusgroup.net/exptags/intro.jsp

This is really cool!

Its very similar to the XTags library in semantics, the XPath-like
expression language, the similar XSLT style tags <forEach>, <valueOf>, <if>
<choose><when><otherwise> <variable> etc. XTags works on XML data, your
library works on Java objects. So they both compliment each other really
nicely. (I'm looking forward to using them both together ;-).

Just a thought, how about calling it JTags? Then we'd have XTags for working
with XML and JTags for working with Java objects (& beans, arrays,
Collections, Maps etc). Nice similarity there?

Also seperating out the expression language from the tag library might be
useful too - certainly Struts may find it useful, I'm sure other projects
will as well. Maybe jakarta-commons might be a good place for the expression
language code to live then it could be used in various (Jakarta &
non-Jakarta) projects - maybe Velocity / Anakia too? I can imagine it being
useful in tools as well such as IDEs, debuggers etc.


Finally a couple of comments about your expression language...

* I'd prefer it if you used the "/" character for the path seperator rather
than ".".

Sure "." is more Java like for Java programmers. Though the people editing
the JSP pages will probably be more XML / HTML / XSLT programmers than Java
programmers, so making the expression language more like XPath would make
more sense IMHO. It would also make JTags and XTags more alike ;-)

Also "." is used to avoid name clashes in page/request/session/application
scope attrbutes lot - often class names or packages are used as attribute
names.

So being able to do something like

$com.acme.model.Customer/name

to lookup a customer variable and get its name property would be valid and
not require any escaping of the "." character.


* Relative / absolute paths and variables.

One neat feature of XPath and XTags / XSLT is that by default path
expressions are relative. So you can do things like...

<xtags:forEach select="order">
    <!-- context is now an order -->

    order's id is:
     <xtags:valueOf select="id"/>

    <xtags:forEach select="item">
        <!-- context is now an item -->

        product name is:
        <xtags:valueOf select="product/name"/>
    </xtags:forEach>

</xtags:forEach>

In the above, the two <forEach> tags are relative to the 'current context'
like in XSLT / XPath. So nested <forEach> tags can be used to efficiently
navigate down a complex tree structure. So in XPath you can be relative

    name     = name element of current context
    /name    = name element of root context
    $name   = name variable

I don't yet see how this kind of relative navigation and lookup of variables
can be done in your expression language. i.e. how to specify the difference
between

<xtags:forEach select="order">

    relative customer for current order

    <xtags:valueOf select="customer"/>

    variable customer...

    <xtags:valueOf select="$customer"/>

</xtags:forEach>


Though the scope axis might have something to do with it? Would your
expression language be something like this?

<jtags:forEach select="order">

    relative customer for current order

    <jtags:valueOf select="customer"/>

    variable customer...

    <jtags:valueOf select="page:customer"/>

</jtags:forEach>


> Are you interested in incorporating this tag library?

+1

Yes! This is really cool.


James


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com