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
