Firstly, the format used when a table modifies the client-id to ensure
row uniqueness is not in the spec as far as I know, so any code that
depends on client ids of a specific layout isn't valid.
Secondly, MyFaces traditionally used _rownum rather than :rownum anyway,
and only changed to using a colon like RI after the last release. So
changing it now is no problem as far as I can see.
I agree that ":" is logical, as the per-row behaviour is very like each
row is a NamingContainer. I also suggest that "_" on the front of the
number is the logical behaviour (though not specified).
On Tue, 2006-01-24 at 16:30 -0500, [EMAIL PROTECTED] wrote:
> 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
> >
