Re: newbie: Best Practice Struts/Value-Objects?

[Ted Husted]

Dan Allen wrote:
In short, instead of keeping around the DTO, just keep around a key
to get to that DTO, whether in a hidden field or the session.  Then,
you can call up the DTO at any point, update it and push it back to
the persistence layer when you want to save it.  The nice part about
this technique is that your action forms and DTOs don't even have to
align, since you draw what you need out of the form and push it into
your DTO to be saved.
If you are using a coarsely-grained data access API, then this is 
certainly a useful strategy. Though, if you have a client story that 
calls for certain fields to be updated, then that story should be 
reflected in the data access API (or DAO). Especially, if you are 
counting trips to the databse. :)

A popular strategy is to use a Transfer Object to define the parameters 
that might be needed by a data access API, and then declare as many data 
access methods are needed. The Struts Mailreader uses this "Context and 
Command" design as does JPetstore3. That some of the fields were null 
wouldn't matter to these specialized methods. Generally speaking, I like 
to try and frame things around the client stories, right down to the 
data access layer.

-Ted.



--
Ted Husted,
  Junit in Action  - ,
  Struts in Action - ,
  JSP Site Design  - .
"Get Ready, We're Moving Out!!" - 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: newbie: Best Practice Struts/Value-Objects?

[Dan Allen]

Ted Husted ([EMAIL PROTECTED]) wrote:

> Value Objects, also called Transfer Objects, are a design pattern. The 
> idea is that you can minimize the calls to the business tier by 
> collecting all the data you might need at once and submitting it as a 
> batch. (Opposed to, say, updating a form a line a time.) The properties 
> on the Transfer Object might be used by more than one business 
> component, but you collect them all together to minimize the number of 
> trips to the business layer.
> 
> The ActionForms are a type of Transfer Object. They transfer data 
> between a HTML form on the presentation layer to the Action on the 
> controller layer. (But most people would say they should not travel past 
> the Action.)
> 
> Many people also use Transfer Objects on the business layer, and often 
> the ActionForms and their Transfer Objects will look alot alike. 
> (Annoyingly so, some might say.) It's commonplace for someone to collect 
> what they need on an ActionForm and then copy all that over to a 
> Transfer Object, for submittal to the business layer. Sometimes people 
> will even nest a Transfer Object on a ActionForm. Another approach is to 
> have the ActionForm implement the Transfer Object's interface.
> 
> If your Transfer Objects and ActionForms share the same protocol (use 
> the same propert names), you can also pass your Transfer Object directly 
> to the HTML page. The HTML form tag doesn't care if you use an 
> ActionForm to populate a form or not, so long as the properties match.
> 
> If you kept your ActionForm in session scope, then you could just expose 
> five fields and keep the others intact. Just watch the that your reset 
> method doesn't blank them out.
> 
> Without using session scope (or a cookie), there is no clean way to 
> retain the fields without writing them out on the page somehow. One 
> trick is to use a method that will spit out whatever hidden fields you 
> need and then just call that using bean:write.
> 
> For this use-case, another approach would be to create a more finely 
> grained business layer. If you only need to update five fields, then you 
> should be able to update only those five fields. So you would have 
> another database query that set those five fields, but left the others 
> alone. The others may exist on the Transfer Object, but the other 
> database query can just ignore those.
> 
> -Ted.

I agree with all of what Ted said as he certainly summed it up very
well.  I want to append an idea of how you can update a portion of
your fields without having to put the DTO in session or push all the
values to hidden fields.  In your "setup" action, query the employee
and obtain a DTO.  At this point, populate the form bean (or just
push the DTO to the view) with a form containing the fields of
interest and one hidden field for your employee ID or unique
identifier (or save the ID in session).  Then, on the "save" form,
query the DB for the employee based on the employee ID (you can
protect this in terms of security with a token or other such
measure) then use beanutils to copy the results of the form to that
DTO and save the DTO.

In short, instead of keeping around the DTO, just keep around a key
to get to that DTO, whether in a hidden field or the session.  Then,
you can call up the DTO at any point, update it and push it back to
the persistence layer when you want to save it.  The nice part about
this technique is that your action forms and DTOs don't even have to
align, since you draw what you need out of the form and push it into
your DTO to be saved.

Dan

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
Daniel Allen, <[EMAIL PROTECTED]>
http://www.mojavelinux.com/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
Real programmers just hate to get up in the morning, and 
contrary to Ordinary People, they're in better shape as 
it gets closer to nighttime.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: newbie: Best Practice Struts/Value-Objects?

[Paul McCulloch]

I *think* the other option is to put your form bean (& it's emebedded VO) in
session scope (rather than request which you seems to have at the moment).

Doing this means that the unchanged values on your VO will remain unchanged
(rather than being nulled).

Paul



-Original Message-
From: Darren Hartford [mailto:[EMAIL PROTECTED]
Sent: 03 October 2003 14:26
To: Struts Users Mailing List
Subject: RE: newbie: Best Practice Struts/Value-Objects?


To make sure I understand, the options so far are to:
1. Pass the full VO to the view, create the 15 other fields as hidden tags
within the form, and then on submit Action create a blank VO and populate
with the fields and send to the DB.

2. Pass the full VO to the view, get the 5 fields that are changed from the
form, and then on submit Action re-create the original VO and simply change
the 5 fields within that newly created original and pass that back to the
DB.

3. Create specialized LightVO's that are only the field groupings that will
be changed for that submit Action (and send the LightVO's back to the DB
as-is with the changes from the form).

With #1 I mentioned some concerns with maintanence but some good options
came up on how to work around those. #3 seems the best approach for an
environment that will be setup and not likely to change and the 'end result'
for a good system (aka after there are NO more changes, and we know how
often that is).

But for my scenario/environment, of the options presented it seems #2 is the
best combination for low-maintanence and flexibility to get started on a
project and then as things settle down and performance becomes a motivator
move to #3 (which is an easy migration path).

Does this seem to correctly identify all the options of using Value-Objects
with Struts?

-D


-Original Message-
From: Menke, John [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 02, 2003 3:31 PM
To: 'Struts Users Mailing List'
Subject: RE: newbie: Best Practice Struts/Value-Objects?


Maybe make what we call a displayBean in our app.  It is not a VO as we view
VO's to be more domain oriented.  It's just for the front end.  In your
action create the display bean and set it on the form.   Then in your action
have logic to take values from displayBean and set them in the VO.   We
don't want our API to get crowded with view oriented objects so the
displayBean is kept in the same package as the actions.  VO's are more
domain oriented and can go into API package.

-jm

-Original Message-
From: Darren Hartford [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 02, 2003 2:20 PM
To: Struts Users Mailing List
Subject: RE: newbie: Best Practice Struts/Value-Objects?


Hi John,
Yeah, that is one (messy) solution to my problem. My concern is I would have
to do add those 15 fields in every JSP page that sends the VO back, and if I
have to make a change to the DB/VO, then go back over every JSP page again
to make more changes.

I'm trying to get to as low-maintanence as possible initially, even if it
means sacrificing some performance by not using light-value-objects in the
beginning.  Can always make it faster after it is working correctly, right?
;-)

I'm still lost as to how to handle Struts with Value Objects though
-D

-Original Message-
From: Menke, John [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 02, 2003 12:16 PM
To: 'Struts Users Mailing List'
Subject: RE: newbie: Best Practice Struts/Value-Objects?


you could use hidden variables on your jsp page to store the VO attributes
you are not changing and keep your VO intact only changing the 5 fields

-Original Message-
From: Brian McSweeney [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 02, 2003 11:05 AM
To: 'Struts Users Mailing List'
Subject: RE: newbie: Best Practice Struts/Value-Objects?


Hi Darren,
I was under the impression that it works exactly the way you hope it
does.
Actually I'm pretty sure it does.
Also what might be worth looking at ( I have to look at it myself ), is 
Light-value-objects where you only populate the initial value object
with the 5 fields rather than the whole 20. This is obviously more
optimal in 
terms of db queries.

This is all pre-supposing you are using xdoclet and EJBs and xdoclet,
which
perhaps you are not.

HTH,
Brian

-Original Message-
From: Darren Hartford [mailto:[EMAIL PROTECTED] 
Sent: 02 October 2003 13:41
To: [EMAIL PROTECTED]
Subject: newbie: Best Practice Struts/Value-Objects?

Hi all!
Been working with struts and value-objects, and I am beginning to
understand the power of these two in combination. I did however run into
a snag that may be either on purpose or just ignorance on my part.

If I pass a 20-field value-object to an ActionForm (let's say an
EmployeeVO), and I only show the employee's name and address for editing
(only 5 or so fields).  They make the necessary changes and submit

RE: newbie: Best Practice Struts/Value-Objects?

[Darren Hartford]

To make sure I understand, the options so far are to:
1. Pass the full VO to the view, create the 15 other fields as hidden tags within the 
form, and then on submit Action create a blank VO and populate with the fields and 
send to the DB.

2. Pass the full VO to the view, get the 5 fields that are changed from the form, and 
then on submit Action re-create the original VO and simply change the 5 fields within 
that newly created original and pass that back to the DB.

3. Create specialized LightVO's that are only the field groupings that will be changed 
for that submit Action (and send the LightVO's back to the DB as-is with the changes 
from the form).

With #1 I mentioned some concerns with maintanence but some good options came up on 
how to work around those. #3 seems the best approach for an environment that will be 
setup and not likely to change and the 'end result' for a good system (aka after there 
are NO more changes, and we know how often that is).

But for my scenario/environment, of the options presented it seems #2 is the best 
combination for low-maintanence and flexibility to get started on a project and then 
as things settle down and performance becomes a motivator move to #3 (which is an easy 
migration path).

Does this seem to correctly identify all the options of using Value-Objects with 
Struts?

-D


-Original Message-
From: Menke, John [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 02, 2003 3:31 PM
To: 'Struts Users Mailing List'
Subject: RE: newbie: Best Practice Struts/Value-Objects?


Maybe make what we call a displayBean in our app.  It is not a VO as we view
VO's to be more domain oriented.  It's just for the front end.  In your
action create the display bean and set it on the form.   Then in your action
have logic to take values from displayBean and set them in the VO.   We
don't want our API to get crowded with view oriented objects so the
displayBean is kept in the same package as the actions.  VO's are more
domain oriented and can go into API package.

-jm

-Original Message-
From: Darren Hartford [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 02, 2003 2:20 PM
To: Struts Users Mailing List
Subject: RE: newbie: Best Practice Struts/Value-Objects?


Hi John,
Yeah, that is one (messy) solution to my problem. My concern is I would have
to do add those 15 fields in every JSP page that sends the VO back, and if I
have to make a change to the DB/VO, then go back over every JSP page again
to make more changes.

I'm trying to get to as low-maintanence as possible initially, even if it
means sacrificing some performance by not using light-value-objects in the
beginning.  Can always make it faster after it is working correctly, right?
;-)

I'm still lost as to how to handle Struts with Value Objects though
-D

-Original Message-
From: Menke, John [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 02, 2003 12:16 PM
To: 'Struts Users Mailing List'
Subject: RE: newbie: Best Practice Struts/Value-Objects?


you could use hidden variables on your jsp page to store the VO attributes
you are not changing and keep your VO intact only changing the 5 fields

-Original Message-
From: Brian McSweeney [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 02, 2003 11:05 AM
To: 'Struts Users Mailing List'
Subject: RE: newbie: Best Practice Struts/Value-Objects?


Hi Darren,
I was under the impression that it works exactly the way you hope it
does.
Actually I'm pretty sure it does.
Also what might be worth looking at ( I have to look at it myself ), is 
Light-value-objects where you only populate the initial value object
with the 5 fields rather than the whole 20. This is obviously more
optimal in 
terms of db queries.

This is all pre-supposing you are using xdoclet and EJBs and xdoclet,
which
perhaps you are not.

HTH,
Brian

-Original Message-
From: Darren Hartford [mailto:[EMAIL PROTECTED] 
Sent: 02 October 2003 13:41
To: [EMAIL PROTECTED]
Subject: newbie: Best Practice Struts/Value-Objects?

Hi all!
Been working with struts and value-objects, and I am beginning to
understand the power of these two in combination. I did however run into
a snag that may be either on purpose or just ignorance on my part.

If I pass a 20-field value-object to an ActionForm (let's say an
EmployeeVO), and I only show the employee's name and address for editing
(only 5 or so fields).  They make the necessary changes and submit the
form.  What I understand is the form will populate a NEW EmployeeVO and
not make the changes to the original EmployeeVO, thereby creating an
EmployeeVO populated only from the 5 fields on the form and nulling the
other 15 fields.

I was hoping to take an existing Value-Object, only make necessary
changes from the submitted form (i.e. 0-5 changed fields and the other
15 stay the way they are), and then re-submit the Value-Object for
updating the DB,

RE: newbie: Best Practice Struts/Value-Objects?

[Mark Galbreath]

Could you not, then, consider ActionForms and DynaActionForms xfer objects?

Mark

-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 02, 2003 2:42 PM
To: Struts Users Mailing List
Subject: Re: newbie: Best Practice Struts/Value-Objects?


Value Objects, also called Transfer Objects, are a design pattern. The
idea is that you can minimize the calls to the business tier by
collecting all the data you might need at once and submitting it as a
batch. (Opposed to, say, updating a form a line a time.) The properties
on the Transfer Object might be used by more than one business
component, but you collect them all together to minimize the number of
trips to the business layer.

The ActionForms are a type of Transfer Object. They transfer data
between a HTML form on the presentation layer to the Action on the
controller layer. (But most people would say they should not travel past
the Action.)

Many people also use Transfer Objects on the business layer, and often
the ActionForms and their Transfer Objects will look alot alike.
(Annoyingly so, some might say.) It's commonplace for someone to collect
what they need on an ActionForm and then copy all that over to a
Transfer Object, for submittal to the business layer. Sometimes people
will even nest a Transfer Object on a ActionForm. Another approach is to
have the ActionForm implement the Transfer Object's interface.

If your Transfer Objects and ActionForms share the same protocol (use
the same propert names), you can also pass your Transfer Object directly
to the HTML page. The HTML form tag doesn't care if you use an
ActionForm to populate a form or not, so long as the properties match.

If you kept your ActionForm in session scope, then you could just expose
five fields and keep the others intact. Just watch the that your reset
method doesn't blank them out.

Without using session scope (or a cookie), there is no clean way to
retain the fields without writing them out on the page somehow. One
trick is to use a method that will spit out whatever hidden fields you
need and then just call that using bean:write.

For this use-case, another approach would be to create a more finely
grained business layer. If you only need to update five fields, then you
should be able to update only those five fields. So you would have
another database query that set those five fields, but left the others
alone. The others may exist on the Transfer Object, but the other
database query can just ignore those.

-Ted.


Darren Hartford wrote:
> Hi all!
> Been working with struts and value-objects, and I am beginning to
understand the power of these two in combination. I did however run into a
snag that may be either on purpose or just ignorance on my part.
>
> If I pass a 20-field value-object to an ActionForm (let's say an
EmployeeVO), and I only show the employee's name and address for editing
(only 5 or so fields).  They make the necessary changes and submit the form.
What I understand is the form will populate a NEW EmployeeVO and not make
the changes to the original EmployeeVO, thereby creating an EmployeeVO
populated only from the 5 fields on the form and nulling the other 15
fields.
>
> I was hoping to take an existing Value-Object, only make necessary changes
from the submitted form (i.e. 0-5 changed fields and the other 15 stay the
way they are), and then re-submit the Value-Object for updating the DB, but
that does not seem possible.  Am I doing something wrong and/or
mis-understanding the best utilization of Value-Objects with Struts?  Again,
I'm a newbie so any pointers, help, or examples would be great!
>
> thanky in advance!
> -D
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

--
Ted Husted,
   Junit in Action  - <http://www.manning.com/massol/>,
   Struts in Action - <http://husted.com/struts/book.html>,
   JSP Site Design  - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.




-
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]

RE: newbie: Best Practice Struts/Value-Objects?

[Menke, John]

Maybe make what we call a displayBean in our app.  It is not a VO as we view
VO's to be more domain oriented.  It's just for the front end.  In your
action create the display bean and set it on the form.   Then in your action
have logic to take values from displayBean and set them in the VO.   We
don't want our API to get crowded with view oriented objects so the
displayBean is kept in the same package as the actions.  VO's are more
domain oriented and can go into API package.

-jm

-Original Message-
From: Darren Hartford [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 02, 2003 2:20 PM
To: Struts Users Mailing List
Subject: RE: newbie: Best Practice Struts/Value-Objects?


Hi John,
Yeah, that is one (messy) solution to my problem. My concern is I would have
to do add those 15 fields in every JSP page that sends the VO back, and if I
have to make a change to the DB/VO, then go back over every JSP page again
to make more changes.

I'm trying to get to as low-maintanence as possible initially, even if it
means sacrificing some performance by not using light-value-objects in the
beginning.  Can always make it faster after it is working correctly, right?
;-)

I'm still lost as to how to handle Struts with Value Objects though
-D

-Original Message-
From: Menke, John [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 02, 2003 12:16 PM
To: 'Struts Users Mailing List'
Subject: RE: newbie: Best Practice Struts/Value-Objects?


you could use hidden variables on your jsp page to store the VO attributes
you are not changing and keep your VO intact only changing the 5 fields

-Original Message-
From: Brian McSweeney [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 02, 2003 11:05 AM
To: 'Struts Users Mailing List'
Subject: RE: newbie: Best Practice Struts/Value-Objects?


Hi Darren,
I was under the impression that it works exactly the way you hope it
does.
Actually I'm pretty sure it does.
Also what might be worth looking at ( I have to look at it myself ), is 
Light-value-objects where you only populate the initial value object
with the 5 fields rather than the whole 20. This is obviously more
optimal in 
terms of db queries.

This is all pre-supposing you are using xdoclet and EJBs and xdoclet,
which
perhaps you are not.

HTH,
Brian

-Original Message-
From: Darren Hartford [mailto:[EMAIL PROTECTED] 
Sent: 02 October 2003 13:41
To: [EMAIL PROTECTED]
Subject: newbie: Best Practice Struts/Value-Objects?

Hi all!
Been working with struts and value-objects, and I am beginning to
understand the power of these two in combination. I did however run into
a snag that may be either on purpose or just ignorance on my part.

If I pass a 20-field value-object to an ActionForm (let's say an
EmployeeVO), and I only show the employee's name and address for editing
(only 5 or so fields).  They make the necessary changes and submit the
form.  What I understand is the form will populate a NEW EmployeeVO and
not make the changes to the original EmployeeVO, thereby creating an
EmployeeVO populated only from the 5 fields on the form and nulling the
other 15 fields.

I was hoping to take an existing Value-Object, only make necessary
changes from the submitted form (i.e. 0-5 changed fields and the other
15 stay the way they are), and then re-submit the Value-Object for
updating the DB, but that does not seem possible.  Am I doing something
wrong and/or mis-understanding the best utilization of Value-Objects
with Struts?  Again, I'm a newbie so any pointers, help, or examples
would be great!

thanky in advance!
-D

-
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]

-
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]

Re: newbie: Best Practice Struts/Value-Objects?

[Carey Nation]

Write a tag that emits the hidden stuff.  Put it everywhere.  Then there's
only one maintenence point...



Hi John,
Yeah, that is one (messy) solution to my problem. My concern is I would have
to do add those 15 fields in every JSP page that sends the VO back, and if I
have to make a change to the DB/VO, then go back over every JSP page again
to make more changes.

I'm trying to get to as low-maintanence as possible initially, even if it
means sacrificing some performance by not using light-value-objects in the
beginning.  Can always make it faster after it is working correctly, right?
;-)

I'm still lost as to how to handle Struts with Value Objects though
-D



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: newbie: Best Practice Struts/Value-Objects?

[Ted Husted]

Value Objects, also called Transfer Objects, are a design pattern. The 
idea is that you can minimize the calls to the business tier by 
collecting all the data you might need at once and submitting it as a 
batch. (Opposed to, say, updating a form a line a time.) The properties 
on the Transfer Object might be used by more than one business 
component, but you collect them all together to minimize the number of 
trips to the business layer.

The ActionForms are a type of Transfer Object. They transfer data 
between a HTML form on the presentation layer to the Action on the 
controller layer. (But most people would say they should not travel past 
the Action.)

Many people also use Transfer Objects on the business layer, and often 
the ActionForms and their Transfer Objects will look alot alike. 
(Annoyingly so, some might say.) It's commonplace for someone to collect 
what they need on an ActionForm and then copy all that over to a 
Transfer Object, for submittal to the business layer. Sometimes people 
will even nest a Transfer Object on a ActionForm. Another approach is to 
have the ActionForm implement the Transfer Object's interface.

If your Transfer Objects and ActionForms share the same protocol (use 
the same propert names), you can also pass your Transfer Object directly 
to the HTML page. The HTML form tag doesn't care if you use an 
ActionForm to populate a form or not, so long as the properties match.

If you kept your ActionForm in session scope, then you could just expose 
five fields and keep the others intact. Just watch the that your reset 
method doesn't blank them out.

Without using session scope (or a cookie), there is no clean way to 
retain the fields without writing them out on the page somehow. One 
trick is to use a method that will spit out whatever hidden fields you 
need and then just call that using bean:write.

For this use-case, another approach would be to create a more finely 
grained business layer. If you only need to update five fields, then you 
should be able to update only those five fields. So you would have 
another database query that set those five fields, but left the others 
alone. The others may exist on the Transfer Object, but the other 
database query can just ignore those.

-Ted.

Darren Hartford wrote:
Hi all!
Been working with struts and value-objects, and I am beginning to understand the power 
of these two in combination. I did however run into a snag that may be either on 
purpose or just ignorance on my part.
If I pass a 20-field value-object to an ActionForm (let's say an EmployeeVO), and I only show the employee's name and address for editing (only 5 or so fields).  They make the necessary changes and submit the form.  What I understand is the form will populate a NEW EmployeeVO and not make the changes to the original EmployeeVO, thereby creating an EmployeeVO populated only from the 5 fields on the form and nulling the other 15 fields.

I was hoping to take an existing Value-Object, only make necessary changes from the submitted form (i.e. 0-5 changed fields and the other 15 stay the way they are), and then re-submit the Value-Object for updating the DB, but that does not seem possible.  Am I doing something wrong and/or mis-understanding the best utilization of Value-Objects with Struts?  Again, I'm a newbie so any pointers, help, or examples would be great!

thanky in advance!
-D
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ted Husted,
  Junit in Action  - ,
  Struts in Action - ,
  JSP Site Design  - .


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: newbie: Best Practice Struts/Value-Objects?

[Darren Hartford]

Hi John,
Yeah, that is one (messy) solution to my problem. My concern is I would have to do add 
those 15 fields in every JSP page that sends the VO back, and if I have to make a 
change to the DB/VO, then go back over every JSP page again to make more changes.

I'm trying to get to as low-maintanence as possible initially, even if it means 
sacrificing some performance by not using light-value-objects in the beginning.  Can 
always make it faster after it is working correctly, right? ;-)

I'm still lost as to how to handle Struts with Value Objects though
-D

-Original Message-
From: Menke, John [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 02, 2003 12:16 PM
To: 'Struts Users Mailing List'
Subject: RE: newbie: Best Practice Struts/Value-Objects?


you could use hidden variables on your jsp page to store the VO attributes
you are not changing and keep your VO intact only changing the 5 fields

-Original Message-
From: Brian McSweeney [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 02, 2003 11:05 AM
To: 'Struts Users Mailing List'
Subject: RE: newbie: Best Practice Struts/Value-Objects?


Hi Darren,
I was under the impression that it works exactly the way you hope it
does.
Actually I'm pretty sure it does.
Also what might be worth looking at ( I have to look at it myself ), is 
Light-value-objects where you only populate the initial value object
with the 5 fields rather than the whole 20. This is obviously more
optimal in 
terms of db queries.

This is all pre-supposing you are using xdoclet and EJBs and xdoclet,
which
perhaps you are not.

HTH,
Brian

-Original Message-
From: Darren Hartford [mailto:[EMAIL PROTECTED] 
Sent: 02 October 2003 13:41
To: [EMAIL PROTECTED]
Subject: newbie: Best Practice Struts/Value-Objects?

Hi all!
Been working with struts and value-objects, and I am beginning to
understand the power of these two in combination. I did however run into
a snag that may be either on purpose or just ignorance on my part.

If I pass a 20-field value-object to an ActionForm (let's say an
EmployeeVO), and I only show the employee's name and address for editing
(only 5 or so fields).  They make the necessary changes and submit the
form.  What I understand is the form will populate a NEW EmployeeVO and
not make the changes to the original EmployeeVO, thereby creating an
EmployeeVO populated only from the 5 fields on the form and nulling the
other 15 fields.

I was hoping to take an existing Value-Object, only make necessary
changes from the submitted form (i.e. 0-5 changed fields and the other
15 stay the way they are), and then re-submit the Value-Object for
updating the DB, but that does not seem possible.  Am I doing something
wrong and/or mis-understanding the best utilization of Value-Objects
with Struts?  Again, I'm a newbie so any pointers, help, or examples
would be great!

thanky in advance!
-D

-
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]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: newbie: Best Practice Struts/Value-Objects?

[Menke, John]

you could use hidden variables on your jsp page to store the VO attributes
you are not changing and keep your VO intact only changing the 5 fields

-Original Message-
From: Brian McSweeney [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 02, 2003 11:05 AM
To: 'Struts Users Mailing List'
Subject: RE: newbie: Best Practice Struts/Value-Objects?


Hi Darren,
I was under the impression that it works exactly the way you hope it
does.
Actually I'm pretty sure it does.
Also what might be worth looking at ( I have to look at it myself ), is 
Light-value-objects where you only populate the initial value object
with the 5 fields rather than the whole 20. This is obviously more
optimal in 
terms of db queries.

This is all pre-supposing you are using xdoclet and EJBs and xdoclet,
which
perhaps you are not.

HTH,
Brian

-Original Message-
From: Darren Hartford [mailto:[EMAIL PROTECTED] 
Sent: 02 October 2003 13:41
To: [EMAIL PROTECTED]
Subject: newbie: Best Practice Struts/Value-Objects?

Hi all!
Been working with struts and value-objects, and I am beginning to
understand the power of these two in combination. I did however run into
a snag that may be either on purpose or just ignorance on my part.

If I pass a 20-field value-object to an ActionForm (let's say an
EmployeeVO), and I only show the employee's name and address for editing
(only 5 or so fields).  They make the necessary changes and submit the
form.  What I understand is the form will populate a NEW EmployeeVO and
not make the changes to the original EmployeeVO, thereby creating an
EmployeeVO populated only from the 5 fields on the form and nulling the
other 15 fields.

I was hoping to take an existing Value-Object, only make necessary
changes from the submitted form (i.e. 0-5 changed fields and the other
15 stay the way they are), and then re-submit the Value-Object for
updating the DB, but that does not seem possible.  Am I doing something
wrong and/or mis-understanding the best utilization of Value-Objects
with Struts?  Again, I'm a newbie so any pointers, help, or examples
would be great!

thanky in advance!
-D

-
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]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: newbie: Best Practice Struts/Value-Objects?

[Brian McSweeney]

Hi Darren,
I was under the impression that it works exactly the way you hope it
does.
Actually I'm pretty sure it does.
Also what might be worth looking at ( I have to look at it myself ), is 
Light-value-objects where you only populate the initial value object
with the 5 fields rather than the whole 20. This is obviously more
optimal in 
terms of db queries.

This is all pre-supposing you are using xdoclet and EJBs and xdoclet,
which
perhaps you are not.

HTH,
Brian

-Original Message-
From: Darren Hartford [mailto:[EMAIL PROTECTED] 
Sent: 02 October 2003 13:41
To: [EMAIL PROTECTED]
Subject: newbie: Best Practice Struts/Value-Objects?

Hi all!
Been working with struts and value-objects, and I am beginning to
understand the power of these two in combination. I did however run into
a snag that may be either on purpose or just ignorance on my part.

If I pass a 20-field value-object to an ActionForm (let's say an
EmployeeVO), and I only show the employee's name and address for editing
(only 5 or so fields).  They make the necessary changes and submit the
form.  What I understand is the form will populate a NEW EmployeeVO and
not make the changes to the original EmployeeVO, thereby creating an
EmployeeVO populated only from the 5 fields on the form and nulling the
other 15 fields.

I was hoping to take an existing Value-Object, only make necessary
changes from the submitted form (i.e. 0-5 changed fields and the other
15 stay the way they are), and then re-submit the Value-Object for
updating the DB, but that does not seem possible.  Am I doing something
wrong and/or mis-understanding the best utilization of Value-Objects
with Struts?  Again, I'm a newbie so any pointers, help, or examples
would be great!

thanky in advance!
-D

-
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]