I believe the spec requires JSF-generated ids to start with "_", and
that using "_id" is merely MyFaces convention.
if (id starts with "_id") {
// ok, this is MyFaces-generated, and is not a row id
} else if (id starts with "_") {
// ok, this is MyFaces-generated, and is a table index
rowNum = Integer.parse(id.substring(1))
} else {
// this is user-specified
}
On Wed, 2006-01-25 at 10:05 +0100, Martin Marinschek wrote:
> Yes, you have a point here.
>
> but in fact, autogenerated id's don't start with _, but with _id.
>
> and if we do that, I again loose my ability to make a distinction
> between a row-id and a sub-component-id :(
>
> regards,
>
> Martin
>
> On 1/25/06, Simon Kitching <[EMAIL PROTECTED]> wrote:
> > 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
> > > >
> >
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
