To recap...
understand that you can do something like you mention above, but have you
tried to do that? It brings me back full circle to my original point that I
haven't found a clean solution at all. Say we are back to a list of users
and each user has multiple "addresses." You want to update all the address
information for each address including the Integer "zipCode." Are you going
to make a new object called AddressWithPropsForJustInput - even though you
need to input 99% of what's alredy in "Address" (as Strings) except for the
zip (thus duplicating 99% of what already exsists). Doing this will also
require a new Employee object that can take your
"AddressWithPropsForJustInput" so that you can populate your list of
EmployeesWitPropsJustForInput in your ActionForm. You then have to get all
this info back into a List of regular Employees - and if you didn't
lazyLists up front inside of Employee - you are going to have a nice ugly
time looping through everything and recreating objects and populating your
input fields into them.
Bottom line is it is going to be *extremely* messy - I've actually tried
using that approach as well. I've tried even embedding the value objects
into my ActionForm DTOs - for example
AddressWithPropsJustForInput {
Address address; //standard value object from domain
String zipAsString;
setAddress(Address address) { this.address = address; }
getAddress( return address; );
String setZipAsString().... etc
Another option is to recreate the backend methods to take your new
"inputOnly" objects - bypassing the transfer of the inputOnly objects to the
normal domain POJOs (value object/dto's/whatever you want to call them). I'm
not fond of this solution either.
All this being said Paul, I actually agree that what you propose will work
and it's actually all that I can come up with as well - the problem is while
i've used that approach, It is very messy - especially when you have regular
POJOs staring at your right in the face. It's the duplication of property
names and the mess involved in conversions to the nested business objects
that you need to tranform them into that is the real annoyance.
I think I'm going to try all this with DynaForms and see how that alleviates
some of the headache. Thanks though for your thoughts.
On 12/17/05, Rick R <[EMAIL PROTECTED]> wrote:
>
> oops ... don't try to tab while using gmail :) I was trying to indent my
> code by instinct using tab and hit tab and 'end' to the end of the line an
> enter:) .... caused a send. I'l continue in another email.
>
> On 12/17/05, Rick R <[EMAIL PROTECTED]> wrote:
> >
> > On 12/16/05, Paul Benedict <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > > I am not suggestign you create a new business object. I am suggesting
> > > you create a new object for input purposes. You need a transport layer
> > > between your model and the web; thus you have an ActionForm. But you need
> > > to
> > > pad your ActionForm with additional objects because of the complexity of
> > > your app.
> >
> >
> >
> > In a sense though they "do" become duplicat objects of standard POJOs
> > that you use in the backend. You keep mentioning you only need to add the
> > properties that you need for input, and sure that's fine, that might save
> > you a couple minutes of work not having to add those properties, but I'll
> > explain more about the problem with that later.
> >
> > >
> > >
> > > No. You only create properties for the values you need for INPUT. As I
> > > said in previous emails, if you have a business object with 50 properties
> > > but only need to capture input for 3, your input object only needs 3
> > > properties.
> >
> >
> >
> > I understand that you can do something like you mention above, but have
> > you tried to do that? It brings me back full circle to my original point
> > that I haven't found a clean solution at all. Say we are back to a list of
> > users and each user has multiple "addresses." You want to update all the
> > address information for each address including the Integer "zipCode." Are
> > you going to make a new object called AddressWithPropsForJustInput - even
> > though you need to input 99% of what's alredy in "Address" (as Strings)
> > except for the zip (thus duplicating 99% of what already exsists). Doing
> > this will also require a new Employee object that can take your
> > "AddressWithPropsForJustInput" so that you can populate your list of
> > EmployeesWitPropsJustForInput in your ActionForm. You then have to get all
> > this info back into a List of regular Employees - and if you didn't
> > lazyLists up front inside of Employee - you are going to have a nice ugly
> > time looping through everything and recreating objects and populating your
> > input fields into them.
> >
> > Bottom line is it is going to be *extremely* messy - I've actually tried
> > using that approach as well. I've tried even embedding the value objects
> > into my ActionForm DTOs - for example
> >
> > AddressWithPropsJustForInput {
> > Address address; //standard value object from domain
> > setAddress(..)// puts an Address object into the object. Th
> >
> >
> >
> > --
> > Rick
>
>
>
>
> --
> Rick
--
Rick
