8:40 p.m.
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.
That now is really a show-stopper for us with regards to 2.0 - the
first real one we encounter.
regards,
Martin
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
8:47 p.m.
New subject: [jsr-314-open] Spec-Issue https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1408
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
9:21 p.m.
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.
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
regards,
Martin
On 11/10/09, Ryan Lubke <Ryan.Lubke(a)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
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
11:04 p.m.
New subject: [jsr-314-open] Spec-Issue https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1408
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(a)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
>>
>>
>
>
3:04 a.m.
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.
ok, that's good.
> 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.
that would be cool. If the sentence in the spec is changed (which says
that applying the tag-handlers should occur only once), I do think it
is possible to do this in the implementation only.
regards,
Martin
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
8:08 p.m.
Gang -
I wanted to check up on this issue as it impacts our ability to leverage
partial state saving (which we very much want to use). I see that this
issue is now being tracked here:
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1313
And it looks like there are plans to fix this in Mojarra 2.0.3, but just
wanted to make sure that there weren't any concerns about the potential
fixes.
My thinking is that we would go with Martin's proposed fix #1:
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.
One reason why I was thinking we would go with this approach is because
this mirrors the behavior provided by the full state saving case. It
doesn't seem like our decision to re-execute handlers after invoke
application should be influenced by our choice of full or partial state
saving. In both cases we need to give handlers a chance to operate on
the previously restored view.
Regarding one concern that Ryan raised in 1313:
Component resoures. When the facelet handlers are re-applied during
render response, ComponentSupport.findChildByTagId() will never find
the existing component resource as it was relocated to the UIViewRoot
so Facelets considers the component as new each time.
Perhaps I am missing something here, but doesn't this issue exist in the
full state saving case as well? Don't we end up with the same component
tree after the view is restored, regardless of whether we restore by
building + applying deltas (partial) or solely from state (full)? I
always thought that the goal was that these two techniques for restoring
the view should end up restoring the component tree back to the same
state (ie. the state that it was left in on the previous request).
Andy
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.
That now is really a show-stopper for us with regards to 2.0 - the
first real one we encounter.
regards,
Martin
5255
days inactive
5290
days old
jsr-314-open-mirror@lists.jboss.org
5 comments
3 participants
participants (3)
-
Andy Schwartz -
Martin Marinschek -
Ryan Lubke