The focus of the visual component base solution would be to create a XML definition, backed beans, and an abstract factory/ cache to manage the resources. Create a view controller or action class that knows how to use the metadata to manage corresponding model classes. And view helpers that would encapsulate the call back to the models when generating a presentation.
It’s not as sexy as faces? Thanks for listening…
What you describe still sounds like it's essentially rewriting Faces-type functionality.
I think I'm warming up to Craig's point. The only reason we shouldn't use JSF is if we don't like the processing model it provides. If we like the processing model it provides, we shouldn't go to the trouble to rewrite it. Folks who want to do that can work on the MyFaces implementation instead.
My JSF experience is still limited to reading about it. I find it pretty interesting. I've read some commentary that pegs it as overkill, but haven't reached that conclusion myself. I'd be better off talking about it if I'd used it more.
The point being that JSF stakes out a lot of territory for the view-side of the equation. Craig's deep familiarity with it makes it a natural way for him to envision the view-controller side of Shale. If people think it's not a good solution to the view-controller side, then they should articulate why -- and even if the why is just "i'd rather not buy into JSF yet," then they should come up with an alternate description of the view controller's responsibilities. Then people can make a choice based on how it works rather than what its called.
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
