Really, we need something in the spec to allow for an object facade to
be returned-- your visitor solution makes it much more generic and more
pliable for the spec-- I would even go as far as to attempt to sneak
this one in since the default behavior can be implemented without
modifying the whole component stack.
But yes, right now, I would externally visit with specific knowledge of
UIData instanceof and parse manually. Really this should be up to the
particular UIComponent itself (and optimized easily) in the spec:
// UIComponentBase
public UIComponentReference findReference(FacesContext faces, String
clientId) {
String myId = this.getClientId(faces);
if (myId.equals(clientId)) return new UIComponentReference(this);
UIComponentReference ref;
for (Iterator itr = this.getFacetsAndChildren(); itr.hasNext(); ) {
ref = ((UIComponent) itr.next()).findReference(faces, clientId);
if (ref != null) return ref;
}
return null;
}
// UIForm
public UIComponentReference findReference(FacesContext faces, String
clientId) {
String myId = this.getClientId(faces);
if (myId.equals(clientId)) return new UIComponentReference(this);
else if (clientId.startsWith(myId) || this.prefixId == false) return
super.findReference(faces, clientId);
return null;
}
// UIData
public UIComponentReference findReference(FacesContext faces, String
clientId) {
// do just like UI form, except before calling the super, set the
appropriate index
}
Martin Marinschek wrote:
Ok, good to have positive feedback on this.
What do you say to the colon-problem? Any idea about that?
It's just not failsafe like it is right now - am I supposed to parse
out the rowIndex and try to convert it to a number to see if I am in a
valid row ;) ?
e.g.
form:data:1:input
is the client-id if rowindex is set to 1 and
form:data:input
is the client-id if rowindex is set to -1.
No clue how I am supposed to work around that, except with different
separators.
regards,
Martin
On 1/22/06, Jacob Hookom <[EMAIL PROTECTED]> wrote:
I think it's a great idea!
One of my motivations around the perspectives was to allow components to
actually return 'things' that weren't UIComponents to participate in the
lifecycle. I think this is one of the flaws of JSF is that the base
Component object has 40+ methods on it-- I've been trying to think of
ways to better lend to other UI technologies and mix them into JSF.
-- Jacob
Martin Marinschek wrote:
Yes, exactly.
What do you say to that?
I'd also include a return-value, so that it is possible to return
stuff out of the method again.
regards,
Martin
On 1/22/06, Jacob Hookom <[EMAIL PROTECTED]> wrote:
Nice--
so you would have
public void accept(new ComponentVisitor(FacesContext faces, UIComponent c) {
c.renderAll(faces);
});
public class IndexedPerspective {
private final idx;
private final UIData parent;
private final UIComponent target;
public void visit(ComponentVisitor cv) {
int oidx = parent.getRow();
try {
parent.setRow(idx);
cv.accept(target);
} finally {
parent.setRow(oidx);
}
}
}
?
Martin Marinschek wrote:
Hi *,
I've decided against Jacob's suggestion of using Avatar and
Perspectives for solving my executeOn... - problem. I believe that it
is important to have the actual component instance available, and this
is better doable with a callback-method that is called from the
blackbox the parent component represents.
for the executeOnComponent stuff I'm currently working on I'd need to
have a way to inversely lookup components. I want to provide an id -->
find component
For children of an UIData component I have problems with that: the
id's of those components include the NamingContainer.SEPARATOR_CHAR
for both separating the naming-containers from each other and for
separating the row-index from the id of the component.
Shouldn't there be different characters used for those two usages - or
another way of clearly distinguishing these separators (e.g. a
doble-colon for the row-index)?
Plus - Ed, I've just read in the spec that you've added a section
explaining that there are problems with the id as a separator for
id-based selectors in the explanation of NamingContainers. We've just
recently had a discussion on the mailing-list where on of our users
has told me that it is possible to escape the colon in id-selectors
with a \. you might want to add this to the workarounds you present in
the spec.
regards,
Martin
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
--
Jacob Hookom - Minneapolis
----------------------------
JSF-EG, JSF-RI, EL, Facelets
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
--
Jacob Hookom - Minneapolis
----------------------------
JSF-EG, JSF-RI, EL, Facelets
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
--
Jacob Hookom - Minneapolis
----------------------------
JSF-EG, JSF-RI, EL, Facelets
