Admittedly I haven't read the spec, but I'd rather just ask in case someone knows...

Have the "back button issues" been fixed?

Cheers,
Clinton

Having difficulties downloading the spec..!

Is it just me ?

Have the "back button issues" been fixed?

I dont think so.

>
> I dont think so.

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".

Ed

>>
>> I dont think so.

>Can you please be more specific?

1. Take guessNumber example
2. Set javax.faces.STATE_SAVING_METHOD=server (default value, BTW)
3. Launch example
4. Click Submit
5. Click _Browser_ Back Button
So far, so good.
6. Click Submit
No action (page is refreshed)
7. Click Submit again
Now, "Sorry" page is shown
8. Click _Browser_ Back Button
No action (page is refreshed)
9. Click _Browser_ Back Button again
We are back!

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?

Looking at the specs and examples, seperation of design and logic has completely vanished. So the programmer better learns how to design webpages or the designer learns how JSF works...

Brave New Web ;(

  -Markus

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.

Mileta

I meant to say: good developers will differetiate and decouple presenatation LOGIC and business process logic ...

Too bad there is no editing functionality for user's own messages on the TSS, ;)

Or in Martin Fowler's terms:

Business logic = application logic + domain logic

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).

>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.

Sorry, but does it mean that B2C users do not need a rich UI or JSP+ JSTL does
not allow you to create it?

Dmitry Namiot
Coldbeans

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

Dovik