Return-Path: Delivered-To: apmail-myfaces-dev-archive@www.apache.org Received: (qmail 25659 invoked from network); 2 Jun 2005 08:28:39 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 2 Jun 2005 08:28:39 -0000 Received: (qmail 52369 invoked by uid 500); 2 Jun 2005 08:28:38 -0000 Delivered-To: apmail-myfaces-dev-archive@myfaces.apache.org Received: (qmail 52333 invoked by uid 500); 2 Jun 2005 08:28:38 -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 52299 invoked by uid 99); 2 Jun 2005 08:28:37 -0000 X-ASF-Spam-Status: No, hits=0.1 required=10.0 tests=HTML_40_50,HTML_MESSAGE X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from Unknown (HELO mail.psi-im.de) (193.25.216.30) by apache.org (qpsmtpd/0.28) with ESMTP; Thu, 02 Jun 2005 01:28:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5674C.D2F4E67C" Subject: RE: Why HtmlDataTablePhaseListener? Date: Thu, 2 Jun 2005 10:26:50 +0200 Message-ID: <411872756F2300499FB7791C027C55CC292E58@mail.psi-im.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Why HtmlDataTablePhaseListener? Thread-Index: AcVnJtmnyVZZO5yeT1iB6/xEcp/qFQAH4RsQ From: "Broekelmann, Mathias" To: "MyFaces Development" X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N This is a multi-part message in MIME format. ------_=_NextPart_001_01C5674C.D2F4E67C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IMO it would be the best to find out why a phase listener is used for = the HtmlDataTable. Because this might not be related to the alias bean = component only. =20 It=B4s also an performance issue for the existing phase listener for the = datatable. Since every faces request if the page contains the datatable = or not will call the listener which traverses the component tree to find = a HtmlDataTable component. =20 Mathias -----Original Message----- From: Sylvain Vieujot [mailto:svieujot@apache.org]=20 Sent: Thursday, June 02, 2005 5:54 AM To: MyFaces Development Cc: Broekelmann, Mathias; Broekelmann@mailgwvw01.freelance.com; Manfred = Geiler Subject: Re: Why HtmlDataTablePhaseListener? I'm not 100% sure I fully understand how this works for the = HtmlDataTable, but if I'm right, the only solution would be to also have = a phaseListener for the alias bean. This would still raise some other problems : 1) A performance issue 2) I'm not sure we could set/remove the aliases in a reliable manner in = the phase listener as we have no way to know the enclosing tags. My suggestion is to rather avoid such cases :-( Maybe there is a better solution though ?? Sylvain. On Mon, 2005-05-30 at 16:12 +0200, Manfred Geiler wrote:=20 Yes, I (the author of this class ;-) know that this phase listener is absolutely necessary for the extended data table to work properly. This listeners purpose is to make sure that the refresh method for each extended HtmlDataTable in the component tree is called right before the render phase begins. There is no way to make this sure other than by means of this phase listener, because the render phase can be initiated by different incidents (see Lifecycle). Now, why is the refresh method important? The refresh method clears the internal DataModel of the HtmlDataTable when all children are valid and therefore there is no need to longer preserve the DataModel. What is more, we even must omit the internal DataModel, so that the actual data from the backing bean is taken during rendering - could have been changed in the meantime by some application event. Seems like this is rather an aliasbean issue. Sylvain, are you = listening? -Manfred 2005/5/30, Broekelmann, Mathias : > Hi, >=20 > The x:datatable component uses a phase listener > (HtmlDataTablePhaseListener) for validation issues. I don't know why > this is necessary but it causes problems when a aliased bean (through > aliasbean component) is used in a nested datatable. >=20 > Due to the implementation of the aliasbean component the aliased bean = is > only available in the process phases but not in the before or after > phase in which the phase listener is called. >=20 > To solve this problem for our application I just commented the phase > listener out of faces-config.xml. The application is still working as > expected but I want to make sure that there is no hidden issue which I > haven't seen so far. >=20 > Does anyone know why this phase listener is necessary? >=20 > Mathias > ------_=_NextPart_001_01C5674C.D2F4E67C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Nachricht
IMO it=20 would be the best to find out why a phase listener is used for the=20 HtmlDataTable. Because this might not be related to the alias = bean=20 component only.
 
It=B4s=20 also an performance issue for the existing phase listener for the = datatable.=20 Since every faces request if the page contains the datatable = or not=20 will call the listener which traverses the component tree to find a=20 HtmlDataTable component.
 
Mathias
-----Original Message-----
From: Sylvain Vieujot=20 [mailto:svieujot@apache.org]
Sent: Thursday, June 02, 2005 = 5:54=20 AM
To: MyFaces Development
Cc: Broekelmann, = Mathias;=20 Broekelmann@mailgwvw01.freelance.com; Manfred = Geiler
Subject: Re:=20 Why HtmlDataTablePhaseListener?

I'm not 100% sure = I fully=20 understand how this works for the HtmlDataTable, but if I'm right, the = only=20 solution would be to also have a phaseListener for the alias = bean.

This=20 would still raise some other problems :

1) A performance=20 issue

2) I'm not sure we could set/remove the aliases in a = reliable=20 manner in the phase listener as we have no way to know the enclosing=20 tags.

My suggestion is to rather avoid such cases = :-(

Maybe=20 there is a better solution though ??

Sylvain.

On Mon, = 2005-05-30=20 at 16:12 +0200, Manfred Geiler wrote:=20 
Yes, I (the =
author of this class ;-) know that this phase listener is
absolutely necessary for the extended data table =
to work properly.
This listeners purpose is to make sure that the =
refresh method for
each extended HtmlDataTable in the component tree =
is called right
before the render phase begins.
There is no way to make this sure other than by =
means of this phase
listener, because the render phase can be =
initiated by different
incidents (see Lifecycle).

Now, why is the refresh method important?
The refresh method clears the internal DataModel =
of the HtmlDataTable
when all children are valid and therefore there is =
no need to longer
preserve the DataModel. What is more, we even must =
omit the internal
DataModel, so that the actual data from the =
backing bean is taken
during rendering - could have been changed in the =
meantime by some
application event.

Seems like this is rather an aliasbean issue. =
Sylvain, are you listening?

-Manfred


2005/5/30, Broekelmann, Mathias <MBroekelmann@psi.de>:
> Hi,
> 
> The x:datatable component uses a phase =
listener
> (HtmlDataTablePhaseListener) for validation =
issues. I don't know why
> this is necessary but it causes problems when =
a aliased bean (through
> aliasbean component) is used in a nested =
datatable.
> 
> Due to the implementation of the aliasbean =
component the aliased bean is
> only available in the process phases but not =
in the before or after
> phase in which the phase listener is =
called.
> 
> To solve this problem for our application I =
just commented the phase
> listener out of faces-config.xml. The =
application is still working as
> expected but I want to make sure that there =
is no hidden issue which I
> haven't seen so far.
> 
> Does anyone know why this phase listener is =
necessary?
> 
> Mathias
>
------_=_NextPart_001_01C5674C.D2F4E67C--