myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Winer <awi...@gmail.com>
Subject Re: Client-ID
Date Fri, 27 Jan 2006 17:26:50 GMT
On 1/26/06, Martin Marinschek <martin.marinschek@gmail.com> wrote:
> Except you render the client-id to the server - transmit it back via
> an AJAX-request - and now want to lookup the component and do some
> handling on this component .

This cannot currently be done in JSF.  Jacob Hookom's Avatar
project works to rectify this.  Changing the semantics of
findComponent() is not nearly enough, esp. because of stamped
components like tables and trees.

> How do you do this in ADF faces - I know you are using a filter, but
> how do you know which component the filter applies to?

Our filter doesn't do anything with respect to partial-page requests.
Partial-page requests are detected during decode() in the appropriate
Renderer.  So, basically, ADF Faces doesn't try to optimize the
overhead of walking the component tree - that's the job of things
like Avatar - it optimizes the user experience (and the developer
experience, by making PPR so easy.)

> Do you - additionally to sending the client-id to the client- send the
> scoped id as well?

Nope.

> @Adam: well, findComponent does not work if the component is a child
> component in a dataTable, and IMHO it should, that's my basic issue
> here.

It does, as long as you include the ID of the table plus the separator,
since a UIData is a NamingContainer.

-- Adam


> Martin
>
> On 1/26/06, John Fallows <john.r.fallows@gmail.com> wrote:
> > Folks,
> >
> >  On 1/25/06, Adam Winer <awiner@gmail.com> wrote:
> > > The intention of clientId is to provide an identifier that can be
> > > used in markup and therefore to refer to elements on the client.
> > >
> > > The point of findComponent() is find UIComponents on the server,
> > > generally given known (that is, explicitly set) IDs (and I mean
> > > "id", setId(), getId()) on various waypoints between the source
> > > component and the target component.
> >
> >  I think this is the key point for the discussion.  There's no reason to
> > expect findComponent to work with client id.
> >
> >  Kind Regards,
> >  John Fallows.
> >
> >
> > > It's not obvious to me why you'd want to go from one to the other;
> > > they're basically totally different roles.
> > >
> > > It's also somewhat meaningless to have row identifers apply
> > > to scoped-id:  what you get out the other end is a UIComponent,
> > > and that's it:  how could the row identifier meaningfully apply
> > > to that return value?
> > >
> > > -- Adam
> > >
> > > On 1/25/06, Martin Marinschek <martin.marinschek@gmail.com> wrote:
> > > > Yes, ok.
> > > >
> > > > but then, the scoped-id is something which should also work with row
> > > > identifiers. And - there should be a way to lookup a scoped identifier
> > > > from a client-id and the other way round. If both are unique - why
> > > > take away the possibility of converting them into each other from the
> > > > user?
> > > >
> > > > regards,
> > > >
> > > > Martin
> > > >
> > > > On 1/24/06, John Fallows <john.r.fallows@gmail.com> wrote:
> > > > > Folks,
> > > > >
> > > > > AFAIK, UIComponent.findComponent(String) receives a "scoped" id rather
> > than
> > > > > a client id, since it just traverses the component hierarchy, rather
> > than
> > > > > factoring in any "current row" for cases such as UIData.
> > > > >
> > > > > So, although the exact structure of client id is privately controlled
> > by the
> > > > > Renderer as an implementation detail, the syntax of the scoped id
> > passed to
> > > > > findComponent is well-defined.  In certain cases, the a component's
> > client
> > > > > id and scoped id may happen to have the same value, but that does
not
> > imply
> > > > > that client id is supposed to work with findComponent in all cases.
> > > > >
> > > > > Kind Regards,
> > > > > John Fallows.
> > > > >
> > > > >
> > > > > On 1/23/06, Martin Marinschek <martin.marinschek@gmail.com>
wrote:
> > > > > > Hi guys,
> > > > > >
> > > > > > I'm opening a can of worms here - I just discussed with John
for
> > quite
> > > > > > some time, and now there is a new point that represents a problem
to
> > > > > > me.
> > > > > >
> > > > > > So a short question to the spec-gurus - how are findComponent
and
> > > > > > Renderer.convertClientId supposed to work together?
> > > > > >
> > > > > > findComponent makes assumptions on the structure of a passed
> > clientId,
> > > > > > convertClientId has no restrictions whatsoever (as for the spec)
on
> > > > > > what it is allowed to do with the client-id. Doesn't that represent
> > a
> > > > > > problem?
> > > > > >
> > > > > > regards,
> > > > > >
> > > > > > Martin
> > > > > >
> > > > > > --
> > > > > >
> > > > > > http://www.irian.at
> > > > > >
> > > > > > Your JSF powerhouse -
> > > > > > JSF Consulting, Development and
> > > > > > Courses in English and German
> > > > > >
> > > > > > Professional Support for Apache MyFaces
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > >   http://apress.com/book/bookDisplay.html?bID=10044
> > > > > Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
> > > >
> > > >
> > > > --
> > > >
> > > > http://www.irian.at
> > > >
> > > > Your JSF powerhouse -
> > > > JSF Consulting, Development and
> > > > Courses in English and German
> > > >
> > > > Professional Support for Apache MyFaces
> > > >
> > >
> >
> >
> >
> > --
> >
> > http://apress.com/book/bookDisplay.html?bID=10044
> > Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>

Mime
View raw message