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 <[EMAIL PROTECTED]> 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 <[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
> >
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
