[jsr-314-open] Spec-Issue https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1408

Ryan Lubke Ryan.Lubke at Sun.COM
Tue Nov 10 17:04:06 EST 2009


On 11/10/09 12:21 PM, Martin Marinschek wrote:
> Hi Ryan,
>
> I don't think it is really cool to list all our applications' pages in
> this exemption list - we are using dialogs, built on top of dynamic
> includes, so we (at least) will have to find a workaround here.
>    
You can disable partial state saving for the entire application and not 
for specific views.

> In https://javaserverfaces.dev.java.net/issues/showvotes.cgi?issue_id=1313,
> I suggest an (or better two) alternative courses of action. One of
> them we should take, I believe. Find the issue text in the following:
>
> 1) (preferred) do as Facelets did before: treat the second
> merry-go-round (application of tag-handlers) slightly different. Just
> deal with new components (call mark initial state) and deleted
> components (let them silently fall under the table, don't treat them
> as dynamically removed components), and don't call onComponentCreated,
> but onComponentPopulated if the component has been found. The
> tag-handlers already expect this behaviour.
>
> 2) (performance intensive, not preferred) save partial state, recreate
> the component tree and reapply partial state before rendering
>    
We'll see if we can address this for 2.0.2.
> regards,
>
> Martin
>
> On 11/10/09, Ryan Lubke<Ryan.Lubke at sun.com>  wrote:
>    
>> On 11/10/09 11:40 AM, Martin Marinschek wrote:
>>      
>>> Hi,
>>>
>>> I just ran into a new issue with 2.0: a condition-change in the test
>>> attribute of a c:if in invoke-application doesn't lead to a changed
>>> component tree, as the tag-handlers are not reevaluated before render
>>> response.
>>>
>>> In Facelets old, they were evaluated -->   therefore, this is a
>>> backwards compatibility issue.
>>>
>>>        
>> It works in Facelets 1.1.x because you aren't using partial state saving.
>>   From what I understand, you would see similar behavior using Facelets
>> 1.1.x with Trinidads
>> partial state saving implementation for similar reasons (check the 1.1.x
>> FaceletViewHandler's
>> logic with regards to facelets.BUILD_BEFORE_RESTORE).
>>      
>>> That now is really a show-stopper for us with regards to 2.0 - the
>>> first real one we encounter.
>>>
>>>        
>> For these cases, you can disable partial state saving for view in question.
>>      
>>> regards,
>>>
>>> Martin
>>>
>>>        
>>
>>      
>
>    





More information about the jsr-314-open-mirror mailing list