Can you please be more specific? One of the byproducts of the new state saving system is the ability for the server to keep an arbitrary number of views stored in the page. Therefore, the back button should "just work".

P.S. Internet Explorer 6.0 has been used for this test.
P.P.S. STATE_SAVING_METHOD=client forces to send several KB to the client each time. I disbelieve that developers will be happy to use this method.

... yet another example for the abuse of the MVC-Concept in a context that doesn't support MVC?

First, I must admit that I didn't read the JSF spec, but I'm familiar what JSF is.
I do not agree that JSF abuses MVC. Classic approach to development of web applications is very, very well suited for MVC approach, because there is natural and physical difference between the View (a web page, a HTML document) and a controller (i.e. servlet code running in the web container). But for event driven UIs (like windowing systems) MVC approach doesn't fit that extremely well, although it fits pretty well. When MVC is applied to event driven UIs then controller and view tends to be more mixed and line between them is somewhat blured. This is natural, because the code for controler and the code for the view are tightly connected by event dispathing mechanism.

JSF, as an event driven component system for web applications, also slightly couples view and controler as any event driven UI system does. I would not be concerned about this because this is natural for event driven UIs and development of complex UIs using event driven approach has been proved to be the most productive way.

Also, JSF is not the only and the best way to go for all web applications. For example, for corporate intranet applications that are developed as web applications only because they need to be accessesd over HTTP from remote sites, and that need a rich UI, I would use JSF (although true rich client using swing and EJB/CORBA/RMI should be considered seriosly for this scenario). But for web B2C sites like Amazon I would stay with JSP + JSTL and just maybe some poular web framework like struts.

Further, the MVC pattern has weaknesses, too. For example, when applying MVC, the presentation logic is often mixed with business process logic (under 'business process' logic I mean the business logic that correspondes to business process and do not naturally fit in the model code). Of course, good developers will differetiate and decouple presenatation and business process logic, but MVC as a pattern does not enforce this difference.

I find this terminology preferrable. Domain logic is the logic for which the classes in the domain model (the M in MVC) are responsible, and which could be reused in different business applications. Application logic is mainly the responsibility of the MVC Controller, but can also be implemented, at least partially, in the MVC Model (for example, in the Service Layer pattern, or with a Facade).

Sorry, but does it mean that B2C users do not need a rich UI or JSP+ JSTL does

not allow you to create it?

There is certenly less need for ruch UI for B2C sites then for intranet apps. Under rich UI I mean coplex controls with server side events like tree control, editable grid control, tab control etc. (Although tree control and tab control could be controls only with client side events (JavaScript), sometimes there is a need for such controls that have server side events, like presenting large tree hierarchies or if content of a tab page is too large to download with other tabs)

Alothough rich UI (with complex controls and server side events) can be developed
using JSP + JSTL (we did), it needs developing a lot of infrastructure code that JSF has.

Also (for 'Amazon' case), any event driven web component system will be slower then JSP and I would avoid using it for high throughoutput sites.

I am a real fan of JSF and the idea behind it, and it seems like the JavaServer Faces framework may give some real solutions to some of the main problems of java based web developement.

Having said all that, i get the feeling that sun is dragging this project for too long.
For quite sometime now, we have been hearing and learning of the framework's (JSF)capabilities, yet practically we can not consider it as a real practical solution for the near future, and in addition there are many solutions based on similar principles that offer a real solution (Oracle's solution for instance ).

my message to sun as a corporate developer is, we do not expect the framework to be perfect but don't make us wait for too long

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.