That's exactly what it does! (My example is that there's an organisation that has teams, that have monkeys that pick bunches that hold bananas. But it's all the same).
The extending class that represents a tag, implements "NestedParentSupport" and two other interfaces that tell the helper static method that the name and the property can be set by the nesting mechanism. But NestedParentSupport means that the tag is a parent, and that any property beneath it nests under that property adding it's property to the path. eg: Last night I just finished off making extensions to all the new logic and bean tags in the nightly build that were relevant. But as for the example... the nested version of the equals tag, needs to use it's current nesting level to check against, but the tags that it contains don't want it to interfere in the path, so it doesn't implement the NestedParentSupport and all the tags in it's contents will jump its property. I've adapted my example to use some of the nested logic tags... and damn... so fun. I'll be polishing it tonight/tomorrow and post it back to the group. A couple of bugs fixed (to do with the parenting) and all the tags in struts that could benefit from it. We're using it as a front to a full enterprisy app, but I have my smaller Monkey example serializing to a file defined as a static string in a class. It works. The only "slightly" tricky part is that it relies on one of the constructors load from a "getInstance()" singleton style so that it fetches from the disk. I'll clean it up for presentation, as it was a 15 minute hack for scientific curiosity, but running out of a static instance works a treat for a simple system. I think that it could redefine what tools are used to make speedy developed tiny apps. The abbreviated syntax is simply removing the need for the "name" property in the tag. It is set. Every time. But it's internal in the tag. This is because we can assume that all nesting tags have to use the same bean, therefore just do enough work to fix it's name property for strut's super class. It does make the tags nice, small and sexy though. :) There's one other feature that I've written, but have to finish the example tonight, is the ability to drop down levels in the properties. For example, you want options in a child class that you want to provide in a parent class... to use the familiar "../../" directory style to step down levels to get to a parent, or parent's parent etc. Would allow for ultimate flexibility in it's usage. Also need to spend 5 minutes making a tag that can define the bean at the top without the need for a form. Real easy, will be in my stuff tonight. Re the docco... the great thing is, is that the tags *are* the struts tags, with all the documentation on them where the "name" and "property" properties are set is true for the nested extension. I'm in the middle of a document that is outlining some nice usage, do's, don'ts etc. But this will be stuff that differs from the taglib docco that is already there for the super tags. As for the O/R tooling. No, haven't had the chance, not unless one of the boys that pulled it off this mail list has. For the persistent storage... nothing to suggest besides a "roll your own" solution. It's easy to set collections of objects from recordsets. That's fantastic. I think that this'll all come into its own when JDO implementations start rolling. Arron. Ted Husted wrote: >Arron Bates wrote: > >>If you want to go this way, I've heard that there's a nesting extension >>to make this easier too. >> > >So, the underlying purpose of the nested tags is to render the full >"path" to an element when it is situate on a nested bean. Given a >structure like > >+Grandparent >++Parent >+++Child >----property > >With properties like > >grandparent.getName() >grandparent.getParents() > >parent.getName() >parent.getChilds() > >child.getName() >child.getAllowance() > >We can write something like > ><nested:nest property="grandparent"> > <nested:write property="name"> > <nested:iterate property="parents"> > <nested:write property="name"> > <nested:iterate propery="childs"> > <nested:write property="name"> > $<nested:text property="allowance"> > </nested:iterate> > </nested:interate> ></nested:nest> > >With visible output like > >Lou > Stu > Tommy > $1 > Dill > $0 > Drew > Angelica > $10 > >And have Tommy's allowance element be represented in the HTML as > >$<input type="text" name="grandparent[1].parent[1].child[1].allowance" >value="1"> > >When submitted back to the ActinForm, the BeanUtils will then walk this >path so that the allowance property for the first child element of the >first parent element of the first grandparent element (Tommy) is >updated. > >And, it also allows for an abbreviated syntax, since the nested versions >of iterate look to the "enclosing" bean for its "name" property, as the >html form tags look to the ActionForm bean. > >Given the support for indexed and nested properties, I can see that we >need a taglib like this to "close the loop". I take it that the >nested-taglib-src is ready to commit as is (it looks that way to me). > >Meanwhile, are you updating a JDBC database from a bean like this? > >I agree that this is a valid representation of a model, but most >developers need to persist something like this to a conventional >database. > >We typically add a Developers Guide to a taglib, where we could put >notes about your serialization example, alogn with any notes on mapping >this back to a database. > >Is anyone using an O/R tool that would work well with nested beans like >this? > > >-- Ted Husted, Husted dot Com, Fairport NY USA. >-- Custom Software ~ Technical Services. >-- Tel +1 716 737-3463 >-- http://www.husted.com/struts/ > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
