myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ja...@hookom.net
Subject RE: Re: Re: Client-ID
Date Sat, 28 Jan 2006 18:54:49 GMT
Actually, proxying is pretty straight forward with cglib since we would only need to intercept
external invocations upon the instance-- not dealing with proxying within the UIComponent
itself-- where member variable state could be difficult.

So if you did use cglib to proxy the returned instance, you could do everything we describe
with a single methodinterceptor which would take care of all invocations, while still 'looking'
like an actual HtmlCommandLink.

-- Jacob

>
>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