I admit to a huge amount of ignorance about JSF. I have partly been stymied by an inability to decide on a text to read. I have always liked Hans work, and may go that direction. I cannot know, of course, how that ignorance impacts my part in this discussion. I do think that in any event it is wise for shale to accommodate but not be tied to a particular implementation, if there is no penalty for that, and I cannot see one. I have always found that allowing options in the long run.
Particular implementation of what?
View renderer? JSF can use Velocity to render its views, so it's not tied to JSP as the implementation of a view renderer.
View controller? JSF is an API, so you aren't tied to the reference implementation. In fact, there is an Apache incubator project (MyFaces) to build an alternative implementation: http://incubator.apache.org/projects/myfaces.html
Of course, there is no more generalized "view controller" API right now. Craig's point is that it would be substantially reinventing the wheel to design yet another API and implementation when JSF seems to address all the bases.
Craig is starting from his knowledge of JSF and proscribing it as a facility for providing a lot of functionality to Shale. If anyone cares to start from the other side and describe the functionality Shale needs, and finds that they don't end up essentially describing JSF, then we'd have something to choose between.
Joe
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place."
- Carlos Santana
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
