You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Martin Marinschek <ma...@gmail.com> on 2006/01/22 18:52:53 UTC
NamingContainer.SEPARATOR_CHAR
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
Re: NamingContainer.SEPARATOR_CHAR
Posted by Simon Kitching <sk...@apache.org>.
On Tue, 2006-01-24 at 16:12 +0100, Martin Marinschek wrote:
> 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.
+1.
The only potential issue is code that calls findComponent then casts the
result to a specific UIComponent subclass. But any such code that is
passing an id with an embedded rowId in it is probably not doing what is
expected at the current time anyway.
> 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'd be interested in hearing more about that. Can you post a summary?
I'd just like to bring up my earlier proposal again: to move to using
"_{rownum}" rather than just {rownum} for the index. As the rownum is a
generated id, and generated ids are required to start with "_" I think
this would be the right thing to do. Example:
form1:table1:_3:component1
Regards,
Simon
Re: NamingContainer.SEPARATOR_CHAR
Posted by Martin Marinschek <ma...@gmail.com>.
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 <ma...@gmail.com> 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 <sk...@apache.org> 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 <ma...@gmail.com> 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 <ja...@hookom.net> 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 <ja...@hookom.net> 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 <ja...@hookom.net> 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
Re: NamingContainer.SEPARATOR_CHAR
Posted by Martin Marinschek <ma...@gmail.com>.
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 <sk...@apache.org> 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 <ma...@gmail.com> 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 <ja...@hookom.net> 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 <ja...@hookom.net> 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 <ja...@hookom.net> 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
Re: NamingContainer.SEPARATOR_CHAR
Posted by Simon Kitching <sk...@apache.org>.
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 <ma...@gmail.com> 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 <ja...@hookom.net> 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 <ja...@hookom.net> 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 <ja...@hookom.net> 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.
Re: NamingContainer.SEPARATOR_CHAR
Posted by Jacob Hookom <ja...@hookom.net>.
Are you sure you need that? If the passed clientId startsWith
UIData.clientId, then check the next token, if numeric, set rowIndex and
continue, otherwise set rowIndex to -1 and continue, otherwise if
clientId !startsWith UIData.clientId, return null.
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 <ma...@gmail.com> 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 <ja...@hookom.net> 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 <ja...@hookom.net> 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 <ja...@hookom.net> 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
>
>
>
--
Jacob Hookom - Minneapolis
----------------------------
JSF-EG, JSF-RI, EL, Facelets
Re: NamingContainer.SEPARATOR_CHAR
Posted by Martin Marinschek <ma...@gmail.com>.
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 <ma...@gmail.com> 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 <ja...@hookom.net> 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 <ja...@hookom.net> 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 <ja...@hookom.net> 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
Re: NamingContainer.SEPARATOR_CHAR
Posted by Martin Marinschek <ma...@gmail.com>.
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 <ja...@hookom.net> 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 <ja...@hookom.net> 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 <ja...@hookom.net> 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
Re: NamingContainer.SEPARATOR_CHAR
Posted by Jacob Hookom <ja...@hookom.net>.
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 <ja...@hookom.net> 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 <ja...@hookom.net> 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
Re: NamingContainer.SEPARATOR_CHAR
Posted by Martin Marinschek <ma...@gmail.com>.
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 <ja...@hookom.net> 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 <ja...@hookom.net> 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
Re: NamingContainer.SEPARATOR_CHAR
Posted by Jacob Hookom <ja...@hookom.net>.
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