You are viewing a plain text version of this content. The canonical link for it is here.
Posted to adffaces-user@incubator.apache.org by Adam Winer <aw...@gmail.com> on 2007/01/20 20:21:45 UTC
Re: tr:inputText disabled="true" & pageFlowScope
On 1/19/07, Mark Dopheide <md...@qwizics.com> 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 <h:inputHidden
> 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" <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
>
>
RE: tr:inputText disabled="true" & pageFlowScope
Posted by Mark Dopheide <md...@qwizics.com>.
Adam,
Well, clearly I'm the one confused but I can't see my way beyond it.
My backing bean does this:
RequestContext requestContext = RequestContext.getCurrentInstance();
requestContext.getPageFlowScope().put("registration", registration);
// ex: registration.candidateId = 111;
My view has this readOnly tag:
<tr:inputText id="regCode"
label="#{text['registration.candidateId']} : "
value="#{pageFlowScope.registration.candidateId}"
readOnly="true"
/>
When the form is submitted, I retrieve it in the postback:
Registration registration = (Registration)
app.getVariableResolver().resolveVariable(context, "registration");
However, the registration.candidateId = 0, the attributes that are NOT
readOnly DO have their attributes preserved correctly.
It seems simple enough but apparently something is erroneous, though I have
no clue as to what it is. I assume I don't need managed-property for this in
my faces-config.xml file.
Thanks again for any insights...
Mark
-----Original Message-----
From: Adam Winer [mailto:awiner@gmail.com]
Sent: Saturday, January 20, 2007 3:24 PM
To: adffaces-user@incubator.apache.org
Subject: Re: tr:inputText disabled="true" & pageFlowScope
Mark,
I'm confused about the problem. Since you've disabled the field, JSF won't
write the value back to the EL target. OTOH, since that value was
originally retrieved from pageFlowScope, it'll still be there on postback.
So it doesn't seem that you should be any worse-off on the postback. What
am I missing?
-- Adam
On 1/20/07, Adam Winer <aw...@gmail.com> wrote:
> On 1/19/07, Mark Dopheide <md...@qwizics.com> 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 <h:inputHidden
> > 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" <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/communicatingBetweenPa
> > ges.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
> >
> >
>
Re: tr:inputText disabled="true" & pageFlowScope
Posted by Adam Winer <aw...@gmail.com>.
Mark,
I'm confused about the problem. Since you've disabled
the field, JSF won't write the value back to the EL
target. OTOH, since that value was originally retrieved
from pageFlowScope, it'll still be there on postback.
So it doesn't seem that you should be any worse-off
on the postback. What am I missing?
-- Adam
On 1/20/07, Adam Winer <aw...@gmail.com> wrote:
> On 1/19/07, Mark Dopheide <md...@qwizics.com> 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 <h:inputHidden
> > 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" <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
> >
> >
>