myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Delbecq <de...@oma.be>
Subject Re: Reset of forms
Date Fri, 15 Sep 2006 10:44:46 GMT
I wanted confirmation due to a list of items not showing as they should
after navigation until i renavigate again to  the page.

However, investigations have shown it's a transaction error in another
library that lead to the list of rebuild bean to still show old values
until transaction is commited.

Thanks for the confirmation :)

Gert Vanthienen a écrit :
> David,
>
> Normally you should be able to get the behavior you're describing by
> using a navigation rule to the same page.  In the render response
> phase, a response component tree should be built, based upon the
> updated values in backing bean.  This way, components that available
> in some conditions only, should appear/disappear from the component
> tree appropriately.  Are you experiencing any problems with this,
> because in my opinion it should work?
>
> Regards,
>
> Gert Vanthienen
> gert@anova.be
>
> David Delbecq wrote:
>> Hi,
>> the backing bean are being modified by the action, exactly as you
>> suggest (except more over they are request scope and rebuild at each
>> request, as very dependant on some database values). My problem is to be
>> sure that the old components, which have local values, won't be used
>> anymore after the action and that the form will be reconstructed. I need
>> this because i have composite components that create childrens. Their
>> children tree are very dependant on the bean value. switching from one
>> bean value to another means a  very different children tree.
>>
>> So am wondering if a navigation rule to self was enough to warranty
>> rebuild of forms in the page.
>> Gert Vanthienen a écrit :
>>  
>>> David,
>>>
>>> Wouldn't it be an option to create an backing bean containing your
>>> data object?  You could store this containing bean in the session
>>> using JSF bean management and let it manage the lifecycle of the data
>>> object it contains.  Your action method would have access to the
>>> correct state of the data object and would it be able to
>>> dispose/recreate it whenever your application requires it do so.
>>> Something like...
>>>
>>> public class BusinessObjectHolder() {
>>>    private BusinessObject object = new BusinessObject();
>>>    //getters and setters for the object
>>>
>>>    public String action() {
>>>       //validate and save the object
>>>       //or call whatever business logic is necessary;
>>>       //reset the business object
>>>       this.object = new BusinessObject();
>>>       //go the same page
>>>       return "same_page";
>>>    }
>>> }
>>>
>>> One possible drawback of this approach would be that the EL in your
>>> pages gets a little bit more verbose
>>> #{BusinessObjectHolder.object.property_of_the_object}, but if this is
>>> getting to complicated, you can solve it by using <t:aliasBean/> I
>>> suppose.
>>>
>>> Does this help or am I still missing the point here?
>>>
>>> Regards,
>>>
>>> Gert Vanthienen
>>> gert@anova.be
>>>
>>>
>>> David Delbecq wrote:
>>>    
>>>> using immediate=true is not possible. I will explain further what i
>>>> need
>>>> to achieve
>>>> 1) immediate = true does not update the backing bean, i need them
>>>> to be
>>>> updated before action call
>>>> 2) my action does commit some datas relative to my backing beans. This
>>>> involve changing some lists in the backing beans
>>>> 3) after action is confirmed and run, i need my form to recreate all
>>>> it's components (In fact, after the action called from xxx.jsp, i
>>>> need a
>>>> new form that use the layout defined in xxx.jsp)
>>>>
>>>> In my current situation, after the update of backing beans and
>>>> return of
>>>> action, the navigation rule does no create a new form. As a result,
>>>> one
>>>> of my component keeps it's 'initialized' state and does not recreate
>>>> himself :(
>>>>
>>>> This navigation to the same page is not just a matter of clearing the
>>>> form, I need to have a new form, with same design, but with different
>>>> datas.
>>>>
>>>> Note about the redirect: this makes me think about the redirect
>>>> manager
>>>> in sandbox about which (see my other message in mailing list) i have
>>>> problems as it store in session non serializable request scope datas.
>>>> Mike Kienenberger a écrit :
>>>>  
>>>>      
>>>>> On 9/14/06, David Delbecq <delbd@oma.be> wrote:
>>>>>           
>>>>>> Is it correct to assume a transition from xxx.jsp to the same
>>>>>> xxx.jsp,
>>>>>> following a navigation-rule after an action creates a brand new form
>>>>>> (recreation of all components, submitted value are not linked to
>>>>>> those
>>>>>> components)
>>>>>>                 
>>>>> I used this "navigate-to-the-same-page" technique when I couldn't
>>>>> quickly come up with a useful "public String clear()" action method.
>>>>>
>>>>> As others have noted, your backing beans providing data must be
>>>>> request-scoped.
>>>>>
>>>>> Also, you may need to use a <redirect /> rule to thwart any
>>>>> t:saveState and messages preservation you have on the page.
>>>>>
>>>>>  <navigation-rule>
>>>>>    <description></description>
>>>>>    <from-view-id>/pages/MyPage.xhtml</from-view-id>
>>>>>    <navigation-case>
>>>>>      <from-outcome>clear</from-outcome>
>>>>>      <to-view-id>/pages/MyPage.xhtml</to-view-id>
>>>>>       <redirect />
>>>>>    </navigation-case>
>>>>>  </navigation-rule>
>>>>>
>>>>>    public String clear()
>>>>>    {
>>>>>        return "clear";
>>>>>    }
>>>>>
>>>>>                <h:commandButton
>>>>>                    value="Clear"
>>>>>                    immediate="true"
>>>>>                    action="#{yourBean.clear}">
>>>>>                </h:commandButton>
>>>>>             
>>>>
>>>>         
>>
>>
>>
>>   
>


Mime
View raw message