> -----Original Message-----
> From: Marco Tedone [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, September 07, 2004 10:51 AM
> To: Struts Users Mailing List
> Subject: Re: A couple of questions
>
>
>
> >Not really... your way you have to add the code to the
> action to do the
> validation and extraction as well as the JSP, model and SQL.
>
> Model and SQL is not necessarily (and often) true: if I used
> course grained
> strategy, it may be that I've already got the field in my
> model, and if I
> use CMP EJB, I don't have to touch the SQL, because what it
> is returned to
> me is a local interface reference, rather than a ResultSet. And if I
> designed carefully my EJBs, and the field is already in the
> database, I
> wouldn't change a comma of my business model. So, resuming: I
> need another
> field in my presentation view (supposed I've got it already
> in my business
> model...): I add it to the JSP page, check it with Javascript, add its
> management to the servlet and I'm done. With Struts Actions:
> I add a field
> to the JSP, to the form object, dynamic or not (in case of an
> Action object
> getter/setter, reset() and validate() method), to the
> validation framework,
> to the Action (for its management)...
Okay...
ActionForm way Your Way
1)Add it to jsp form ditto
2)Add it to Form Object No
3)Add it to validation.xml Write validation for both JS _and_
server side.
(JS and server side validation done)
4)Treat it as object immediately, Write and maintain all the conversion
stuff yourself.
and use other peoples code to This includes all the parsing etc by hand.
transfer the Strings to VO.
So, yeah I get to add an extra field to my form class. right click and tell eclipse
to generate the getter/setters for it. OMG, that's hard. You on the other hand get
to write lots more code then I do to accomplish the same task. Now if you never
validate your code, and never have to worry about a user entering text when they
should be entering numbers, then your way is definitily easier. BUT if you have to
make a field required, ActionFormas are easier. If you have to make sure that it's a
float, ActionForm is easier. If you have to do both... hands down, ActionForms are
easier.
Anecdotal:
I have a little DyanForm I use for links, where sometimes I want to show everything,
sometimes I want to show just a summary. Typically this link looks like <html:link
aciont="showData?detail=Summary">Link</html:link>. With the action form I validate
this like this:
<form name="DetailForm">
<field property="detail" depends="required,mask">
<arg0 key="DetailForm.detail" />
<var>
<var-name>mask</var-name>
<var-value>(^full$)|(^summary$)</var-value>
</var>
</field>
</form>
Now this is a silly example, except that I can use DetailForm for as many actions as I
want, with no changes. Oh.. wait... now I want to add page ranges!
<form name="DetailForm">
<field property="detail" depends="required,mask">
<arg0 key="DetailForm.detail" />
<var>
<var-name>mask</var-name>
<var-value>(^full$)|(^summary$)</var-value>
</var>
</field>
<field property="startpage" depends="int">
<arg0 key="DetailForm.startPage"/>
</field>
<field property="startpage" depends="int">
<arg0 key="DetailForm.endPage"/>
</field>
</form>
Now, I've just moderately protected myself from some idget trying to tinker with the
links to some degree. I could also make sure they were all positive numbers etc. I
could even rather easily say that the page ranges are only valid for full, and not
summary detail pages.
The question again is.... what would you rather do... code what I just did by hand for
every action where you have summar/full options? or cobble up a quick configuration
bit? Which is going to get more usage? I copy and paste the above between customers
a lot.
>
>
> The ActionForm way. I >change the JSP, the Form, The model
> and the SQL. If
> I'm using Dyna Forms then the only code I touch is the VO.
> Everything else
> is handled in config files. If >I'm using Hibernate then I
> only have to
> worry about the field being in the database.
>
> >Which would you rather maintain, 1-20 lines of code , or 2-3
> config files?
>
> I can't see how my solution could lead to 20 lines of code
> against 2-3
> config files?
Validation. Transferring the strings to their VO counterparts. Try/catch blocks for
each field if you want to show all the errors at once.
Struts validation allows me to validate the whole form at once, rather then one field
at a time. With no extra coding. Just a configuration file.
Add in javascript on top of that. Making sure the JS is cross browser... All of which
the ActionForm gives you for free.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
