(a) it seems an unnecessary step since I'm already marshalling data into & out of resultsets
(b) I have to maintain the object field/member variable information in yet another place (UML, database schema, xml schema, struts-config (& possibly HTML should be on this list too))
(c) BeanUtils won't convert strings based on locale-specific information (yet, AFAIK though it might be in the pipeline)
re (b), when I only have to specify that in one place, I know that I will have died and gone to programmer heaven :)
On 09/27/2003 05:00 PM Sgarlata Matt wrote:
Hmm well I do sometimes use different types in my DynaForms, but I think I want to move away from this practice in the future. There was a fairly good discussion of this in the post "[repost] Special view information -> ActionForm or request?" starting on 9/18.
To answer your real question about using DynaForms as transfer objects, I only use them if I am transferring data from the presentation tier down to the business tier. I use the DynaBean interface to do this. It's pretty slick how this works. If for some reason I decide not to use DynaActionForm at some point in the future you can make a POJO into a DynaBean by just passing "new WrapDynaBean(pojo)". If you want your business tier to have things already nicely placed in the correct type you could always use ConvertUtils to populate a strongly-typed POJO from your ActionForm. Or if you want to use a typed DynaBean I think you can declare your own DynaClass or something, but I'm not really sure on all the specifics of this process.
Does that answer your question?
Matt
----- Original Message ----- From: "Adam Hardy" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Saturday, September 27, 2003 10:40 AM
Subject: Re: BeanMapping WAS: [Poll] action mappings
Hey Matt, do you use different types in your dynaforms or do you stick to just strings? I was wondering about using dynaforms as transfer objects like you mention, but I only use strings, since incorrect form entries for non-string types don't make it back into the form after validation
failure.
And I would want to have types in my transfer objects.
Adam
On 09/26/2003 10:44 PM Sgarlata Matt wrote:
----- Original Message ----- From: "Mainguy, Mike" <[EMAIL PROTECTED]>
To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]>
Sent: Thursday, September 25, 2003 3:35 PM
Subject: BeanMapping WAS: [Poll] action mappings
I think your way is perfectly acceptable. I like to try and use the supplied interfaces (i.e. DynaBean) if they suit my needs and, to date, DynaBean has served me well. You can use BeanUtils to map DynaBeans to POJO's and visa versa (as a matter of fact you can to it to/from maps
also
I believe).
After working with DynaBeans some more, I agree with you. I am going to
use
them as my type for transfer objects as well instead of the strategy I outlined before where I defined my own IInputForm and IDynaInputForm interfaces.
My only gripe with using the commons-beanutils would be that I would
perhaps
like to have a couple levels of DynaBean and perhaps at the simplest
level
only have an interface like you describe (i.e. fewer methods in
implement).
I would like to see an empty interface called org.apache.commons.beanutils.Bean, but I can see that being a huge point
of
contention so I'm not going to press for it.
Matt
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- struts 1.1 + tomcat 4.1.27 + java 1.4.2 Linux 2.4.20 RH9
--------------------------------------------------------------------- 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]
-- struts 1.1 + tomcat 4.1.27 + java 1.4.2 Linux 2.4.20 RH9
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]