Adam Hardy wrote:
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.
That's exactly right; the traditional Struts paradigm is 'push', where
there are actions which feed data into the request before the JSP is
called. What I'm working with is 'pull' where the JSPs aquire the data
they need themselves. Struts becomes the mediator for page flow and
operations which modify state on the server. Pure view operations have
minimal dependance on Struts.
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?
That's right, yes. The methods for translating to/from Maps of Strings
is a convenience for the presentation layer on top. The advantage of
making the view objects / DTOs responsible for this is it reduces
coupling. The presentation layer can be less intimately entwined with
the view layer ;-)
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"
type="org.apache.struts.validator.AdamsDynaValidatorForm">
<form-property name="sectionId"
type="java.lang.String"
cast="java.lang.Integer"
validate="true"
/>
</form-bean>
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.
Yeah, that would be a good abstraction. But it does mean that the view /
DTO objects and the Struts configuration have to be kept closely in
sync. I think some sort of typed form bean would be a good general
solution, though; I suspect a lot of people would find this approach
appealing -- I'd probably have adopted it in my case if it had existed
already!
L.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
