lol - good point!

My point is that you shouldn't accept all parameters, lump them into a map and chuck them to the application. I might be complicating things by looking at the mistake the struts developers made by including maps. In a purely scripting, dynamic environment, it may be more acceptible.

I need to think in a more groovy manner and less about typing I suppose :$

Graeme Rocher wrote:

On 7/1/05, Graham O'Regan <graham.oregan-hLP5QRf/WPkaAEmSxgGLmNBPR1lH4CV8@public.gmane.org> wrote:

I think the idea of a map of parameters is a really bad way to go, it's better to have a strongly typed object (like strut's actionForm) so you know *exactly* what parameters you are accepting and can validate their type and content before processing.

When has "strongly typed" been a major consideration in scripting languages? And why does using a Map preclude validation? You can still validate the Map just as you would the request object.

Maps of attributes is more acceptible tho, like RequestMap, SessionMap and ApplicationMap which *only* reference maps of objects that the application has created rather than opening the map to parameters that the user can create. Christof Vollrath wrote:

Hi Steve, to handle request parameters in GvTags I invented a DynaForm. This DynaForm extends a map by allowing subforms and arrays. So if a HTTP request parameter is named like: form.subform.array[5].name the request can be parsed and several DynaForm objects will be created, so that the field can be accessed using the same expressions as the parameter name. This makes it easy to have subforms and tables in a form. By, tof Steven Devijver wrote:

One thing I have been thinking about is a good Groovy abstraction for the request and response interfaces. Maps seem nice but then we only have the state without the behavior. But maps support in Groovy is nice so we should probably merge the Map interface with the HttpServletRequest and HttpServletResponse interfaces. If anyone wants to take a shot a this please feel free to do so.

-- Graham O'Regan Senior Developer Ellison Brookes m: 07971 993 726 e: graham.oregan-hLP5QRf/WPkaAEmSxgGLmNBPR1lH4CV8@public.gmane.org w: http://www.ellisonbrookes.com The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this information is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. Ellison Brookes is neither liable for the proper and complete transmission of the information contained in this communication nor for any delay in its receipt.

-- Graham O'Regan Senior Developer Ellison Brookes w: http://www.ellisonbrookes.com The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this information is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. Ellison Brookes is neither liable for the proper and complete transmission of the information contained in this communication nor for any delay in its receipt.