Questions regarding the usage of nested tags...

[Alex Paransky <al...@individualnetwork.com>]

At some point NESTED tags were being developed outside of the STRUTS tag
library, however, recently they have been merged into the nightly build.
There are a number of questions which I have in this regard:

1. With introduction of nested tags into the library, there are now two
methods of coding your page, mainly using nested tags or not.  On one hand,
using the nested tags are preferred (I think).  On the other hand, what is
the need for keeping the standard STRUTS tags in the library other than for
compatibility reasons.  In addition, point 2 (below) raises additional
concern.

2. Since nested tags a based on the "general" STRUTS tags, how closely are
nested tags following the development of the "general" STRUTS tag.  In other
words, if an additional attribute is added to an existing STRUTS tag, or a
new tag is developed for STRUTS, will this change be "mirrored" in the
NESTED tag library?

3. Would it be a good effort, to incorporate the "NEST" and "ROOT" tags
directly into STRUTS proper, and make the existing STRUTS tags NEST/ROOT
aware (perhaps by pointing the struts tags to use the .nested. extensions or
otherwise, just incorporating the logic in the NESTED library into the
existing STRUTS tags themselves.

4. The context of the NEST or ROOT tags do not flow into any "dynamically"
included pages (<jsp:include... for instance).  We have an application which
dynamically includes required presentation for a particular object at
runtime.  It is not practical to include this presentation at compilation
time, since the type of the object is not known.  We were at first, using
the NESTED library, however, because it did not properly work with
dynamically included pages, we stopped using it in favor of a <bean:define
toScope="request"... just prior to the dynamic include.

Thanks.
-AP_


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Questions regarding the usage of nested tags...

[Arron Bates <ar...@pacific.net.au>]

Answers inline...

>At some point NESTED tags were being developed outside of the STRUTS tag
>library, however, recently they have been merged into the nightly build.
>There are a number of questions which I have in this regard:
>
>1. With introduction of nested tags into the library, there are now two
>methods of coding your page, mainly using nested tags or not.  On one hand,
>using the nested tags are preferred (I think).  On the other hand, what is
>the need for keeping the standard STRUTS tags in the library other than for
>compatibility reasons.  In addition, point 2 (below) raises additional
>concern.
>
The nested tags are literally an extension to the original tags. All 
they do is provide the mechanism that allows the tags to see their 
parents and define how they relate to the tags they're nested inside.

All tags that can benefit from being nested have been extended. But not 
all. Most tags like the html tags use a "property" property to define 
bean properties. The nested tags manage this to define the nesting. You 
could already do it if you used dot notation "myProperty.propertyTwo". 
The nested tags manage this, and manage it in a complete sense beyond 
what you can type into your static properties (iterators for instance). 
Some tags have nothing to do with this, and hence not extended.

Some tags have alternative uses besides using the "property" property. 
<html:options> for example can use a "collections" attribute, and not 
bother with the "name" and "property" routine the other tags do. The 
nested tags assume you're using the nested context, and so rely on 
setting and managing the "name" and "property" properties.

For these reasons, the nested tags are not a replacement, but should be 
seen as an enhancement that allows you to nest them properly.

Plus the fact that some tags are just handy to use in their original 
form along with the nested tags. That's why they weren't intended as a 
replacement. They just enable truly neat data modeling and just as neat 
markup.

>2. Since nested tags a based on the "general" STRUTS tags, how closely are
>nested tags following the development of the "general" STRUTS tag.  In other
>words, if an additional attribute is added to an existing STRUTS tag, or a
>new tag is developed for STRUTS, will this change be "mirrored" in the
>NESTED tag library?
>
At the moment they include all the properties of the tags they extend. 
If an extra attribute is added to a tag the nested tags extend, it is up 
to the committer of that attribute to add it to the tld of the nested 
tags. Or at the very least tell the rest of the committers about it so 
someone can do it. This really is a menial maintenance effort.

As for functionality of the base tags themselves... the nested tags 
extend them, so anything internal is naturally obtained for free.

>3. Would it be a good effort, to incorporate the "NEST" and "ROOT" tags
>directly into STRUTS proper, and make the existing STRUTS tags NEST/ROOT
>aware (perhaps by pointing the struts tags to use the .nested. extensions or
>otherwise, just incorporating the logic in the NESTED library into the
>existing STRUTS tags themselves.
>
That was an option I strongly considered, but not all tags need to be 
nested aware. The logic for the nesting would have to be managed on a 
case by case basis, and also make the tld for the tags more complex. 
All-in-all, making the tags harder to maintain, and harder for Struts 
developers to use. Where as you take the clean markup you can use for 
the nested tags (because they're specifically made and not an 
adaptation), it's so clean and nice to play with. This could only be 
achieved by having their own tld and working structure.

>4. The context of the NEST or ROOT tags do not flow into any "dynamically"
>included pages (<jsp:include... for instance).  We have an application which
>dynamically includes required presentation for a particular object at
>runtime.  It is not practical to include this presentation at compilation
>time, since the type of the object is not known.  We were at first, using
>the NESTED library, however, because it did not properly work with
>dynamically included pages, we stopped using it in favor of a <bean:define
>toScope="request"... just prior to the dynamic include.
>
The tags rely on the run-time ability of running back up the tag 
hierarchy to ask the parent tags about their nested property. To do this 
through a dynamic include would require extra logic to place the nested 
property value at each step into scope so it can persist to the new 
page. It's possible, and not off my "to do" list all together. Just a 
matter of time, and nobody has come complaining that it's stopping them 
from doing something.

If you want to use dynamic includes, you can use the <nested:define> tag 
at point of inclusion and name the bean at that level. Then in your 
included page you can use the <nested:root> tag to pick up on the name 
of the bean you just defined, and from there continue nesting as if you 
were all in the same page. Note that this would only be for viewing 
details, and not updating values in the child page. For that I'd simply 
recommend using the static include directive. It has all the development 
time advantages, only it gets compiled into the main page at compile time.

The tags only need the root tag to point to a bean that the tags can get 
at. From there it's just property management.

As for "..since the type of the object is not known...", how does this 
apply?...
You have to rely on the property layout to your object model to markup 
any tags in the first place.
The nested tags are the same as the originals, as long as the properties 
match up to the right object, you're golden. One advantage nesting has 
over original tags in this capacity is that the natural composition of 
the data model and accessor properties will handle all this and select 
the right object for you. Sweet.


Hope that this has cleared some nagging thoughts. Possibly made a few, 
but that's what you get for creating something for a group of autonomous 
thinkers :)

The nested tags took the path of least resistance which also happen to 
be the cleanest result. When the tags were first made, it was after 
consultation with the struts-dev list and its contributors as to how I 
went about it. So even though it started out separate to Struts, it was 
made as if it was a part of it.


Arron.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>