[jsr-314-open-mirror] [jsr-314-open] PostAddToViewEvent publishing conditions

[Leonardo Uribe]

Hi

On this link:

https://issues.apache.org/jira/browse/MYFACES-2638

attachment: MYFACES-2638-3.patch

I attached a proposal to fix this issue, based on myfaces code. The idea is
create a event called javax.faces.event.PostBuildRefreshViewEvent. This
event
is quite different from the one proposed in:

[jsr-314-open] add component resources depending on the owner component
state

because there is one case this one is not published: when partial state
saving is
enabled and there is no call to vdl.buildView for refresh. I also notice
that there is
no "inheritance" between events, that means, if I have two events and one
extends
from the other and there is a listener attached to the parent, when the
child event
is raised the listener is not notified.

h:outputScript, h:outputStylesheet, cc:insertChildren, cc:insertFacet needs
to attach
its listeners to that event too, to give the chance to relocate their
related components
correctly. The listener that track changes on the component tree and mark
them to
be saved/restored fully does not need to listen this event.

PostAddToViewEvent/PreRemoveFromViewEvent should continue working as always,
the important here is disable event processing while we are refreshing the
view. The side
effect is components added to the component tree when view is refreshed
(c:if case) will
not receive that event.

If we want to avoid that side effect, the proposal is change
PostBuildRefreshViewEvent
to PostBuildViewEvent, this one will be an event specific for relocation and
that one
should be published after the view is build, in other words, in the same
place as
we are doing PostBuildRefreshViewEvent but for all cases, but that one
requires remove
the register of the listeners to PostAddToViewEvent on h:outputScript and
related. Also,
it is necessary to indicate in some way when publish PostAddToViewEvent/
PreRemoveFromViewEvent by facelets algorithm for build/refresh view, because
it is there
where we have the knowledge about when propagate it or not.

I think at this point it is clear the problem and the possible direction to
solve it, so I'll create
an issue for this one on the spec issue tracker.

regards,

Leonardo Uribe

2010/3/30 Leonardo Uribe <lu4242 at gmail.com>

> Hi Martin
>
> In theory the secod event (PreRemoveFromViewEvent) should not be called
> when the view is "refreshed".
>
> The important for me at this point is make clear the problem, but in this
> point
> I think the better is do a prototype with myfaces. It will take some time,
> but as
> soon as I have something I'll publish the results, so we can discuss
> a more concrete proposal. I'll integrate also the solution for the problem
>
> "[jsr-314-open] add component resources depending on the owner component
> state"
> because it seems it is related.
>
> regards,
>
> Leonardo Uribe
>
> 2010/3/30 Martin Marinschek <mmarinschek at apache.org>
>
> Hi,
>>
>> > - Create a new event (let's call it PostBuildViewEvent for the moment),
>> that
>> > is
>> > propagated every time the view is build (when it is created, restored or
>> > refreshed before render response). h:outputScript, h:outputStylesheet,
>> > cc:insertChildren and cc:insertFacet should add a listener for this
>> > event and handle all relocation code at response of this event.
>> >
>> > - Fix PostAddToViewEvent/PreRemoveFromViewEvent publishing conditions.
>> > In my opinion this ones should not be called when the view is
>> "refreshed".
>> > Martin suggestion about the publishing conditions are reasonable.
>>
>> yes, this sounds good. Leonardo, for the second event, how would you
>> suggest the publishing to happen (actual sourcecode)?
>>
>> best regards,
>>
>> Martin
>> --
>>
>> http://www.irian.at
>>
>> Your JSF powerhouse -
>> JSF Consulting, Development and
>> Courses in English and German
>>
>> Professional Support for Apache MyFaces
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20100331/ee59ee73/attachment-0002.html