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
