myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ja...@hookom.net
Subject RE: Re: NamingContainer.SEPARATOR_CHAR
Date Tue, 24 Jan 2006 21:30:27 GMT
You don't want to massage API client ids from what exists now, that's a pretty dramatic change
for people that have expected those ids within the UI.

>
>On Tue, 2006-01-24 at 16:12 +0100, Martin Marinschek wrote:
>> Ok
>> 
>> I've discussed with Manfred some more, and we agreed upon the fact
>> that mixing the two approaches together would be the best solution.
>> 
>> So you have the normal findComponent() call on a naming-container, and
>> if this naming container is doing something special to it's components
>> and it finds the referential information for setting this context up
>> in the client-id, we deliver back a properly initialized perspective.
>> 
>> Now if we want to do some serious work on the component itself, we'll
>> have a "visit" or "execute" method on the perspective, with which you
>> can actually do the serious work on the properly initialized
>> component.
>
>+1.
>
>The only potential issue is code that calls findComponent then casts the
>result to a specific UIComponent subclass. But any such code that is
>passing an id with an embedded rowId in it is probably not doing what is
>expected at the current time anyway.
>
>
>
>> By the way - I've also talked to John Fallows about this - he is not
>> 100% d'accord, but he sees the basic problem as well. What he proposes
>> is a customized lifecycle, along with a filter, just like in
>> ADF-faces.
>
>I'd be interested in hearing more about that. Can you post a summary?
>
>
>I'd just like to bring up my earlier proposal again: to move to using
>"_{rownum}" rather than just {rownum} for the index. As the rownum is a
>generated id, and generated ids are required to start with "_" I think
>this would be the right thing to do. Example:
>  form1:table1:_3:component1
>
>Regards,
>
>Simon
>

Mime
View raw message