Hi Thomas
Excellent question. One of the problems with Jelly is there's lots of ways
of doing things and it depends on exactly what you need.
You could just implement this with Tag implementations that match each tag
in your XML, using an abstract base class that the child will register with
its parent (if you need this feature).
As Christian said, another option is to just write normal beans for all your
tags (along with the Ant-style createFoo() and addFoo() method signatures),
then use the BeanTagLibrary to map the beans to tags. Then that will create
a root bean with nested bean properties for you. A custom root Tag might
help do something special (like when all the children have been added, do
something special or whatever).
It maybe that you just want to write normal beans for most of the child tags
but hook them together via some custom protocol. The JellySwing and JellySWT
libraries are interesting examples. When you do things like this in
JellySwing...
<frame title="My Explorer">
<splitPane>
<tree model="${bar}"/>
<table model="${foo}"/>
</splitPane>
</frame>
This is actually all implemented with one generic Tag implementation class,
called ComponentTag, which is instantiated by the tag library with a class
depending on the tag name so that when its invoked it creates a bean (a
swing widget) for each tag and then registers the beans with each other
using a custom protocol (the Component.add() with some special jiggery
pokery for some non-polymorphic wierdness in Swing).
So a similar approach could be taken if you want to keep your beans seperate
from Jelly and only have a little Jelly-specific glue to make it all work
and you want a custom protocol for hooking things together..
Probably the simplest approach is the bean one that Christian suggested -
where you just write beans then a single tag library that binds the root
bean to the library. You might want a custom root tag to do something
special.
What might help further this discussion is to describe what these tags do.
e.g. does it create some service or configure some components? Or does it
generate some XML output of some kind etc.
James
-------
http://radio.weblogs.com/0112098/
----- Original Message -----
From: "Thomas Nichols" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, January 23, 2003 2:34 PM
Subject: [jelly] Taglib best practices for nested elements?
> Good day,
>
> I'm implementing a custom tag library, trying to learn some lessons
> from earlier attempts. This library needs to use nested elements - a
> top-level "munge" tag contains children and grandchldren. I.e.
> level 0 : munge etc.
> level 1 : input tag, output tag etc. - "parameters"
> level 2 : "document" tags - currently FileTag (has name attr), URLTag
> (has href attr) Workfile (creates a temporary file).
>
> Question: what are the preferred ways to implement this?
> My priorities:
> - extensibility : must be easy to add new tags at each level
> - simplicity : must be easy to understand
> - Jelly compliance :) this stuff may get integrated into existing
> Jelly environments, it must play well with existing tag libraries.
> Options:
> 1. Each tag is a JellyTag in my namespace.
> 2. Level 0 tags are JellyTags, the remainder are extracted from the
> tag body.
> 3. Use BeanTagLibrary etc?
>
> ==== Option 1 ====
> MungeTag.doTag() calls invokeBody(), triggers InputTag.doTag() which
triggers
> FileTag.doTag() { // Level 2.
> // Use attributes to set file name (standard Jelly mechanics).
> // Attach self to parent (level 1) tag.
> }
>
> Level1Tag.doTag() {
> // Attach self to parent (level 0) tag.
> }
> Level0Tag.doTag() {
> // Process child "level 1" tag(s), e.g:
> URL url = level1Tag.getLevel2Tag.getURL();
> ...
> }
> Effectively, I'm manually duplicating the structure of the XML within
> Java - ugh.
>
> ==== Option 2 ====
> Something like:
> MungeTag.doTag() {
> Element mungeEl = JellyUtils.tagToDom4jElement (this); // :-)
> // Plain sailing - I can use dom4j to walk the tree.
> ...
> }
>
> So... how could I implement a generic tagToDom4jElement method? What are
> pros and cons of each approach? If feasible, the dom4j solution is clearly
> far simpler, but it's using Jelly only as a framework to deliver me a
chunk
> of XML that is in my own syntax. Since supporting other taglibs is a
> priority, I'd need to invokeBody() anyway since the XML fragment may
> contain embedded tags for other taglibs.
>
> Would the "BeanTagLibrary" approach be a better fit?
> A consequence of having such a powerful and flexible framework is having
to
> make such decisions - I've found several other approaches which I haven't
> discussed here. Please let me know if anyone can think of another
contender?
>
> Any and all feedback gratefully received.
>
> Best Regards,
> Thomas.
>
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
