You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Murray Collingwood <mu...@focus-computing.com.au> on 2005/09/12 05:48:45 UTC
Persistence on a form bean?
Hi folks
Getting back to some operational questions...
I want to edit some fields on a record in my database. I have a form bean which
contains all of these fields plus a bunch of other fields that I won't be needing on the
edit form. One of the fields I don't update is the ID property, it is my PRIMARY KEY
and shouldn't be edited.
So I create my DataEditForm action, my DataEdit.jsp and my DataEditSave action.
DataEditForm action retrieves the record (by ID, say "27") from the database and
populates my form bean, saving it as a request attribute.
DataEdit.jsp displays just one text field from this bean (the current value of the field is
displayed in this textbox) and I can edit it quite normally.
DataEditSave action receives the form after editing but fails to update the record as the
ID value now reflects "0" instead of "27".
It seems to me that my DataEdit.jsp is dealing with 2 form beans, a pre-edit version that
contains all of the data and a post-edit version that only contains the information from
the html form.
I know I could create "html:hidden" tags for all of the other fields, however this does
seem a little arcane. I'm wondering if there is another option such as the form bean
being saved pre-edit and restored post-edit and the fields from the html form then being
updated again my form bean before being passed to my DataEditSave action? This
would allow all of the unused fields to retain their true values.
I guess pushing the form bean into the session would do this, but session variables for a
request level function is probably not recommended.
Looking forward to learning...
Kind regards
mc
FOCUS Computing
Mob: 0415 24 26 24
murray@focus-computing.com.au
http://www.focus-computing.com.au
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.10.21/96 - Release Date: 10/09/2005
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Persistence on a form bean?
Posted by Murray Collingwood <mu...@focus-computing.com.au>.
Hi Jan
Yes, this is what I'm doing. This solution (including html:hidden for these fields) does
raise the potential for problems, for example, when I now add a new variable to my
databases / form-bean I have to manually check through all of the JSP files that use
this form-bean and ensure that all fields are included. If I miss one I'm liable to get
some unexpected errors.
What if Struts could include all unused properties when it arrived at the </html:form>,
there are a number of problems with this solution. There may be multiple getters for a
single field, one of which may be included in the form already. There may also be
types in the form-bean for which an html:hidden may not work correctly - my experience
with Timestamp fields is like this.
This leaves the solution of pushing the form-bean into the session. The problem with
this is that every possible link from the page needs to handle the removal of that form-
bean from the session. Otherwise it can hang around in the session and potentially
cause some other problem that might only appear intermittently - the ones you hate the
most!
What I would really like is for request attirbutes to exist for the life of the request.
Consider the name, "form-bean". While not limited to an html form this is probably the
original pupose. It doesn't really matter why I'm writing an html form, in any case it is
always better if the same form-bean I create prior to the user interaction is available
after the user submission. If some component fails (server-side) validation I can simply
push the form-bean back into the request and send a form back to the user that only
displays the fields that failed (rather than viewing all of the form fields again). If I'm
writing a multi-page wizard I can use just one form-bean pushing it from request to
request, and if the user decides to quit the wizard by clicking some other menu item
part way through I'm not going to leave anything undue hanging around in the session.
And after all of that, it just makes good sense.
Alas, I don't think it's going to happen.
I don't know if it is part of any specification but if the current 'request' were modified to
do this we would probably cause problems in thousands of existing applications.
We would probably need to implement a new attribute holder like 'persistingRequest'
that we could push form beans onto, these form beans would be available from the JSP
page using all of the current access methods. This form-bean would need to be
serializable (like a session attribute) and would be restored when the form came back
from the user. The form-bean would be updated with the values from the user,
replacing the restored values. To continue the life of the form-bean it would either be
processed to a database or passed to the next 'persistingRequest', or both.
I've written enough.
mc
On 17 Sep 2005 at 13:53, Jan Fetyko wrote:
> Why not put the ID as a hidden field on the form too, so you SAVE action can read it from the request and update the record with the ID ? It's not hard at all.
>
> J
>
>
> On Mon, 12 Sep 2005 13:48:45 +1000
> "Murray Collingwood" <mu...@focus-computing.com.au> wrote:
>
> > Hi folks
> >
> > Getting back to some operational questions...
> >
> > I want to edit some fields on a record in my database. I have a form bean which
> > contains all of these fields plus a bunch of other fields that I won't be needing on the
> > edit form. One of the fields I don't update is the ID property, it is my PRIMARY
KEY
> > and shouldn't be edited.
> >
> > So I create my DataEditForm action, my DataEdit.jsp and my DataEditSave action.
> >
> > DataEditForm action retrieves the record (by ID, say "27") from the database and
> > populates my form bean, saving it as a request attribute.
> >
> > DataEdit.jsp displays just one text field from this bean (the current value of the field
is
> > displayed in this textbox) and I can edit it quite normally.
> >
> > DataEditSave action receives the form after editing but fails to update the record as
the
> > ID value now reflects "0" instead of "27".
> >
> > It seems to me that my DataEdit.jsp is dealing with 2 form beans, a pre-edit version
that
> > contains all of the data and a post-edit version that only contains the information
from
> > the html form.
> >
> > I know I could create "html:hidden" tags for all of the other fields, however this does
> > seem a little arcane. I'm wondering if there is another option such as the form bean
> > being saved pre-edit and restored post-edit and the fields from the html form then
being
> > updated again my form bean before being passed to my DataEditSave action?
This
> > would allow all of the unused fields to retain their true values.
> >
> > I guess pushing the form bean into the session would do this, but session variables
for a
> > request level function is probably not recommended.
> >
> > Looking forward to learning...
> >
> > Kind regards
> > mc
> >
> >
> > FOCUS Computing
> > Mob: 0415 24 26 24
> > murray@focus-computing.com.au
> > http://www.focus-computing.com.au
> >
> >
> >
> > --
> > No virus found in this outgoing message.
> > Checked by AVG Anti-Virus.
> > Version: 7.0.344 / Virus Database: 267.10.21/96 - Release Date: 10/09/2005
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.344 / Virus Database: 267.10.25/102 - Release Date: 14/09/2005
>
FOCUS Computing
Mob: 0415 24 26 24
murray@focus-computing.com.au
http://www.focus-computing.com.au
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.10.25/102 - Release Date: 14/09/2005
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Persistence on a form bean?
Posted by Jan Fetyko <li...@fetyko.com>.
Why not put the ID as a hidden field on the form too, so you SAVE action can read it from the request and update the record with the ID ? It's not hard at all.
J
On Mon, 12 Sep 2005 13:48:45 +1000
"Murray Collingwood" <mu...@focus-computing.com.au> wrote:
> Hi folks
>
> Getting back to some operational questions...
>
> I want to edit some fields on a record in my database. I have a form bean which
> contains all of these fields plus a bunch of other fields that I won't be needing on the
> edit form. One of the fields I don't update is the ID property, it is my PRIMARY KEY
> and shouldn't be edited.
>
> So I create my DataEditForm action, my DataEdit.jsp and my DataEditSave action.
>
> DataEditForm action retrieves the record (by ID, say "27") from the database and
> populates my form bean, saving it as a request attribute.
>
> DataEdit.jsp displays just one text field from this bean (the current value of the field is
> displayed in this textbox) and I can edit it quite normally.
>
> DataEditSave action receives the form after editing but fails to update the record as the
> ID value now reflects "0" instead of "27".
>
> It seems to me that my DataEdit.jsp is dealing with 2 form beans, a pre-edit version that
> contains all of the data and a post-edit version that only contains the information from
> the html form.
>
> I know I could create "html:hidden" tags for all of the other fields, however this does
> seem a little arcane. I'm wondering if there is another option such as the form bean
> being saved pre-edit and restored post-edit and the fields from the html form then being
> updated again my form bean before being passed to my DataEditSave action? This
> would allow all of the unused fields to retain their true values.
>
> I guess pushing the form bean into the session would do this, but session variables for a
> request level function is probably not recommended.
>
> Looking forward to learning...
>
> Kind regards
> mc
>
>
> FOCUS Computing
> Mob: 0415 24 26 24
> murray@focus-computing.com.au
> http://www.focus-computing.com.au
>
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.344 / Virus Database: 267.10.21/96 - Release Date: 10/09/2005
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Persistence on a form bean?
Posted by Michael Jouravlev <jm...@gmail.com>.
On 9/11/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
> From: "Murray Collingwood" <mu...@focus-computing.com.au>
>
> > I guess pushing the form bean into the session would do this, but session
> > variables for a
> > request level function is probably not recommended.
>
> It is by me. :) Put the form in session scope, and most of your problems
> will disappear. You pick up a couple of new ones, but the tradeoffs are
> generally worth it.
>
> One of my webapps deals exclusively with editing records, and it takes
> several requests to finally complete an edit (or an add). All that time, I
> have a DTO (Value Object... what are we calling them this week?) and a form
> bean in session scope, updating the DTO as necessary until the user hits
> 'Finish'.
>
> The database key is read-only, in fact it's never in the form bean, it gets
> displayed with <c:out> directly from the DTO.
Same here, but instead of DTO I use real business object (BO), nested
in the ActionForm with setters, that accept stringified data. I have
my validation in the BO as well, which I call manually from action
class.
Oh, and I do not use pre-action and post-action, I use just one action
in code-behind/event-dispatch style ;-)
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Persistence on a form bean?
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
There has been an interesting shift lately with people more apt to put
things in session. I think a lot of it stems from what newer frameworks
are doing and people taking some cues from them. There are certainly
some obvious advantages, and the old disadvantages aren't nearly as big
a deal as they used to be.
The one thing I always like to point out however is that you cnn really
make a bad choice if you don't work in a clustered environment. Many
people still work in single-server environments. In such a situation,
putting more in session almost entirely comes down to just dumping more
memory in the server. Very little else matters a whole lot.
In a clustered environment though, you want to be a whole lot more
careful. More importantly, even if you are in a single-server situation
now, carefully consider what happens if you move to a multi-server
environment (I know, this happened to me!). Session replication across
nodes can come back to haunt you big-time.
Of course, it's always a matter of trade-offs... is that session
replication going to be better or worse than continually hitting a
database to regenerate a dataset if you are doing things per-request?
There's no general-purpose right or wrong answers.
The one pointer I give people about this is to carefully consider what
you are thinking of putting in session, and ultimately put as little as
possible, but put enough to have a tangible benefit. If your doing a
wizard-like interface as Wendy describes, you can either store the built
up data in session, or you can pass it around between requests, or you
can put it in a database or other persistent store temporarily. The
session option winds up being the best in most cases, in terms of
performance, simplicity and server load.
Frank
Murray Collingwood wrote:
> Two responses and both suggesting I push all my beans into the session scope.
>
> This really does beg the question, what purpose is the request scope for a bean? My
> only answer was display-only material. Is this really how it was designed?
>
> Sorry to be asking so many design questions but I really find it hard to understand that
> after all of these years (of Object Oriented Design) we are still using globals to store
> values that are processed through one form.
>
> Kind regards
> mc
>
>
> On 11 Sep 2005 at 21:13, Wendy Smoak wrote:
>
>
>>From: "Murray Collingwood" <mu...@focus-computing.com.au>
>>
>>>I guess pushing the form bean into the session would do this, but session
>>>variables for a
>>>request level function is probably not recommended.
>>
>>It is by me. :) Put the form in session scope, and most of your problems
>>will disappear. You pick up a couple of new ones, but the tradeoffs are
>>generally worth it.
>>
>>One of my webapps deals exclusively with editing records, and it takes
>>several requests to finally complete an edit (or an add). All that time, I
>>have a DTO (Value Object... what are we calling them this week?) and a form
>>bean in session scope, updating the DTO as necessary until the user hits
>>'Finish'.
>>
>>The database key is read-only, in fact it's never in the form bean, it gets
>>displayed with <c:out> directly from the DTO.
>>
>>--
>>Wendy Smoak
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>>
>>--
>>No virus found in this incoming message.
>>Checked by AVG Anti-Virus.
>>Version: 7.0.344 / Virus Database: 267.10.21/96 - Release Date: 10/09/2005
>>
>
>
>
>
> FOCUS Computing
> Mob: 0415 24 26 24
> murray@focus-computing.com.au
> http://www.focus-computing.com.au
>
>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Persistence on a form bean?
Posted by Murray Collingwood <mu...@focus-computing.com.au>.
Two responses and both suggesting I push all my beans into the session scope.
This really does beg the question, what purpose is the request scope for a bean? My
only answer was display-only material. Is this really how it was designed?
Sorry to be asking so many design questions but I really find it hard to understand that
after all of these years (of Object Oriented Design) we are still using globals to store
values that are processed through one form.
Kind regards
mc
On 11 Sep 2005 at 21:13, Wendy Smoak wrote:
> From: "Murray Collingwood" <mu...@focus-computing.com.au>
>
> > I guess pushing the form bean into the session would do this, but session
> > variables for a
> > request level function is probably not recommended.
>
> It is by me. :) Put the form in session scope, and most of your problems
> will disappear. You pick up a couple of new ones, but the tradeoffs are
> generally worth it.
>
> One of my webapps deals exclusively with editing records, and it takes
> several requests to finally complete an edit (or an add). All that time, I
> have a DTO (Value Object... what are we calling them this week?) and a form
> bean in session scope, updating the DTO as necessary until the user hits
> 'Finish'.
>
> The database key is read-only, in fact it's never in the form bean, it gets
> displayed with <c:out> directly from the DTO.
>
> --
> Wendy Smoak
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.344 / Virus Database: 267.10.21/96 - Release Date: 10/09/2005
>
FOCUS Computing
Mob: 0415 24 26 24
murray@focus-computing.com.au
http://www.focus-computing.com.au
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.10.23/99 - Release Date: 12/09/2005
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Persistence on a form bean?
Posted by Wendy Smoak <ja...@wendysmoak.com>.
From: "Murray Collingwood" <mu...@focus-computing.com.au>
> I guess pushing the form bean into the session would do this, but session
> variables for a
> request level function is probably not recommended.
It is by me. :) Put the form in session scope, and most of your problems
will disappear. You pick up a couple of new ones, but the tradeoffs are
generally worth it.
One of my webapps deals exclusively with editing records, and it takes
several requests to finally complete an edit (or an add). All that time, I
have a DTO (Value Object... what are we calling them this week?) and a form
bean in session scope, updating the DTO as necessary until the user hits
'Finish'.
The database key is read-only, in fact it's never in the form bean, it gets
displayed with <c:out> directly from the DTO.
--
Wendy Smoak
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org