Hi,
Initially, myfaces used "_" to separate table id from row id.
It was only recently that a move was made to use ":".
If you ignore the *implementation detail* that UIData uses a "flyweight"
pattern, then using ":" makes sense. From a logical point of view, each
row has a separate copy of each column component. A row must therefore
act as a NamingContainer for the components that are in it. And naming
containers use : to separate their id from their child id. So
"table:0:column1" makes good sense. I think it's nicer style to stay
with this than change the separator.
As Jacob notes, the id can be tested for all-numeric. Actually
JSF-generated ids are supposed to start with "_", so perhaps we should
be using "table:_0:column1" in order to avoid conflict with user-defined
ids that happen to be numeric?
What if UIData.findComponent returns a UIComponent object which
implements each method by setting the rowindex on the table then calling
the method then restoring the rowindex, just like the custom
FacesEventWrapper created in queueEvent. The only problem is that code
that calls findComponent often tries to downcast the result to the
expected type which won't work. So maybe the "visitor" approach makes
better sense after all.
Regards,
Simon
On Sun, 2006-01-22 at 20:24 +0100, Martin Marinschek wrote:
> 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.
