Well,

what my problem is that I _can't_ currently find out the component
with an id that has been created for a component in a special row.

It's not a question about manually parsing and if I should do it or
the component should do it itself, it's rather a question of it being
impossible in the current state ;)

I can't differentiate between the id of a naming-container and the
index of a row with the current implementation.

form:data:input

and

form:data:1:input

- the rowIndex is not distinguishable from the normal id.

regards,

Martin

On 1/22/06, Jacob Hookom <[EMAIL PROTECTED]> wrote:
> Really, we need something in the spec to allow for an object facade to
> be returned-- your visitor solution makes it much more generic and more
> pliable for the spec-- I would even go as far as to attempt to sneak
> this one in since the default behavior can be implemented without
> modifying the whole component stack.
>
> But yes, right now, I would externally visit with specific knowledge of
> UIData instanceof and parse manually.  Really this should be up to the
> particular UIComponent itself (and optimized easily) in the spec:
>
> // UIComponentBase
> public UIComponentReference findReference(FacesContext faces, String
> clientId) {
>     String myId = this.getClientId(faces);
>     if (myId.equals(clientId)) return new UIComponentReference(this);
>     UIComponentReference ref;
>     for (Iterator itr = this.getFacetsAndChildren(); itr.hasNext(); ) {
>        ref = ((UIComponent) itr.next()).findReference(faces, clientId);
>        if (ref != null) return ref;
>     }
>     return null;
> }
>
> // UIForm
> public UIComponentReference findReference(FacesContext faces, String
> clientId) {
>     String myId = this.getClientId(faces);
>     if (myId.equals(clientId)) return new UIComponentReference(this);
>     else if (clientId.startsWith(myId) || this.prefixId == false) return
> super.findReference(faces, clientId);
>     return null;
> }
>
> // UIData
> public UIComponentReference findReference(FacesContext faces, String
> clientId) {
>     // do just like UI form, except before calling the super, set the
> appropriate index
> }
>
>
>
>
> Martin Marinschek wrote:
>
> >Ok, good to have positive feedback on this.
> >
> >What do you say to the colon-problem? Any idea about that?
> >
> >It's just not failsafe like it is right now - am I supposed to parse
> >out the rowIndex and try to convert it to a number to see if I am in a
> >valid row ;) ?
> >
> >e.g.
> >
> >form:data:1:input
> >
> >is the client-id if rowindex is set to 1 and
> >
> >form:data:input
> >
> >is the client-id if rowindex is set to -1.
> >
> >No clue how I am supposed to work around that, except with different
> >separators.
> >
> >regards,
> >
> >Martin
> >
> >On 1/22/06, Jacob Hookom <[EMAIL PROTECTED]> wrote:
> >
> >
> >>I think it's a great idea!
> >>
> >>One of my motivations around the perspectives was to allow components to
> >>actually return 'things' that weren't UIComponents to participate in the
> >>lifecycle.  I think this is one of the flaws of JSF is that the base
> >>Component object has 40+ methods on it-- I've been trying to think of
> >>ways to better lend to other UI technologies and mix them into JSF.
> >>
> >>-- Jacob
> >>
> >>Martin Marinschek wrote:
> >>
> >>
> >>
> >>>Yes, exactly.
> >>>
> >>>What do you say to that?
> >>>
> >>>I'd also include a return-value, so that it is possible to return
> >>>stuff out of the method again.
> >>>
> >>>regards,
> >>>
> >>>Martin
> >>>
> >>>On 1/22/06, Jacob Hookom <[EMAIL PROTECTED]> wrote:
> >>>
> >>>
> >>>
> >>>
> >>>>Nice--
> >>>>
> >>>>so you would have
> >>>>
> >>>>public void accept(new ComponentVisitor(FacesContext faces, UIComponent 
> >>>>c) {
> >>>>   c.renderAll(faces);
> >>>>});
> >>>>
> >>>>public class IndexedPerspective {
> >>>>   private final idx;
> >>>>   private final UIData parent;
> >>>>   private final UIComponent target;
> >>>>
> >>>>   public void visit(ComponentVisitor cv) {
> >>>>      int oidx = parent.getRow();
> >>>>      try {
> >>>>         parent.setRow(idx);
> >>>>         cv.accept(target);
> >>>>      } finally {
> >>>>         parent.setRow(oidx);
> >>>>      }
> >>>>   }
> >>>>}
> >>>>
> >>>>?
> >>>>
> >>>>Martin Marinschek wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>Hi *,
> >>>>>
> >>>>>I've decided against Jacob's suggestion of using Avatar and
> >>>>>Perspectives for solving my executeOn... - problem. I believe that it
> >>>>>is important to have the actual component instance available, and this
> >>>>>is better doable with a callback-method that is called from the
> >>>>>blackbox the parent component represents.
> >>>>>
> >>>>>for the executeOnComponent stuff I'm currently working on I'd need to
> >>>>>have a way to inversely lookup components. I want to provide an id -->
> >>>>>find component
> >>>>>
> >>>>>For children of an UIData component I have problems with that: the
> >>>>>id's of those components include the NamingContainer.SEPARATOR_CHAR
> >>>>>for both separating the naming-containers from each other and for
> >>>>>separating the row-index from the id of the component.
> >>>>>
> >>>>>Shouldn't there be different characters used for those two usages - or
> >>>>>another way of clearly distinguishing these separators (e.g. a
> >>>>>doble-colon for the row-index)?
> >>>>>
> >>>>>Plus - Ed, I've just read in the spec that you've added a section
> >>>>>explaining that there are problems with the id as a separator for
> >>>>>id-based selectors in the explanation of NamingContainers. We've just
> >>>>>recently had a discussion on the mailing-list where on of our users
> >>>>>has told me that it is possible to escape the colon in id-selectors
> >>>>>with a \. you might want to add this to the workarounds you present in
> >>>>>the spec.
> >>>>>
> >>>>>regards,
> >>>>>
> >>>>>Martin
> >>>>>
> >>>>>--
> >>>>>
> >>>>>http://www.irian.at
> >>>>>
> >>>>>Your JSF powerhouse -
> >>>>>JSF Consulting, Development and
> >>>>>Courses in English and German
> >>>>>
> >>>>>Professional Support for Apache MyFaces
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>--
> >>>>Jacob Hookom  -  Minneapolis
> >>>>----------------------------
> >>>>JSF-EG, JSF-RI, EL, Facelets
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>--
> >>>
> >>>http://www.irian.at
> >>>
> >>>Your JSF powerhouse -
> >>>JSF Consulting, Development and
> >>>Courses in English and German
> >>>
> >>>Professional Support for Apache MyFaces
> >>>
> >>>
> >>>
> >>>
> >>>
> >>--
> >>Jacob Hookom  -  Minneapolis
> >>----------------------------
> >>JSF-EG, JSF-RI, EL, Facelets
> >>
> >>
> >>
> >>
> >
> >
> >--
> >
> >http://www.irian.at
> >
> >Your JSF powerhouse -
> >JSF Consulting, Development and
> >Courses in English and German
> >
> >Professional Support for Apache MyFaces
> >
> >
> >
>
>
> --
> Jacob Hookom  -  Minneapolis
> ----------------------------
> JSF-EG, JSF-RI, EL, Facelets
>
>


--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Reply via email to