I suggest that we use a single-colon for separating naming-containers,
and add a section to the spec, in which we say that for internal
split-up like separating the row-id from the component name we take a
double-colon (::).
So instead of:
form:data:input
and
form:data:1:input
we'd have:
form:data:input
and
form:data::1:input
The findComponent method would need to be adopted for this to work,
but that's easy.
regards,
Martin
On 1/22/06, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> 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
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
