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 <[EMAIL PROTECTED]> 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, [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
>>
