My hunch is that you'll never be able to solve this without the
components really getting into the picture, and in particular, you have
to give stamping components (UIData, etc.) and parents with interesting
behavior (the ADF UIXRegion component) a chance to intercept
processing. Trying to perform the process entirely externally
to the components (given a UIViewRoot and a clientId, locate the
target component, accounting for UIData and all other interesting
parent components and their behavior) is a path to great pain
and "just-one-more-patch-and-*now*-it'll-work" hell.
Wrapping components inside proxies is also likely to be a major
nightmare (perhaps unless you use AOP-type techniques like those
Spring uses to re-expose interfaces, etc.). FWIW, a plain
"findReference" isn't sufficient, because it's not enough to
set the current row of data, you have to unset it when you leave
the child component.
-- Adam
On 1/26/06, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> Hmm....
>
> yes, you're right - we could do that.
>
> but of course, Jacob is right in that the user might expect something
> for their javascript methods as well.
>
> and I am sure as soon as we change that, we'll get 15 requests of
> users asking why we are doing that differently than the RI here ;)
>
> regards,
>
> Martin
>
> On 1/25/06, Simon Kitching <[EMAIL PROTECTED]> wrote:
> > 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
> >
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
