Admittedly, I haven't looked at your code... but can you please verify that it meets the following requirements:
1) All form errors are displayed together. In other words, if more than one field is bad, the user will see all bad fields rather than having to correct them one at a time. 2) The user sees the original data they input. In other words, if the user enters "abc" into a dollar field, then the form displaying the errors and allowing them to redo their input will also display "abc". 3) Data conversion and validation can be done on multiple fields at once. One example is a set of date fields (month, day, year) that together form a single Date object. I always find this topic interesting because I don't think the right answer has really bubbled up yet. That's why I try to understand the different approaches. >From my point of view, to meet the above requirements data conversion and validation would have to be done on or within the entire form bean. Since your code sounds like it does this before the data ever gets to the form bean, I just wondered how you solved those issues. -Paul Arron wrote: > > People reading this thread should also look at the last few in... > Re: Fwd: Re: Extensibility of struts... > It's touching the same topic. > > I think that the most important things is what was just raised. The > marshaling of strings into more valid objects. One implementation I'm > working with has altered the struts servlet to allow the configuration > of Converter objects to be mapped to object types, so that you can > specify classes that can handle this marshal on a specific need in an > automatic process. e.g.: we use BigDecimal for all of our dollar types > (financial app), and there's a converter set up to handle the > marshaling, and on the inside the model is perfectly fine. A bad marshal > also results in an error, and is returned to the input view. Quite neat. > > Not taking away from skill or intentions, you've all written some sweet > stuff, but don't you think (this is more than likely just me. I often > think too laterally and get the wrong point on things) that relying on a > big property switcheroo from the form object to the data model in the > action class is messy and almost defeating the point of struts when it > handles everything automatically, excellently and elegantly?... > > Struts' level of automagic management is something to be beheld, but as > a group trying to maintain wads of yukky code that's frizbee-ing data > from one object to another. > > It's like a Ken Done painting hanging on the wall of the Sistine Chapel. > Nasty ugly little blemish. > > Arron. > > Craig R. McClanahan wrote: > > > > >On Sun, 25 Nov 2001, box wrote: > > > >>Date: Sun, 25 Nov 2001 22:53:38 +0100 > >>From: box <[EMAIL PROTECTED]> > >>Reply-To: Struts Developers List <[EMAIL PROTECTED]>, > >> box <[EMAIL PROTECTED]> > >>To: Struts Developers List <[EMAIL PROTECTED]> > >>Subject: Re: General model question ? > >> > >>Thank you Craig, > >> > >>I see the point, You are right it makes a lot of sense. But the behind the > >>scene matter of my question was the performance reason. > >>I have to copy all the properties of ActionForm to appropriate business > >>logic object. The clean way of doing this is using the reflection API, which > >>is rather slow. > >> > > > > > >First, you're going to have to do this type of conversion anyway -- > >because HTTP parameters come in as strings, you don't want to directly use > >things like java.util.Date for the properties. > > > >Second, have you *yourself* done benchmarks that the "cost" of reflection > >even matters? Consider: > > > >* This is totally an issue of CPU time - economically, this is an > > incredibly easy problem to solve (in fact, it's very difficult to > > buy a new processor that is faster than your current one, but actually > > costs you more money). > > > >* Modern JVMs have ***vastly*** narrowed the performance gap between > > reflection based calls and direct calls. In the very large majority > > of cases, it's just not worth worrying about. > > > >* If our application is based on EJBs, it is already doing a *lot* more > > reflection-based processing than Struts is doing. > > > >My advice would be focus on reducing developer effort -- this is > >***much*** more expensive than whatever hardware you utimately deploy your > >application on. > > > >>regards Wojtek > >> > > > >Craig > > > > > >>----- Original Message ----- > >>From: "Craig R. McClanahan" <[EMAIL PROTECTED]> > >>To: "Struts Developers List" <[EMAIL PROTECTED]>; "box" > >><[EMAIL PROTECTED]> > >>Sent: Sunday, November 25, 2001 7:14 AM > >>Subject: Re: General model question ? > >> > >> > >>> > >>>On Thu, 22 Nov 2001, box wrote: > >>> > >>>>Date: Thu, 22 Nov 2001 19:36:25 +0100 > >>>>From: box <[EMAIL PROTECTED]> > >>>>Reply-To: Struts Developers List <[EMAIL PROTECTED]>, > >>>> box <[EMAIL PROTECTED]> > >>>>To: [EMAIL PROTECTED] > >>>>Subject: General model question ? > >>>> > >>>>Hi everybody, > >>>> > >>>> I am new to struts, but I find them very usefull. > >>>> > >>>> There is one question that bothers me. > >>>> > >>>> Wy is ActionForm a class not an interface ? > >>>> > >>>> I have got my own application data model and I would just need to > >>>>implement > >>>> the ActionForm to update/input the data via html forms. > >>>> > >>>> But it's not possible - I must inherit the struts structure, so I have > >>>> > >>to > >> > >>>> create ActionForm with get, set methods and after all copy all > >>>> > >>properties > >> > >>>> between my data model and the corresponding ActionForm. > >>>> > >>>> Am I missing something ? > >>>> > >>>ActionForm is a class in order to *prevent* exactly the behavior you > >>>propose :-). > >>> > >>>The purpose of an ActionForm is to contain the server-side state of the > >>>input fields, for the following reasons: > >>> > >>>* So that you can validate them (you don't want invalid data > >>> being scribbled into your application data objects by Struts's > >>> automatic bean population) > >>> > >>>* So that you can reproduce the user's input data in case of an > >>> error such as an invalid integer (you would use a String in the > >>> ActionForm for an EJB property that is an "int"). > >>> > >>>* So that your application data objects can be reused in non-Struts > >>> contexts (otherwise, they would always require struts.jar to be around). > >>> > >>>You *really* don't want to modify anything in your application data model > >>>until *after* validation has succeeded. That's why the Struts design > >>>pattern is to do this in an Action, by copying the appropriate values from > >>>the ActionForm into your application data objects, performing any data > >>>conversions that are necessary. Making ActionForm a class instead of an > >>>interface forces you to do the right thing. > >>> > >>>> regards > >>>> > >>>> Wojtek > >>>> > >>>Craig McClanahan > >>> > >>> > >>>-- > >>>To unsubscribe, e-mail: > >>> > >><mailto:[EMAIL PROTECTED]> > >> > >>>For additional commands, e-mail: > >>> > >><mailto:[EMAIL PROTECTED]> > >> > >>> > >>>-- > >>>Myslisz o otworzeniu wlasnego sklepu internetowego? > >>>A moze o wynajeciu stoiska w wirtualnym pasazu? > >>>W Centrum e-biznesu mozesz miec jedno i drugie. Juz od 290 zl za rok. > >>>Wybierz: e-witryne lub e-sklep. http://handel.getin.pl/ > >>> > >>> > >> > >>-- > >>Myslisz o otworzeniu wlasnego sklepu internetowego? > >>A moze o wynajeciu stoiska w wirtualnym pasazu? > >>W Centrum e-biznesu mozesz miec jedno i drugie. Juz od 290 zl za rok. > >>Wybierz: e-witryne lub e-sklep. http://handel.getin.pl/ > >> > >> > >>-- > >>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > >>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > >> > >> > > > > > >-- > >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
