Plus: that would also fix Adam's problem with:
parent.getChildren().remove(comp)
cause you are working on the actual component instance.
regards,
Martin
On 1/27/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> You proabably missed Martin's original take on the ProcessingContext
> (Perspective is more code friendly ;-), but it would use a callback to allow
> a single point of decoration for all lifecycle methods:
>
> public class Perspective {
>
> private final UIComponent target;
>
> public Perspective(UIComponent target) {
> this.target = target;
> }
>
> public Object invoke(FacesContext faces, Invoke inv) {
> return inv.invoke(faces, this.target);
> }
>
> public void processDecode(FacesContext faces) {
> this.invoke(faces, DECODE_INVOKE);
> }
>
> ...
> }
>
> public class UIDataPerspective extends Perspective {
>
> private final UIData data;
> private final int row;
>
> public UIDataPerspective(UIComponent target, UIData data, int row) {
> ...
> }
>
> public Object invoke(FacesContext faces, Invoke inv) {
> int origRow = this.data.getRow();
> Object result = null;
> try {
> this.data.setRow(this.row);
> result = super.invoke(faces, inv);
> } finally {
> this.data.setRow(origRow);
> }
> return result;
> }
> }
>
> I really wish we didn't have to go this route, but UIComponent has 30+
> methods on it and no read-only interface inherent to optionally compose this
> behavior. Ideally, we have some super interface for UIComponent that's
> something like LifecycleAware that would have the methods UIComponents needs
> to participate in the JSF lifecycle, without carrying the rest of the baggage
> of a UIComponent proxy. Although, that solution sounds just as interesting,
> but we still have the problem that was initially brought up with Avatar where
> the UIComponent itself must be able to return a snapshot for a given index,
> it's extremely difficult to assert this behavior externally.
>
> -- Jacob
>
> >
> >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
> >>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
