Now that's exactly what I try to implement here. A version of find-component working with stamped components like dataTable and tree.
What I'm working on: if you give it a rowIndexed clientId (like: :form:data:1:myInput) the findComponent method of tomahawk's extendedDataTable returns (instead of null ;) a Perspective (yes, i took the wording from Jacob ;) which wraps all methods an UIInput would provide. If calling those methods is not enough for your special case, there is an visit-method on this Perspective, which you can, by providing a callback-handler, use to call some custom stuff on the returned component. regards, Martin On 1/27/06, Adam Winer <[EMAIL PROTECTED]> wrote: > On 1/26/06, Martin Marinschek <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > > Folks, > > > > > > On 1/25/06, Adam Winer <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > > > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
