Imbedded Context response... >Auch Arron, > >Are you sure all those "instanceof" checks are a good idea? Adding >another nested tag would require you to adapt the NestedPropertyHelper, >which isn't clean design IMHO. > Quite sure. The "instanceof"s look for standard nesting functionality which the nested tags implement (they're actually empty interfaces. Basically used for identification only, so I wouldn't have to have huge lists of "instanceof"s or otherwise).
1) Nested property helper looks up the tree to find a parent tag to get the nested property from (NestedParentSupport) 2) If the tag supplied implements NestedNameSupport it will write it's name attribute for it. 3) If the tag implements NestedPropertySupport it will updated its "property" property with the nested property. 4) NestedTagSupport is for future proofing, in the case that some action just needs to pick out the nested tags from the rest. The only exception to this rule is the html:form tag. I left this for backwards compatibility, as some other original tags may need it for some reason in it's current state, so I maintained support. I don't know why I didn't have a nested:form tag, but there's one now (only took a minute to add :). I even updated the running examples to use it. I also removed the check for the select tag. I had it there from when there was no NestedParentSupport interface. It was the first implementation, then the logic tags were done and they all used it and the realisation was there that it's a state of nesting. Not implementing it means the helper will jump right over it. None of the extended logic tags use it, as you don't want them to be parents. Horrible parents those logic tags... lock their beans under the stairs they do :) These updates are all updated in the downloads and examples except the saving example... http://www.keyboardmonkey.com/struts If there is a better way... somebody tell me. >And I wouldn't have noticed this if I wasn't checking an NestedIterate >bug. nested:iterate behaves differently than logic:iterate, which really >shouldn't be. I narrowed it down to this: > For one... the nested tags don't need the name attribute. They'll overwrite it anyway. :) The id attribute is set for you if it's not supplied (only because it used to be the only way to correctly nest (viewing only) with the original tags. Done only to be on the safe side). As for any bugs... I added the id and indexId attributes as you have them there into my monkey example and they worked fine. >The only place I can see something happens between >IterateTag.doStartTag() and NestedIterateTag.doStartTag() is precisely >in NestedPropertyHelper. So I guess all those instanceofs already >created a bug ... > Dare I say that the instanceof's didn't create the bug. I'd be making sure the libraries which you tested the original version on is the same as the nested version. Nothing else is different about the tags. You'll get more of my attention if they're running out of the same library in the same webapp. This is the process... Tag starts off with it's "doStartTag()". The nested tags get the property helper to do it's thing, and then returns from a call to the super.doStartTag(). So, outside of property helper, it's 100% the Struts tag it extends. The Property helper does four things. 1) Walks up the tree of tags to find the nested tags' parent tag. And from it gets the nesting level, the property of the current tag, and sets the nested property. 2) If the tag has NestedNameSupport, it will also get it's "name" property set. To make sure that the super Struts tag gets a hold of the right bean. 3) If the property has "../../" in it or whatever, it will correct the nested property for that specified. 4) Nothing else. Everything else is left to the original Struts tag. Everything. You can think of the nested extension as exactly this... It simply sets the properties for you from the inside. Instead of you have to know the nesting, it will do it for you. Instead of writing the name, it will write it for you (and write over it too if you have :). All properties are set in the tags properties before the tag is run. The nested extension just steps in there to correct them, and let the tag do what it always has. The original tag actually thinks you're really clever for nesting so well... :) Read what property helper does. It is commented. Take two seconds per tag source to see that that is all they're doing. The most complex tag extended is the iterate tag, which if "id" is not supplied, It will correct it to make sure things are more reliable. It also has to put the index on the end. Tough stuff. >I'm searching further to find the bug itself, but if you would beat me >at it, I would appreciate it :) > >Cheers, >tomK > Sorry if this didn't help. A part of my frustration is that the extension is *really* simple, and does largely nothing at all. One of the things which has kind of baffled me about this group is the lengths I have to go to tell you you're running the original tags! As I've been saying from day one... ...they just see each other better to render that important little "property" property out properly. 'tis all. Everything else was just a delightful bunch of by-products of having everything finally relate rather than act as islands. Be cool peoples. Arron. (theKM*) * instanceof's don't create bugs as they're always the result of bad logic. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
