From adffaces-user-return-1940-apmail-incubator-adffaces-user-archive=incubator.apache.org@incubator.apache.org Sat Jan 20 20:22:11 2007 Return-Path: Delivered-To: apmail-incubator-adffaces-user-archive@locus.apache.org Received: (qmail 19204 invoked from network); 20 Jan 2007 20:22:11 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 20 Jan 2007 20:22:11 -0000 Received: (qmail 69138 invoked by uid 500); 20 Jan 2007 20:22:17 -0000 Delivered-To: apmail-incubator-adffaces-user-archive@incubator.apache.org Received: (qmail 69118 invoked by uid 500); 20 Jan 2007 20:22:17 -0000 Mailing-List: contact adffaces-user-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: adffaces-user@incubator.apache.org Delivered-To: mailing list adffaces-user@incubator.apache.org Received: (qmail 69109 invoked by uid 99); 20 Jan 2007 20:22:17 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 20 Jan 2007 12:22:17 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of awiner@gmail.com designates 66.249.92.171 as permitted sender) Received: from [66.249.92.171] (HELO ug-out-1314.google.com) (66.249.92.171) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 20 Jan 2007 12:22:08 -0800 Received: by ug-out-1314.google.com with SMTP id y2so866988uge for ; Sat, 20 Jan 2007 12:21:46 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=TxFxr1P7ZyuKSRvRyLwvOi7rlkfy4VQ8Btku0Wm8aljw/Zof1ljuHtVGNdR5cQDdrwXfIgOqa+RkRQFx/PlUTl2H5UdhrCdNzYnxkpVQBE4mmZA/WEF994ZIwkD0H9zc8Imic6ZJPCdKdDIm+G8GC8TPlmch9HlWgY95C6V5Qhc= Received: by 10.67.119.9 with SMTP id w9mr5134559ugm.1169324505767; Sat, 20 Jan 2007 12:21:45 -0800 (PST) Received: by 10.67.99.17 with HTTP; Sat, 20 Jan 2007 12:21:45 -0800 (PST) Message-ID: <6dac79b90701201221i26bb72d8x75413a10f110b796@mail.gmail.com> Date: Sat, 20 Jan 2007 12:21:45 -0800 From: "Adam Winer" To: adffaces-user@incubator.apache.org Subject: Re: tr:inputText disabled="true" & pageFlowScope In-Reply-To: <20070120063649.CFA6110FB000@herse.apache.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <012020070429.6192.45B19A8C000EF0AE0000183022070208530A9D9B0E03020E9009@comcast.net> <20070120063649.CFA6110FB000@herse.apache.org> X-Virus-Checked: Checked by ClamAV on apache.org On 1/19/07, Mark Dopheide wrote: > Gary, > > Yes, essentially you have captured what I am trying to do. The crux of the > problem is where you say: > >If your user object already has a value in the "candidateId" property, a > disabled input component won't > >update the property. Your "candidateId" in the user object should keep the > prepopulated value and be > >ready to save. > > What's happening is that when my User object is retrieved from the edit > detail view with this: > Registration registration = (Registration) > getRequest().getAttribute("registration"); > > the prepopulated but disabled (or readOnly) attributes that are not intended > to be edited do not have the expected values (i.e. instead of "1111" for > candidateId the backing bean gets "0"). Now I surmise that this is because > validation is not performed on these readOnly attributes, but I would really > like to find an elegant way of maintaining these values in the object that > is returned from the view. Again, if I add value="#pageFlowScope.registration.candidateId).../> then these attributes > are maintained but then my keyboard gets that cramp again ;) > > If only half of the attributes in my object are intended to be edited and > that object is retrieved from the view then what? Am I forced to write code > to transfer the "missing" or modified attributes back into my hibernate > managed object? Having hidden inputs in my HTML just seems so "wrong" .... > > > Mark > > -----Original Message----- > From: Gary VanMatre [mailto:gvanmatre@comcast.net] > Sent: Friday, January 19, 2007 11:29 PM > To: adffaces-user@incubator.apache.org > Subject: Re: tr:inputText disabled="true" & pageFlowScope > > >From: "Mark Dopheide" > > > > > > Guidance required on this issue... > > > > Realizing that when using tr:inputText and pageFlowScope (or > > saveState) the readOnly (or disabled) attributes do not get submitted > > to the backing bean as to the model, then... > > > > What is recommended practice when these "disabled" values are to be > > persisted? For example, if I am using pageFlowScope and in my backing > > bean has something like: > > User user = (User) app.getVariableResolver().resolveVariable(context, > > "user"); > > > > And my web pages contains: > > > label="#{text['registration.candidateId']} : " > > value="#{pageFlowScope.registration.candidateId}" > > disabled="true" > > contentStyle="margin: 1em 0 0 0;color: blue" > > required="true"/> > > > > then this "regCode" attribute that is declared "readOnly" does not > > appear in my User model in the backing bean. This is kind of a pain in > > the keyboard > > ;^) > > > "pain in the keyboard"... Ha! Now that's funny! > > > What is recommended practice in these situations? Certainly > on the > > disabled attributes is possible but this seems to lack the elegance that I > would expect. > > > > I mean when using hibernate, etc I would just like to get the model > > (my > > POJO) back from the view and do a userManager.save(user) but when > > readOnly attributes are vacant then this isn't as easy as I think it > should be. > > Having a view object that gets transferred to my POJO just seems like > > so much unnecessary code. > > > > Any tips or hints on best practices related to this issue would be > > greatly appreciated... > > > > I was looking at the pageFlowScope the other day and found some good > documentation. You might have already seen this: > http://incubator.apache.org/adffaces/devguide/communicatingBetweenPages.html > > It sounds like this scope is more granular than session scope but greater > than request. They are some how passing around a token in request that > identifies a new browser window or "dialog". You have to stage the data in > this scope yourself like you might with session or request. > > In your example above, you would find the user object as a managed bean or > maybe a spring bean. > User user = (User) app.getVariableResolver().resolveVariable(context, > "user"); > Lets say that we set the id using code instead of setter injection. > user.setCandidateId("1111111"); > You would then use the trinidad context to push your user object into > pageFlowScope. > RequestContext requestContext = RequestContext.getCurrentInstance(); > requestContext.getPageFlowScope().put("registration", user); > Your user object should exist in "pageFlowScope" until you terminate the > dialog or your session times out. If your user object already has a value > in the "candidateId" property, a disabled input component won't update the > property. Your "candidateId" in the user object should keep the > prepopulated value and be ready to save. > Does that sound correct? > > > > > > > Best regards to all, > > > > Mark > > > Gary > >