Yeah, I've implemented this with an external Visitor instance--
'hacking' the NamingContainer checks.
The thing is to treat this behavior just like UIData's Event wrappers--
something that is a facade over the targeted instance. To assert that
you need to be able to have the actual component instance available
within an iterative context is a far shot-- you are dealing with a
transient instance-- so a limited facade (Perspective) allows some
degree of logical protection within the 'API'.
-- Jacob
Martin Marinschek wrote:
That sounds interesting.
so a Perspective is basically a wrapper for the properly initalized
and pre-configured component-instance then?
Where's the source for Avatar? In the JSF-RI?
I'll need to do that right now, though, and so probably without API changes ;)
regards,
Martin
On 1/21/06, Jacob Hookom <[EMAIL PROTECTED]> wrote:
This ties somewhat appropriately to the ideas behing ProcessingContexts
(or Perspectives) with Avatar--
It involved creating a read-only (like event) interface for UIComponent
such that you can allow the UIComponent to tranverse itself, returning
an (event-facade) for the given component, if found.
http://weblogs.java.net/blog/jhook/archive/2005/09/jsf_avatar_vs_m_1.html
Perspective p = uiData.findPerspective(faces, "_id0:foo:3:bar");
p.encodeAll(faces);
public Perspective findPerspective(FacesContext faces, String clientId) {
String myId = this.getClientId(faces);
if (clientId.equals(myId) {
return new Perspective(this);
} else if (clientId.startsWith(myId)) {
int idx = //find idx from clientId
int oidx = this.getRow();
// modify my state
this.setRow(idx);
// find child now
Perspective p;
try {
p = super.findPerspective(faces, clientId);
} finally {
this.setRow(oidx);
}
if (p != null) {
return new IndexedPerspective(this, idx, p);
}
}
return null;
}
-- Jacob
Martin Marinschek wrote:
Yeah,
in fact I wanted to also hear feedback on the JSF-side of things. Like
- if there's anything like that already implemented in Tobago, ADF
Faces, planned for JSF 2.0.
would be interesting to hear about that.
regards,
Martin
On 1/21/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
Yes, only for extended components. Not for API stuff.
Ok, so from now on its a matter of personal preferences.
Personally I like to use factories/providers and so on ;-)
In the current case it will make no difference between the various
components just try to lookup and execute.
- a third person might want to be able to change the behaviour (I
don't believe they can, though, cause most of the stuff is private in
the components)
And this might be the strongest point why to use the marker interface,
then the component is able to use its internal private states to do
stuff more efficient, eventually.
Said all that, I think its not that bad to use the marker stuff here.
Only that it might lead to duplicate code if one requires the same
traversing policy but didnt extend from the myfaces component.
So maybe, where possible, you could create a new utility class which
will do the hard work, in your component the implemented method is only
a one-liner then.
Whatever solution you decide to use, it wont save the world ;-)
Ciao,
Mario
--
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
