DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19780>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19780 <nested:iterate> does not seem to support java.util.Set, contrary to documentation ------- Additional Comments From [EMAIL PROTECTED] 2003-10-06 22:05 ------- Just marked it as invalid, because nesting with Sets is outside how the nested tags work. WHY? Because the nested tags do nothing but manage the property property. This is in the documentation. To be particular, the iterate tag doesn't set any bean references or anything. It just notes down an extra nested section to the property. At this point the <nested:write> tag evaluates this new property (and it's additional nesting), against the common bean. This differs to the original tags, (and the nested tags if you give it a "name" attribute), because then they're just playing with object references. If you *could* use Sets, it would only be for "viewing" data. Useless if you ever wanted to submit something through a form. Why?... because sets don't have a JavaBean property access method. myProperty = Plain property. No collections. myProperty[9] = Indexed property. Used for basic arrays and List impls. myProperty(key) = Mapped property. Used for Map impls. ...if someone can tell me where Sets fit in then it can be added to the <nested:iterate> tag. It's just that there's no "I have a new value, and this is how you get to it" technique. My recommendation, is basically what you already have or use the <bean:write> instead of the <nested:write>... <nested:root name="bar"> <nested:iterate id="meh" property="delegates" type="Dude"> <bean:write name="meh" property="name" /> </nested:iterate> </nested:root> Even though you "can" supply a name property and have the tags pick up on a bean, this is what gets most people into trouble. If you look at the underlying property, it should be a healthy "something.somethingElse[2].name". But if you give it a name, it will resart the nested context, and it will be left with just "name". This is no good to people trying to commit forms back to the server. The most common hang-up people have with the nested tags is they still use the "name" property. The original tags simply ignored the name property. But others wanted to use it to restart the nested context on purpose, so I allowed it back in. But it's a case of use at your own peril. Summary: There's nothing really wrong with the docco. It does say that it just manages the property property, and that you can forget the name attribute for all child tags. What it doesn't explicitly say is that if you're about to use a name attribute, be sure of what you're in for. In other words, leave the bug as-is, as more docco will follow in some form or another :) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
