myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ja...@hookom.net
Subject RE: Re: Client-ID
Date Fri, 27 Jan 2006 18:30:23 GMT
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
>>

Mime
View raw message