incubator-adffaces-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gvanma...@comcast.net (Gary VanMatre)
Subject Re: tr:inputText disabled="true" & pageFlowScope
Date Sat, 20 Jan 2007 04:29:06 GMT
>From: "Mark Dopheide" <md@qwizics.com> 
>
> 
> 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
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message