myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Winer <awi...@gmail.com>
Subject Re: Re: Client-ID
Date Sat, 28 Jan 2006 17:08:10 GMT
Yep;  BTW, another nastiness with the proxying approach:  from
a proxy, you have to return a proper proxy around components returned
via getChildren() and getFacets().  Blech!

We went down this road in UIX (some of which code still survives
in the ADF Faces drop);  it mostly worked, but only because UIX
compnents were very, very simple objects with few responsibilities
(you could almost think of them as getAttributes() + getChildren() +
getFacets() + encodeAll(), and nothing more).

BTW, in spite of all the negativity I'm casting on the proxying
approach, I'd love for someone to try it and see how it goes,
because we all benefit from seeing a diversity of approaches.

-- Adam



On 1/28/06, Martin Marinschek <martin.marinschek@gmail.com> wrote:
> 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, jacob@hookom.net <jacob@hookom.net> 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 <martin.marinschek@gmail.com> 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 <awiner@gmail.com> wrote:
> > >> > 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
> > >> > >
> > >> >
> > >> >
> > >>
> > >>
> > >> --
> > >>
> > >> 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
>

Mime
View raw message