Yeah, right, we'll see where that takes us...
Well, irrrkks stands for - me don't like it either ;)
regards,
Martin
On 1/27/06, Adam Winer <[EMAIL PROTECTED]> wrote:
> 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
> >
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
