|
Ok, thanks Hubert - this confirms that I will have to do what I want another way.
Cheers
Conrad
Conrad Crampton Software Solutions Manager Force Headquarters 11 Edinburgh Square Sutton Road Maidstone ME15 9BZ 01622 653283 (ext) 19-3283 (internal) 07814 011752 (mobile) >>> [EMAIL PROTECTED] 20/01/05 15:36:03 >>> Our views align on the use of session scoped beans, however, it seems that session scope is what meets your needs. <quote> > So this essentially means that nested objects are worthless as you can't > keep reference to child objects that you populate in the middle tier for the > trip around to the UI and back again. </quote> You want the form to retain the reference to your object from the time you prepare the form in the action leading to the JSP, all the way to the action that responds when the form is submitted. This span goes beyond one request, and that is why request scope fails you. The form you created will only last until the form is shown. While you're rendering your JSP, you have access to everything you put in your form. However, after the JSP has been sent to the browser, the request is also done, and you lose everything you put in request scope. When the form is submitted, a new request begins, with a fresh scope. <quote> > What I find frustrating that the form bean > that is in scope that populated the editable fields, doesn't just get those > values repopulated with any changes but leaves the rest of the form bean as > it was on initial population. </quote> If your bean was placed on request scope, there is nothing to repopulate, because after the JSP is rendered, the form bean is lost. If you want to retain the bean after the life of the request, put it in session scope. hth, Hubert On Thu, 20 Jan 2005 15:21:28 +0000, Conrad CRAMPTON PSE 52704 <[EMAIL PROTECTED]> wrote: > > > > > Conrad Crampton > Software Solutions Manager > Force Headquarters > 11 Edinburgh Square > Sutton Road > Maidstone > ME15 9BZ > 01622 653283 (ext) > 19-3283 (internal) > 07814 011752 (mobile) > > >>> [EMAIL PROTECTED] 19/01/05 16:07:49 >>> > > > So the question is this - how do I retain values of nested properties that > > aren't required to be (or cannot be) represented in the jsp? > > >>The only values that you'll get when the form is submitted are the > >>values that the form has. > >>If you have values that you want to submit with the form, but don't > >>want them displayed to the user, look at hidden fields <html:hidden/>. > > So this essentially means that nested objects are worthless as you can't > keep reference to child objects that you populate in the middle tier for the > trip around to the UI and back again. I am using Hibernate for persistence > so have the object graph that am providing the UI for updates that has child > collections etc. Populating the form bean with the parent class I would have > thought could be 'round-tripped' back to the middle tier with the child > objects still attached to the object. > > > > It appears that > > the value of premises is always null and not using what is in the request > > scope when the jsp is submitted. > > >>Roughly, a "request" begins when the browser asks for information from > >>the server, and ends when the server has supplied that information. > >>After you've created your Premises object and displayed it on your > >>JSP's form, the request is done. When the user submits the form, that > >>counts as another request, a new, empty, fresh one, with nothing yet > >>in its scope, except for the data that comes with the form being > >>submitted. > > yes, I realise how the http protocol work for requests but the struts > documentation appears to bat on about if there is a form bean already in the > current scope (and it is for the current request), then this should be used > - this is obviously being done for the properties that are visible HTML > elements as I can see the data. What I find frustrating that the form bean > that is in scope that populated the editable fields, doesn't just get those > values repopulated with any changes but leaves the rest of the form bean as > it was on initial population. > > >>If you want your form to persist between requests, put your form in > >>session scope. Take a look at > >>http://java.sun.com/developer/EJTechTips/2003/tt1209.html#2 for a > >>better explanation of the differences between scopes. > > I understand what scopes are and this is why I was using request. I didn't > want the overhead of having to keep removing transient data from session > scope. IMHO it is lazy and potentially conducive to bugs to throw everything > into session scope. If you fail to clear up properly then it can lead to > problems. My team are currently working on a large Struts app that puts > everything into session and is having numerous problems with what appears to > be session data being lost. > > >>Here's another link that might help you manage your form data, > >>particularly collections that you may place in <select> controls: > >>http://www.reumann.net/struts/articles/request_lists.jsp > > >>hth, > >>Hubert > > Thanks for the response though > Conrad > > > > On Wed, 19 Jan 2005 13:02:20 +0000, Conrad CRAMPTON PSE 52704 > <[EMAIL PROTECTED]> wrote: > > > > Hi, > > The list archive search doesn't appear to work to forgive me if this is a > > simple and already answered topic. > > > > I have an actionform that has an object as a property - Premises premises, > > and a jsp that uses <html:text name="Premises" property="premises.name" > />. > > When I use createPremises.jsp all is ok and the values for premises get > > through to my action no problem. > > > > The problem I have though is when I want to edit premises. The action > > (extending Dispatchaction) viz... > > > > public ActionForward edit(ActionMapping mapping, ActionForm form, > > HttpServletRequest request, HttpServletResponse response) throws > > IOException, ServletException { > > PremisesForm premForm = (PremisesForm) form; > > String returnMapping = "edit"; > > Long id = null; > > if (request.getParameter("id") != null) > > id = new Long(request.getParameter("id")); > > if (id == null) > > id = (Long) request.getAttribute("id"); > > try { > > PremisesDAO pdao = new PremisesDAO(); > > Premises prem = pdao.getPremises(id); > > premForm.setPremises(prem); > > premForm.setOwner(prem.getOwner()); > > request.setAttribute("Premises", premForm); > > } catch (DataAccessException e) { > > e.printStackTrace(); > > returnMapping = "error"; > > request.setAttribute("error", e.getMessage()); > > } > > return mapping.findForward(returnMapping); > > } > > > > which fine and sets the PremisesForm premises attribute correctly. > > However when this gets submitted ultimately from the jsp, the properties > of > > premises that aren't html:text elements in my jsp aren't being retained. > > e.g. id (primary key of premises from db, and other things like > collections > > of other pojo's in premises. > > > > So the question is this - how do I retain values of nested properties that > > aren't required to be (or cannot be) represented in the jsp? It appears > that > > the value of premises is always null and not using what is in the request > > scope when the jsp is submitted. > > > > I am sure this is simple answer but I just can't get it! > > > > TIA > > Conrad > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] |
This Email and any accompanying document(s) contain information from Kent Police, which is confidential or privileged. The information is intended to be for the exclusive use of the individual(s) or bodies to whom it is addressed. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this Email in error please notify us by telephone immediately. The copyright in the contents of this email and any enclosures is the property of Kent Police and any unauthorised reproduction or disclosure is contrary to the provisions of the Copyright Designs and Patents Act 1988.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
