You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Martin Ahrer <ma...@gmx.at> on 2007/12/28 19:59:08 UTC
Is this a problem that stems from JSF life-cycle
I'm trying to implement a simple table for selecting a table row and editing
the selected row in a form in a different way than I did it before. Table
and form are rendered through the same JSP (see below) such that no
navigation rules are required.
This does not behave as expected-> when a row is selected, its data is shown
in the form. After returning back to the table and selecting a different
row, the form shows the same row data as before BUT NOT the data for the new
selection.
So I assume there is a problem with the component state??? I have modified
the implementation such that the form is implemented by a different JSP and
a navigation rule navigates to this form JSP as #{listController.select} is
invoked! ->> It works!
Background info for the used managed beans: #{listController.select} is
responsible for getting the selected row object and injecting it into
#{formController.entity}. The listController is a request scope bean whereas
the formController is a session scope bean.
<tr:form>
<tr:table value="#{listController.model}" var="object"
rendered="#{formController.entity==null}">
<tr:column>
<tr:commandLink action="#{listController.select}">
<tr:outputText value="#{object.type}" />
</tr:commandLink>
</tr:column>
</tr:table>
<tr:panelFormLayout rendered="#{formController.entity!=null}">
<tr:outputLabel for="typeInput" value="Type" />
<tr:inputText id="typeInput" value="#{formController.entity.type}" />
<tr:commandButton text="OK" action="#{formController.store}" id="okButton"
/>
<tr:commandButton text="CANCEL" action="#{formController.cancel}"
immediate="true" />
</tr:panelFormLayout>
</tr:form>
listController.select is implemented like shown below
public String select() {
setSelectedEntity((T) getDataModel().getRowData());// this injects the
selected object into the form controller
return OUTCOME_SELECT;
}
The JSPs have been implemented using Trinidad, my assumption is that this is
not a Trinidad issue but rather a general JSF life cycle issue!
-----
http://www.martinahrer.at/blog http://www.martinahrer.at/blog
--
View this message in context: http://www.nabble.com/Is-this-a-problem-that-stems-from-JSF-life-cycle-tp14530054p14530054.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: Is this a problem that stems from JSF life-cycle
Posted by Martin Ahrer <ma...@gmx.at>.
David,
this did the trick, I created a navigation rule like from-view-id a.jsp
to-view-id a.jsp. Now the form is updated to reflect the latest row
selection.
David Delbecq-2 wrote:
>
> That's because form's component are keeping their submitted values. It's
> probably linked to the correct backing bean, but the form components
> does display the submitted values if there is any. If no submitted value
> does exist, the data from backing bean is used. To reset the submitted
> values, a navigation rule must occur AFAIK. It can done with a "to same
> form" rule. Without a navigation rule, JSF considers your are still
> editing the same form.
> Martin Ahrer a écrit :
>> I'm trying to implement a simple table for selecting a table row and
>> editing
>> the selected row in a form in a different way than I did it before. Table
>> and form are rendered through the same JSP (see below) such that no
>> navigation rules are required.
>> This does not behave as expected-> when a row is selected, its data is
>> shown
>> in the form. After returning back to the table and selecting a different
>> row, the form shows the same row data as before BUT NOT the data for the
>> new
>> selection.
>>
>> So I assume there is a problem with the component state??? I have
>> modified
>> the implementation such that the form is implemented by a different JSP
>> and
>> a navigation rule navigates to this form JSP as #{listController.select}
>> is
>> invoked! ->> It works!
>>
>> Background info for the used managed beans: #{listController.select} is
>> responsible for getting the selected row object and injecting it into
>> #{formController.entity}. The listController is a request scope bean
>> whereas
>> the formController is a session scope bean.
>>
>> <tr:form>
>> <tr:table value="#{listController.model}" var="object"
>> rendered="#{formController.entity==null}">
>> <tr:column>
>> <tr:commandLink action="#{listController.select}">
>> <tr:outputText value="#{object.type}" />
>> </tr:commandLink>
>> </tr:column>
>> </tr:table>
>> <tr:panelFormLayout rendered="#{formController.entity!=null}">
>> <tr:outputLabel for="typeInput" value="Type" />
>> <tr:inputText id="typeInput" value="#{formController.entity.type}" />
>> <tr:commandButton text="OK" action="#{formController.store}"
>> id="okButton"
>> />
>> <tr:commandButton text="CANCEL" action="#{formController.cancel}"
>> immediate="true" />
>> </tr:panelFormLayout>
>> </tr:form>
>>
>> listController.select is implemented like shown below
>>
>> public String select() {
>> setSelectedEntity((T) getDataModel().getRowData());// this injects the
>> selected object into the form controller
>> return OUTCOME_SELECT;
>> }
>>
>>
>> The JSPs have been implemented using Trinidad, my assumption is that this
>> is
>> not a Trinidad issue but rather a general JSF life cycle issue!
>>
>> -----
>> http://www.martinahrer.at/blog http://www.martinahrer.at/blog
>>
>
>
>
-----
http://www.martinahrer.at/blog http://www.martinahrer.at/blog
--
View this message in context: http://www.nabble.com/Is-this-a-problem-that-stems-from-JSF-life-cycle-tp14530054p14558475.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: Is this a problem that stems from JSF life-cycle
Posted by simon <si...@chello.at>.
Yes, David has a good point.
The behaviour described is probably happening because you are actually
getting a validation failure when selecting a new table row, ie:
A row is selected in the table
Form is submitted, and new page rendered
User now selects a different row
The form is submitted, but validation fails for some reason.
The new page is therefore rendered with the old data
Do you have an h:messages tag in your page so you can see validation
error messages?
When a user enters invalid data and submits a form, the behaviour
usually desired is for the page to be redisplayed with the same data the
user entered, so that a user does not "lose" their input. Error messages
are displayed to tell them which fields they need to fix. So this is
what JSF does by default; when any error occurs editable components (eg
h:inputText fields) internally store the value they had previously, and
redisplay that rather than getting fresh data from the model objects.
The way to disable this default JSF behaviour is to perform a
*navigation* to a new view (ie creating fresh components which have no
old user data in them), rather than returning to the same view.
Regards,
Simon
On Sun, 2007-12-30 at 12:49 +0100, david delbecq wrote:
> That's because form's component are keeping their submitted values. It's
> probably linked to the correct backing bean, but the form components
> does display the submitted values if there is any. If no submitted value
> does exist, the data from backing bean is used. To reset the submitted
> values, a navigation rule must occur AFAIK. It can done with a "to same
> form" rule. Without a navigation rule, JSF considers your are still
> editing the same form.
> Martin Ahrer a écrit :
> > I'm trying to implement a simple table for selecting a table row and editing
> > the selected row in a form in a different way than I did it before. Table
> > and form are rendered through the same JSP (see below) such that no
> > navigation rules are required.
> > This does not behave as expected-> when a row is selected, its data is shown
> > in the form. After returning back to the table and selecting a different
> > row, the form shows the same row data as before BUT NOT the data for the new
> > selection.
> >
> > So I assume there is a problem with the component state??? I have modified
> > the implementation such that the form is implemented by a different JSP and
> > a navigation rule navigates to this form JSP as #{listController.select} is
> > invoked! ->> It works!
> >
> > Background info for the used managed beans: #{listController.select} is
> > responsible for getting the selected row object and injecting it into
> > #{formController.entity}. The listController is a request scope bean whereas
> > the formController is a session scope bean.
> >
> > <tr:form>
> > <tr:table value="#{listController.model}" var="object"
> > rendered="#{formController.entity==null}">
> > <tr:column>
> > <tr:commandLink action="#{listController.select}">
> > <tr:outputText value="#{object.type}" />
> > </tr:commandLink>
> > </tr:column>
> > </tr:table>
> > <tr:panelFormLayout rendered="#{formController.entity!=null}">
> > <tr:outputLabel for="typeInput" value="Type" />
> > <tr:inputText id="typeInput" value="#{formController.entity.type}" />
> > <tr:commandButton text="OK" action="#{formController.store}" id="okButton"
> > />
> > <tr:commandButton text="CANCEL" action="#{formController.cancel}"
> > immediate="true" />
> > </tr:panelFormLayout>
> > </tr:form>
> >
> > listController.select is implemented like shown below
> >
> > public String select() {
> > setSelectedEntity((T) getDataModel().getRowData());// this injects the
> > selected object into the form controller
> > return OUTCOME_SELECT;
> > }
> >
> >
> > The JSPs have been implemented using Trinidad, my assumption is that this is
> > not a Trinidad issue but rather a general JSF life cycle issue!
> >
> > -----
> > http://www.martinahrer.at/blog http://www.martinahrer.at/blog
> >
>
Re: Is this a problem that stems from JSF life-cycle
Posted by david delbecq <de...@oma.be>.
That's because form's component are keeping their submitted values. It's
probably linked to the correct backing bean, but the form components
does display the submitted values if there is any. If no submitted value
does exist, the data from backing bean is used. To reset the submitted
values, a navigation rule must occur AFAIK. It can done with a "to same
form" rule. Without a navigation rule, JSF considers your are still
editing the same form.
Martin Ahrer a écrit :
> I'm trying to implement a simple table for selecting a table row and editing
> the selected row in a form in a different way than I did it before. Table
> and form are rendered through the same JSP (see below) such that no
> navigation rules are required.
> This does not behave as expected-> when a row is selected, its data is shown
> in the form. After returning back to the table and selecting a different
> row, the form shows the same row data as before BUT NOT the data for the new
> selection.
>
> So I assume there is a problem with the component state??? I have modified
> the implementation such that the form is implemented by a different JSP and
> a navigation rule navigates to this form JSP as #{listController.select} is
> invoked! ->> It works!
>
> Background info for the used managed beans: #{listController.select} is
> responsible for getting the selected row object and injecting it into
> #{formController.entity}. The listController is a request scope bean whereas
> the formController is a session scope bean.
>
> <tr:form>
> <tr:table value="#{listController.model}" var="object"
> rendered="#{formController.entity==null}">
> <tr:column>
> <tr:commandLink action="#{listController.select}">
> <tr:outputText value="#{object.type}" />
> </tr:commandLink>
> </tr:column>
> </tr:table>
> <tr:panelFormLayout rendered="#{formController.entity!=null}">
> <tr:outputLabel for="typeInput" value="Type" />
> <tr:inputText id="typeInput" value="#{formController.entity.type}" />
> <tr:commandButton text="OK" action="#{formController.store}" id="okButton"
> />
> <tr:commandButton text="CANCEL" action="#{formController.cancel}"
> immediate="true" />
> </tr:panelFormLayout>
> </tr:form>
>
> listController.select is implemented like shown below
>
> public String select() {
> setSelectedEntity((T) getDataModel().getRowData());// this injects the
> selected object into the form controller
> return OUTCOME_SELECT;
> }
>
>
> The JSPs have been implemented using Trinidad, my assumption is that this is
> not a Trinidad issue but rather a general JSF life cycle issue!
>
> -----
> http://www.martinahrer.at/blog http://www.martinahrer.at/blog
>