Hi Simon,
your last suggestion is what Jacob is currently doing with his
perspectives in Avatar. I like that, but it doesn't give you the real
component to work with. That's what my suggestion would allow you to
do.
If we'd want to implement this using the normal findComponent method,
we'd need some kind of enhancement at runtime - like hibernate does
for its persistent objects.
Your first suggestion doesn't help me, I think. In the numerical case,
I can find out with testing on the id being numerical. In the
non-numerical case (thank goodness nobody has used that in a component
so far) I am again at loss - the actual child id could have been
automatically generated as well. I believe that you can't use one
separator for two logically distinct things.
One option would be to append the rowId always (even if it's 0 or -1),
and do some sort of consuming with the naming-containers - so you ask
them how many parts of the id-string they expect to see. With that,
you'd have a fixed structure available and would be able to determine
the behaviour.
regards,
Martin
On 1/22/06, Simon Kitching <[EMAIL PROTECTED]> wrote:
> 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.
>
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
