Bug 39331

Summary: support nested calls and Maps from request
Product: Taglibs Reporter: Mike Hansen <mh983>
Component: Input TaglibAssignee: Tomcat Developers Mailing List <dev>
Status: RESOLVED FIXED    
Severity: enhancement    
Priority: P2    
Version: nightly   
Target Milestone: ---   
Hardware: All   
OS: All   
Attachments: A Patch to the input taglib to provide nested calls and request lookup for options map.

Description Mike Hansen 2006-04-18 04:16:16 UTC
It would be nice to be able to call nested objects with the input tags.  For
example, <input:text name="person.address.zip" .../> would translate to a call
on the default bean of getPerson().getAddress().getZip().

It would also be very helpful to be able to specify the optionMap and
optionValues and optionLabels as bean names to be looked up in the request to
get the Map instead of only expecting a Map object in the property itself.  So,
for example, <input:select name="color" options="themap"/> would look up the
attribute "themap" in the request object, find the corresponding value of type
Map (put there by the controller) and use that for the options.
Comment 1 Mike Hansen 2006-04-18 04:18:18 UTC
Created attachment 18117 [details]
A Patch to the input taglib to provide nested calls and request lookup for options map.

patches Util.java and Select.java from the input tree.

first time submitting a patch.	please let me know if I missed anything.
Comment 2 Karl von Randow 2007-04-22 01:30:19 UTC
Thanks for this Mike, and my sincere apologies that it is just over a year later that I reply to this bug. 
This is a great idea. It would need to work backwards-compatibly with previous usage, so we would 
need to add some extra attribute or something to let the taglib know that it could treat "."s like that... 
perhaps even a beanProperty="person.address.zip" option.

I believe that the best option is actually to use the new "value" attributes and EL, eg. <input:text 
name="zip" value="${person.address.zip}" /> then you have complete flexibility over the name field. 
This renders the "bean" attribute only useful for simple forms, but I think that is appropriate. The 
general direction seems to be to use EL for doing this kind of bean accessing, and the new "value" 
attribute enables this to work properly.

I'm going to close the bug, hoping that this is a satisfactory solution for you as well (if you're still 
interested in a solution after all this time!).

cheers,
Karl