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" <[EMAIL PROTECTED]> 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 > > [EMAIL PROTECTED] > > 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > -- > 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
