DO NOT REPLY [Bug 19780] - does not seem to support java.util.Set, contrary to documentation

[bu...@apache.org]

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 arron@keyboardmonkey.com  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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org