I am using a kind of bi-directional convertion (Form<->DTO) in my project. I have the form with all fields type String that are converted to a DTO of typed fields. I tryed to use LocaleBeanUtils and I found some bugs as I fixed them and will send the patches to the Commons Project. It is working all right here considering the user Locale (parsing internationalized values of dates, time, numbers... and printing (converting to String) them in a internationalized format too) and so on. I am on vacation and will be out for about 5 weeks (marriage!!!), so if you want the patched codes to send to jakarta-commons, tell me and I will attach it to bugzilla #24941.
http://issues.apache.org/bugzilla/show_bug.cgi?id=24941 Stutz Para: Struts Developers List <[EMAIL PROTECTED]> Hubert Rabago cc: <[EMAIL PROTECTED] Assunto: Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum) .com> 12/18/2003 09:02 PM PST Responder a "Struts Developers List" That's exactly what I meant to say, of course I just didn't articulate it as well as you did. =) Form bean details are spread all around, violating the DRY principle. The DTO's can be used to tell Struts how to generate dynamic action forms that it (and the validator) can work with, without the user having to list down all the fields in the struts config file. Also, the conversion from ActionForm to app-specific DTO's can mostly be automated. You're already working on it -- that's great news! Just give a shout out if you need any sort of help (coding, testing, whatever). I was gonna propose a possible implementation, but since you've got something going already, I'd like to help out with that instead. I'm thinking this is something that doesn't need to wait for 2.0 to be useful, or at least it's something that can be developed to work for 1.x with an eye towards 2.x/Jericho compatibility. Or, design it for 2.x and make it 1.x compatible. Whatever. I just wanna stop repeating field names between DTO and form beans. I suppose laziness really is the father of innovation. --- Ted Husted <[EMAIL PROTECTED]> wrote: > The gotcha is that a DTO usually has typed fields, and can't redisplay > invalid data. An ActionForm is specifically designed to capture String > input, validate it, then redisplay it if necessary, so it can then be > converted to whatever type is desired. Most DTO's aren't up for this > type of gauntlet. > > What I would like to do is merge (2) and (3), and add additional > properties so that an input form can be fully described. Right now, we > have form details spread across the sturts-config, validations.xml, and > the server page. A central element that could render most of the form > for you (including i18n labels, hints, and so forth), would eliminate a > lot of the redundancy we face today. > > I'd also like to include bi-directional data-converters in the form > element, to close the loop. So, after validating the input, we could > extract a populated DTO from a factory-type method. Likewise, we could > pass a DTO to the form object and have it convert the binary types to > properly-formatted Strings. > > Right now, I'm working on this using FormProc and Maverick (SourceForge > projects) and hope to move it to Struts soon. > > -Ted. > > Hubert Rabago wrote: > > I think we're tackling different issues here. > > What I'm trying to avaoid is having (1) a data transfer object used by the > > different tiers, and (2) a form bean object or dyna form bean definition > which is > > a close reflection of the fields that the DTO already defines, and (3) a > > validation rule xml which lists down all/most of the fields along with rules > on > > how to validate each. > > Of course, I'll also need to write code to convert my DTO to a form bean and > vice > > versa. > > I'm thinking we can lose the explicit form bean definition and the code which > > converts between the DTO and form bean. > > > > > > --- Mete Kural <[EMAIL PROTECTED]> wrote: > > > >>>For a given form/action, the framework will be supplied with the FQCN of the > >>>DTO/VO. From there, it can determine what the fields of the form will be. > >> > >>The > >> > >>>form bean validation/descriptor XML will provide the validation information > >> > >>and > >> > >>>any conversion rules as needed to format/parse between the value object and > >> > >>the > >> > >>>string representation for the form bean. > >> > >>That sounds very interesting. I think there is interest in having support for > >>dynamic forms where the fields of the form are determined dynamically rather > >>than hardcoded in the JSP. What are the ideas on how to handle dynamic field > >>names (and number of fields) in Struts 2.0? > >> > >>Let's say that we are designing a dynamic customer information editing form. > >>Every user has different preferences on what fields they want to edit or > >>allowed to edit. Action class accesses a web service and receives a SOAP > >>response with exactly those fields that are fit for this user. How could > Struts > >>assemble the form dynamically and pre-populate the customer information and > >>then validate it when the user submits? > >> > >>Regards, > >>Mete > >> __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
