I think this approach will cause pain; even wrapping all the methods (and making sure you implement the appropriate interfaces too, e.g., EditableValueHolder!) and generalizing to support third-party classes and interfaces, etc., etc., you're still going to have problems; how do you remove() such a component from its parent?
UIComponent ref = ...; UIComponent parent = ref.getParent(); // Doesn't work! parent.getChildren().remove(ref); I quite liked the "ProcessingContext" approach that Jacob proposed well back that let you run the actual lifecycle methods on the actual component instances, but in a more optimized fashion. -- Adam On 1/27/06, Martin Marinschek <[EMAIL PROTECTED]> wrote: > 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 >
