Return-Path: Delivered-To: apmail-myfaces-dev-archive@www.apache.org Received: (qmail 5783 invoked from network); 1 Apr 2010 02:10:35 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 1 Apr 2010 02:10:35 -0000 Received: (qmail 73094 invoked by uid 500); 1 Apr 2010 02:10:34 -0000 Delivered-To: apmail-myfaces-dev-archive@myfaces.apache.org Received: (qmail 73036 invoked by uid 500); 1 Apr 2010 02:10:34 -0000 Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "MyFaces Development" Delivered-To: mailing list dev@myfaces.apache.org Received: (qmail 73029 invoked by uid 99); 1 Apr 2010 02:10:34 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Apr 2010 02:10:34 +0000 X-ASF-Spam-Status: No, hits=2.1 required=10.0 tests=AWL,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of lu4242@gmail.com designates 209.85.222.192 as permitted sender) Received: from [209.85.222.192] (HELO mail-pz0-f192.google.com) (209.85.222.192) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Apr 2010 02:10:30 +0000 Received: by pzk30 with SMTP id 30so630380pzk.12 for ; Wed, 31 Mar 2010 19:10:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=5966YdqVF/91AY08N/X/pPO0wrnuKV00ZDGgMmDNCY4=; b=L2NlYUR40gazkz0xwQ+fV7shnPfr9xCry3Q4K3diYTEizwg8UdI/42vSEVuw1eEwTa +9z9hax4lvD/xdah7LA8A4uCe8sEnSGL/Cva6nk31cULA2lB76fuYB8gCtxm39QToUCg bdHJZ24bbe85+d3ClKnI1KyOVL4+TjoQSIQ/U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=asjQlV8rUKsdNgSa5LkICgXujv9X14n2PG/wBSOWU++3RqEQs/vF2KP6vInRbmQFh9 hWJWggVA78bDj8N/sLYEhUwAvzeBO1b8koQ04cFahoSjcBdsI7K2nTfkegUtcnsXaDrm jeFo+Yy3hBzMzTAkbflV4xxJklCON1QMTwqpM= MIME-Version: 1.0 Received: by 10.142.77.7 with HTTP; Wed, 31 Mar 2010 19:10:09 -0700 (PDT) In-Reply-To: References: <5a99335f1003291729p5ca08f0cl284722cac76044e0@mail.gmail.com> <5a99335f1003300032t204d072ap98e71b0adb8117a3@mail.gmail.com> Date: Wed, 31 Mar 2010 22:10:09 -0400 Received: by 10.142.67.33 with SMTP id p33mr898346wfa.231.1270087809783; Wed, 31 Mar 2010 19:10:09 -0700 (PDT) Message-ID: Subject: Re: [jsr-314-open] PostAddToViewEvent publishing conditions From: Leonardo Uribe To: MyFaces Development Cc: jsr-314-open@jcp.org Content-Type: multipart/alternative; boundary=001636e0a7d4bc5ae80483235c4a --001636e0a7d4bc5ae80483235c4a Content-Type: text/plain; charset=ISO-8859-1 Hi Ok, the spec issue is this one: https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=782 regards, Leonardo Uribe 2010/3/31 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 > > 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 >> >> 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 >>> >> >> > --001636e0a7d4bc5ae80483235c4a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi

Ok, the spec issue is this one:

https://jav= aserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=3D782
<= br> regards,

Leonardo Uribe

2010/3/31 = Leonardo Uribe <lu= 4242@gmail.com>
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 eve= nt
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: wh= en partial state saving is
enabled and there is no call to vdl.buildVie= w for refresh. I also notice that there is
no "inheritance" be= tween 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 chi= ld 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 relat= ed components
correctly. The listener that track changes on the componen= t tree and mark them to
be saved/restored fully does not need to listen = this event.

PostAddToViewEvent/PreRemoveFromViewEvent should continue working as al= ways,
the important here is disable event processing while we are refres= hing 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 pr= oposal is change PostBuildRefreshViewEvent
to PostBuildViewEvent, this o= ne will be an event specific for relocation and that one
should be publi= shed after the view is build, in other words, in the same place as
we are doing PostBuildRefreshViewEvent but for all cases, but that one requ= ires remove
the register of the listeners to PostAddToViewEvent on h:out= putScript and related. Also,
it is necessary to indicate in some way whe= n publish PostAddToViewEvent/
PreRemoveFromViewEvent by facelets algorithm for build/refresh view, becaus= e 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 dir= ection to solve it, so I'll create
an issue for this one on the spec issue tracker.

regards,

Leo= nardo Uribe

2010/3/30 Leonardo Uribe <lu4= 242@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 f= or the problem

"[jsr-314-open] add component resources depending on the owner compone= nt state"
because it seems it is related.

regards,
Leonardo Uribe

2010/3/30 Martin Marinsc= hek <mmarinschek@apache.org>

Hi,

> - Create a new event (let's call it PostBuildViewEvent for the mom= ent), 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 "re= freshed".
> Martin suggestion about the publishing conditions are reasonable.

yes, this sounds good. Leonardo, for the second event, how would you<= br> 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



--001636e0a7d4bc5ae80483235c4a--