myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Marinschek <martin.marinsc...@gmail.com>
Subject Re: Re: Client-ID
Date Sat, 28 Jan 2006 19:06:02 GMT
We'll try to explore the possibilities further.

But if we have either one of (or both) :

1) findPerspective(String scopedId) or a
2) visitComponent(FacesContext f, Visitor c)

in the spec, we should probably leave the wrapping approach be.

regards,

Martin

On 1/28/06, Adam Winer <awiner@gmail.com> wrote:
> 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
> >
>


--

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