Let's start using the dev list for these discussions.
>>>>> On Sun, 21 May 2006 19:02:36 -0500, Jacob Hookom <jacob_at_hookom.net> said:
JH> Based on comments online, I think we should just call it 'avatar'-- it's
JH> a cool name anyways and won't necessarily railroad the artifacts with a
JH> specific architectual behavior by adjective or verb.
JH> com.sun.faces.avatar ?
Ok, but I still think the stuff you have in com.sun.facelets.client
should be in com.sun.faces.client.
Have you committed the latest of your code to the facelets branch?
Please check it in so I can start out with a change-bundle to migrate
the stuff into the jsf-extensions projec.t
JH> BTW, I do like your approach on the lifecycle a bit better-- I think we
JH> can do it with one servlet though--
You mean instead of the FacesServlet? Just have something that does the
same contract as FacesServlet. The trick is that FacesServlet is final,
but we can do it with composition rather than inheritance.
JH> public void execute(...) {
JH> if (some AJAX condition) {
JH> // do me
JH> } else {
JH> // do parent
JH> }
JH> }
JH> Then we can leave the UIViewRoot up as normal.
Yes, I was thinking the same thing. Subclassing UIViewRoot as the
mediator limits the custom component options.
JH> I still think we maybe need a filter--, but if your Lifecycle
JH> solution works as well as I think it will, we may not have to mess
JH> with additional stuff, but we do need to have an easy way of
JH> wrapping the outputstream/printwriter such that all viewhandlers
JH> don't have to deal with the details.
I'd like to avoid a filter. I want to minimize endpoint explosion, as
you know.
Ed
--
| ed.burns_at_sun.com | {home: 407 869 9587, office: 408 884 9519 OR x31640}
| homepage: | http://purl.oclc.org/NET/edburns/
| aim: edburns0sunw | iim: ed.burns_at_sun.com