Text/expression-language-based paradigma continues?

Question

i've been working with jsp and struts for a while. the most significant drawback of jsp, custom tags/jstl and struts is its "runtime" binding caused by the heavy use of string-attributes and interpreted expressions.
it makes the coding itself harder (loss of compiler support and strong typing), it increases the amount of testing (automated tests, regression tests) extremely, it makes jsp-apps very hard to mantain, it is error-prone when changed or refactored, it is slower in execution and last but not james requires extra developement tools (such as struts-editors) to effectively maintain the applications.
but i like the paradigma of a web application that keeps a view state, handles "events" etc.
the only thing i can't understand is why jsf builds on the error-prone jsp/custom tag paradigma instead of compiled server side ui components. it obviuosly still tries to follow the myth, that web-designers and application developers can share their source (i.e. js-pages) by using tags. imo this is a degeneration of the good idea to leverage html by some custom tags. these tags empower designers to make their pages dynamic. (enterprise) software developement ist very different: complex use cases, business logic and often ui-"logic", integration issues etc...
the life cycle of a jsp with custom tags is weird (even more in struts):
- objects (variables in scriptlets) already existing in the scope of the jsp-execute-method are wrapped into attributes of page, request or application scope.
- tags are defined using string-based attributs, such as <html:write name="pinky" property="brain" />
- the implementation of the tag tries to look up the object in any of the scopes, starting with page scope
- if the object exists, it tries to read/set its property via reflection
so you lose strong typing, compile time checks and performance.
there are several frameworks that do not build upon jsp and tags but put in an extra layer. this layer is similar to a rich client "form" and renders the output into html or any other format.
so i'm not preferring any framework, just looking around and curious why this architecture has been chosen for jsf.
thanks
tom

Answer 1

the most significant drawback of jsp, custom tags/jstl and struts is its "runtime" binding
caused by the heavy use of string-attributes and interpreted expressions.I second this heartily.
but i like the paradigma of a web application that keeps a view state, handles "events" etc.
the only thing i can't understand is why jsf builds on the error-prone jsp/custom tag
paradigma instead of compiled server side ui components. The JSF - JSP connection is a major problem. More and more developers are starting to express reservations about it, because the two technologies don't play well together. But I think you've hit on an even deeper fundamental flaw in the equation -- the evils of runtime binding. The heavy JSF/JSP reliance on runtime evaluation is a reliability nightmare. Developers choose Java, in part, because of the robustness provided by compile-time checking. We give that up when it comes to JSF/JSP or Struts web applications, and that's an unacceptable state of affairs.
Winer says that "JSF has taken a major step in the right direction with the <managed-bean> and <referenced-bean> configuration elements. These give some hope for development tools to finally provide real code insight (and even error reporting) for EL expressions, because they define both what keys are used in the expression language and what types of objects may be at those keys." However, this will help with only the simplest EL expressions. As soon as an EL expression reaches into nested properties and maps that aren't defined in the config file, we're back to runtime binding and error reporting. The addition of generics to the language with 1.5 might have made it possible to introduce strong EL type checking at page compile time, but Sun's short-sighted type-erasure implementation of generics rules this out permanently.
Look at what Microsoft is doing with ASP.NET. It's not perfect, but the fundamental technology is based on compiled server side ui components. There are places in that framework where you can write expressions aren't evaluated until runtime, but it's certainly not the fundamental basis of the model as it is with JSF/JSP. And the .NET implementation of generics may make it possible to have these dynamic expressions type-checked at page compile time in a future implementation of .NET.
I keep reading comments from the JSF proponents who say things to the effect of "yes, we know JSP doesn't play well with JSF, but JSF allows you to plug in a different rendering technology." Well, we need one, and we need it urgently. ASP.NET has been out for two years now, and was far more polished and useable at its release than JSF is now after a very long development cycle.
Rightly or wrongly, people will judge JSF on the merits of the reference implementation. And I fear that a lot of developers are going to throw up their hands after a taste of the JSF/JSP world and move to .NET.
Stephen Schaub