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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
