I agree that the mismatch is odd (ie. confusing), but my vote would be to
make the <html:options> collection attribute act like the <logic:iterate>
collection attribute. My reasoning is that I have several static methods
that return collections that could be used to populate the select lists, and
it would be nice to access them directly instead of having to get to them
via a property in a bean.
Vic
> -----Original Message-----
> From: Michael McCallister [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, March 13, 2001 6:58 PM
> To: [EMAIL PROTECTED]
> Subject: Mismatch Between <html:options> and <logic:iterate>
>
> Am I the only one who finds it odd that while both <logic:iterate> and
> <html:options> take a "collection" attribute, one expects a run-time
> expression that evaluates to a Collection and the other takes a String
> that
> names a bean in some scope that is a Collection?
>
> Shouldn't these two tags play according to the same rules when it comes to
>
> identically named attributes? Should I file a bug for this? Should one
> behavior "win-out" over the other? In my opinion, the behavior of naming
> bean with a String attribute feels the most "Struts like".
>
> Unfortunately, changing things one way or the other will break code, but
> better to do so before cutting a release than after.
>
>
> Mike
>
