I didn't code it, but I have to use it. The chaps here did it before I hit the scene. But I have to say that it's quite elegant.
You won't find it in the code I've written for nesting extension. I didn't write this, so it's out of my hands to submit it (and I think that their client paid too much for it to give it away), but I can transfer some IP and wouldn't mind working on the actual solution. But back to the story... 1) yes. 2) yes, but the fine grained errors come from another validation mechanism. Where a custom action was made from extending the struts action, and using an interface the the beans implement, fetch's a series of validation rules from the form to run through. This brings the finer grained business driven errors. The Converters themselves however only throw one error per object type. What I'd like to see, and I think that it'd be easy to implement, would be that if a converter failed, that it register an error against the property key that threw it. Then you could write out the errors properly for each instance. 3) No. This would take an extra runtime mapping to say that n inputs go into the one converter. Not currently implemented, but I do agree that it would be some cool functionality. Best I've done is to have a child object that holds the three properties and returns the proper Calendar object when asked by the business logic. The particular system that I work with is robust enough to get the job done, but I think that working in hind-sight would make it a truly nice solution. Arron. Paul Speed wrote: >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]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
