struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Hardy <>
Subject Re: DynaActionForm and the 'pull' model
Date Sat, 21 May 2005 16:04:04 GMT
On 19/05/05 21:29&nbsp;Laurie Harper wrote:
>> my chosen option would be to use your view objects as form objects, 
>> where you modify the view object by adding string-typed getters and 
>> setters for every property. 
> I'm not really keen to 'pollute' the view objects with String-type 
> derived properties just for the HTML presentation; the view objects are 
> how any client (web app, web service, Swing GUI, etc) would interact 
> with the application. This also implies having String-to-model 
> conversion code scattered through the view objects...

OK, valid point, but you then go on to say that you have a method on 
your view object to provide all the string-typed properties in a map to 
your form bean or get them from your form bean.

I think what you are doing is mixing and matching the struts-paradigm 
(front servlet pattern) with what JSF wants to do. Which is actually a 
good idea because (a) I thinks struts needs something more and (b) I 
don't like the JSF point-and-click .NET wanna-be approach.

By the way this isn't my only reply - I wanted to split the subject - I 
am posting again with questions about your design.

 From a design perspective, there's something niggling me about your 
view objects. The view whether it is a GUI or HTTP is basically a 
framework or layer that should provide an API for stuff like 
string-to-type conversion. So I agree you should not pollute the view 
objects with such code. It's just semantics I guess - they're not really 
'view objects' - they're DTOs. I guess you put the data together from 
various data object in the back end, right?

What I am aiming for is a DynaActionForm that I can configure in xml but 
including type info. There would also be a validation mechanism - do you 
want a validation error if the type cast fails? etc.

<form-bean name="libraryForm"
     <form-property name="sectionId"

You could populate it with BeanUtils or with your toMap() method.

I guess this is only one step removed from what you've got anyway. It's 
just encapsulated within the formbean and view layer framework.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message