Martin Marinschek wrote:
Exactly, that is the reason to go with faces. I personally dont really like the approach of faces too much, I see as to overly complicated, but it is the standard, and the tools which will ease the burdens of the overly complicated config file/backend mess are moving there rapidly into the right direction. In the long run it will be more like writing a Visual Basic program once the tools have matured. Sun IBM and others already are moving into that direction.I believe exactly this plethora of APIs was the reason to invent JSF in the first place - to have a common, standardized API that has that little edge with respect to the other technologies in place.
JSF may not be the better wheel, being more round than others ;) but it is the standardized wheel you will soon be able to plug in in any car (=J2EE Server) and use with any tool manufacturer (=Visual IDEs).
You will still have people who don't believe in the standard, but the
majority of the people will go there where the java community process
has put its vote - and usually with a base technology like web
engineering you will want to be there where the most of the action is;
except you have some very good reasons not to do so.
The whole backend/glueing API is more or less designed for tool developers not really for implementors in its current incarnation.
Anyway.... I think the mess is good, because many frameworks have different angles to the perspective of handling web based programs.
Tapestry, Velocity+Servlet for ease of use for the programmer and fast implementations,
Struts for doing MVC with a correct taglib behind it and groundwork for JSF, Turbine as an early approach of a multi frontend (you can use various render techniques including velocity) application base for web based apps, with an extensible service mechanisme for app services and so on...
