OK, cool: another thing to look for is a system that falls gracefully back
in such a way that not *every* component on the planet that does anything
special needs to add such special coding, that is, the default behavior
is always correct, and you only need to add additional code to optimize.
Otherwise, you'll end up with a mish-mash of components some of which
work and some of which don't in some scenarios.
Dynamic proxies are definitely one of the under-heralded-but-super-cool
features of J2SE!
And what's irrrkks stand for? Google came up with some German
pages about Mechwar...
-- Adam
On 1/27/06, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> Hi Adam,
>
> Of course - every component which does something special will need to
> handle this in its special way. Only the component knows about this
> stuff in JSF - a component is a blackbox is a blackbox is a blackbox
> ;) and should handle that.
>
> I'm doing exactly that.
>
> Wrapping the component into a proxy is (as I implemented it right now)
> done for the UIInput base now, but I've been suggesting the cool AOP
> stuff to Manfred, and we both agreed we want to arrive there finally
> ;).
>
> And of course, I am doing no find-reference. That would be irrrkks....
>
> regards,
>
> Martin
>
>
>
> On 1/27/06, Adam Winer <[EMAIL PROTECTED]> wrote:
> > 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
> > >
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
