Ok
I've discussed with Manfred some more, and we agreed upon the fact
that mixing the two approaches together would be the best solution.
So you have the normal findComponent() call on a naming-container, and
if this naming container is doing something special to it's components
and it finds the referential information for setting this context up
in the client-id, we deliver back a properly initialized perspective.
Now if we want to do some serious work on the component itself, we'll
have a "visit" or "execute" method on the perspective, with which you
can actually do the serious work on the properly initialized
component.
This solution is simple and stays in the confinements of the current
API - plus it allows for things that are somewhat special to the
MyFaces implementation. Of course you'll not be able to work with the
standard dataTable component for this to be practical.
In any case, it would be best to have a cool, standardized, specified,
possibility to do this in the spec.
By the way - I've also talked to John Fallows about this - he is not
100% d'accord, but he sees the basic problem as well. What he proposes
is a customized lifecycle, along with a filter, just like in
ADF-faces.
I like that solution for partial update, validation, etc. of the page
- but it doesn't solve all my problems.
Finally, whatever we discuss about this topic, I want to be free to
have access to the components in the faces-tree, even outside of the
lifecycle.
I want to say "findComponent" (or whatever the method is called), and
be able to work with this component; I can live with a perspective or
a callback, but not having a possibility to access the component
doesn't satisfy me.
regards,
Martin
On 1/23/06, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> 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
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
