Craig McClanahan has announced a plan to integrate Spring Web Flow and JSF, with requirements and a possible approach, on the Spring framework developer mailing list. He goes into a lot of detail about existing technology (focusing on Shale), and then proposes using Spring Web Flow to manage dialogs.

The end result is an environment with some very important benefits resulting:

* Outside of the dialogs world, standard JSF things work in the usual way.
 
* Dialogs can reuse actions and view states (including those that are also accessed directly via standard JSF facilities), because the interpretation of the logical outcome is specialized per dialog.
 
* As with SWF, the configuration of a dialog (or a flow) is very much amenable to tool-aided support like graphical drag-n-drop development of the overall flow -- as well as for more formal UML-based tool support.
 
* Because of the other capabilities provided by Shale, an application will typically need fewer "setup" action states (because the prerender() method of a ViewController can take many of these responsibilities) and less work in what is typically a "bindAndValidate" action in Spring (because JSF has its own support for validation processing that preceeds such a state). But these are just icing on the cake -- the key values of having managed dialogs are independent of Shale.

Do you think this is a good approach? Does Spring Web Flow need Shale or JSF to fill certain needs, or vice versa, as Mr. McClanahan seems to see it?

I know that Craig is impressed with some of the ideas behind the WebFlow and he is actually making two logical steps:

A. He is incorporating some of the very innovative techniques from the WebFlow 'as is' instead of re-implementing them as JSF.

B. Spring is enjoying a tremendous popularity, and in order to get JSF/Shale more exposure he is trying to fit JSF/Shale with it.

The key thing is that both Spring WebFlow team and Craig M. are actually very cooperative and reasonable people, so I expect that this may work out for both. Spring has nothing to loose, and JSF/Shale can only gain from it.

This still does not warrant better adoption rate for
JSF/Shale - it just gives it a better chance.

Well, since I belive tapestry is a much more well structured and mature project, why not this? Hasn't HLS ever think about it?

Well, since I belive tapestry is a much more well structured and mature project, why not this? Hasn't HLS ever think about it?

Personally, I've never developed anything real with Tapestry, but I have to say I am impressed with it's power and non-invasiveness. Still I'm spending most of my time now developing in JSF, and for the same reason Craig isn't going to suggest implementing WebFlow + Tapestry...It has industry support! Tapestry might be more mature, but it's a single project and none of the major companies have adopted it yet. This is the same reason why we're still using relational databases and ORM mapping instead of using object-oriented databases...None of the big companies ever ran with the idea. Get Oracle to support Tapestry and you'll have everyone wanting to integrate their frameworks with it. Until then JSF is where it's at. That's how the world works.

It's not necessary that the big players set the rules all the time. Example: EJB vs Spring. EJB was well supported by all the big players but it was not a success (let's not argue over the definition of success). In contrast the community thrived because of spring and largely spring came because of complexity of EJB.

JSF is way too cumbersome too use and I won't like to use it just because the big players are pushing for it. They are pushing for it because the user needs to buy other tools to develop the application. I am happy to use dreamweaver, tomcat and mysql to develop my app using tapestry.

- Neeraj

JSF is way too cumbersome too use and I won't like to use it just because the big players are pushing for it. They are pushing for it because the user needs to buy other tools to develop the application.

I find these to be strange criticisms. I like JSF precisely because I find it lightweight to use. I had assumed the myth that tools are needed to develop JSF application had been dispelled a while back.

Well, since I belive tapestry is a much more well structured and mature project, why not this? Hasn't HLS ever think about it?

One of the luxuries of JSF is that while it is a very loose API and not as 'developed' as Tapestry in implementation, it allows developers to pull in just about any other technology into the framework-- such as WebFlow, or as Struts is heading with a whole new controller layer.

One of the luxuries of JSF is that while it is a very loose API and not as 'developed' as Tapestry in implementation, it allows developers to pull in just about any other technology into the framework-- such as WebFlow, or as Struts is heading with a whole new controller layer.

I would say a bit differently:
One of the shortcomings of JSF is that it is a very loose API and not as 'developed' as Tapestry in implementation, therefore it forces developers to pull in just about any other technology into the framework to make it suitable for real world use.

As for ORACLEs support for Tapestry: it is hard to get software vendors support for Tapestry especially because the framework simply works, so there is not much room for them to build and sell something. JSF is a whole different story: tools are needed, people need to be retrained etc. In other words JSF is a sweet software vendor dream.

It is software users (big non-software vendor corporations) must say no to vendor’s push of technologies for the sake of technologies.

I would say a bit differently:

One of the shortcomings of JSF is that it is a very loose API and not as 'developed' as Tapestry in implementation, therefore it forces developers to pull in just about any other technology into the framework to make it suitable for real world use.

Konstantin, if it makes you feel better, I will be releasing a JSF add-on called, "Facelets" which gives you the same luxuries as Tapestry for defining pages and actually performs the same as compiled JSP pages. One of the upshots of this framework over Tapestry is that you don't have to maintain lots of extra XML definitions, it's super developer friendly and easy to plug in components that are templated in other HTML files.

Konstantin, if it makes you feel better, I will be releasing a JSF add-on called, "Facelets" which gives you the same luxuries as Tapestry for defining pages

Templating for JSF will be a welcome addition to JSF for sure and will make me feel better when/if it will provide same convenience and holistic approach as Tapestry. Lets see.

and actually performs the same as compiled JSP pages.

LOL, I did not do my little tests for a while but when I did, that compiled JSP routinely performed about 30% worse than parsed every time Velocity template. For the same CRUD type page.

In my experience JSP and Tapestry perform about the same for comparable complex pages, please lets not start that benchmark nonsense. You know better

...please lets not start that benchmark nonsense. You know better

Can't blame a guy for trying ;-)

I will be releasing a JSF add-on called, "Facelets" which gives you the same luxuries as Tapestry for defining pages and actually performs the same as compiled JSP pages. One of the upshots of this framework over Tapestry is that you don't have to maintain lots of extra XML definitions, it's super developer friendly and easy to plug in components that are templated in other HTML files.

It'll be interesting to see how that plays out. As I understand it, you'll be tossing out most of the JSF tool support with the JSP view technology.

Hope you're keeping up to date on Tapestry 4.0 ... the templates are getting simpler, the XML is being reduced and eliminated, and I'm seeing a number of performance improvements based on improved runtime code generation and having alternatives to OGNL for many situations (in Tapestry terms, more binding prefixes that are not based on reflection, as OGNL is).

Performing the same as JSPs is a somewhat dubious goal. Certainly, the amount of overhead in terms of pooling each individual tag instance every time is renders is a bit daunting. Tapestry pools at the page level (an entire page and all the components and machinery below it) which speeds up rendering and opens up a large number of opportunities for optimizations.

Meanwhile, I'm going to be working on a project over the summer where, hopefully, I'll be using Spring Web Flow, so I'll have a chance to see how well I can get Tapestry (hopefully 4.0) connected to that. From my conversations with Keith & co., should not be a problem.

Performing the same as JSPs is a somewhat dubious goal. Certainly, the amount of overhead in terms of pooling each individual tag instance every time is renders is a bit daunting. Tapestry pools at the page level (an entire page and all the components and machinery below it) which speeds up rendering and opens up a large number of opportunities for optimizations.

Basically Facelets compiles the HTML in a format similar to Veclocity's use of Javacc, but because state is being represented by JSF's component tree, the Facelet is actually stateless (no pooling) and simply creates/populates UIComponent trees. This can potentially increase performance quite a bit since the Facelet is *static*, literals are literals, EL is dynamic and everything gets evaluated/transferred to UIComponent trees. In addition, the development is the same as JSPX, with some added tags/attributes to accomodate JSF (so some current JSP IDEs/XML editors will be able to develop Facelets).

-- Jacob Hookom (EL-API & JSR 252 EG)

One of the luxuries of JSF is that while it is a very loose API and not as 'developed' as Tapestry in implementation, it allows developers to pull in just about any other technology into the framework-- such as WebFlow, or as Struts is heading with a whole new controller layer.

I would say a bit differently:One of the shortcomings of JSF is that it is a very loose API and not as 'developed' as Tapestry in implementation, therefore it forces developers to pull in just about any other technology into the framework to make it suitable for real world use.

Having now used JSF for several real-world applications I have not found this to be the case. I have found 'raw' JSF to be a rich and powerful API. I would be interested in why you think that a developer would be 'forced to pull in just about any other technology'.

Tapestry might be more mature, but it's a single project and none of the major companies have adopted it yet. This is the same reason why we're still using relational databases and ORM mapping instead of using object-oriented databases...None of the big companies ever ran with the idea. Get Oracle to support Tapestry and you'll have everyone wanting to integrate their frameworks with it. Until then JSF is where it's at. That's how the world works.

Will people ever stop giving crappy arguments like that? Where would Hibernate be? And Spring? And (list goes on)...

Will people ever stop giving crappy arguments like that? Where would Hibernate be? And Spring? And (list goes on)...

Hibernate will be where it is, without EJB 3.0 compatibility will never get enterprise attention.
Spring - what is spring? You hope it's used in enterprise projects?

Will people ever stop giving crappy arguments like that? Where would Hibernate be? And Spring? And (list goes on)...

Hibernate will be where it is, without EJB 3.0 compatibility will never get enterprise attention.Spring - what is spring? You hope it's used in enterprise projects?

It is. We have built a full wholesale commerce site on it, running since december without a glitch, serving hundreds of thousands of users. Moreover, the backoffice for product management, promo management and in the future content management has been built on it. Even more: we are using its "low-level" ioc and jdbc features for all our integration tasks. A wonderful framework, indeed.

It is. We have built a full wholesale commerce site on it, running since december without a glitch, serving hundreds of thousands of users. Moreover, the backoffice for product management, promo management and in the future content management has been built on it. Even more: we are using its "low-level" ioc and jdbc features for all our integration tasks. A wonderful framework, indeed.

Congratulation, however I always have to work with WebLogic, WebSphere, Oracle, Tuxedo. No escape from this trap. I'm still surprise why you stick with Spring instead of tomcat or JBoss. I really don't expect Spring will make some inroad into enterprise.

Congratulation, however I always have to work with WebLogic, WebSphere, Oracle, Tuxedo. No escape from this trap. I'm still surprise why you stick with Spring instead of tomcat or JBoss. I really don't expect Spring will make some inroad into enterprise.

Spring runs on Tomcat. It is not a servlet engine, it is an IOC container along with additional services. I guess you never tried Spring. You can run in on Weblogic.

Spring runs on Tomcat. It is not a servlet engine, it is an IOC container along with additional services. I guess you never tried Spring. You can run in on Weblogic.

I tested Spring more times. However I don't understand real value of IOC (I understand technology but don't understand advantages). Same things should be achieved much simpler way. And specialy when you start to use things like JDBC different way than J2EE proposed, what is additional value of it for developer or customer?

Spring runs on Tomcat. It is not a servlet engine, it is an IOC container along with additional services. I guess you never tried Spring. You can run in on Weblogic.

I tested Spring more times. However I don't understand real value of IOC (I understand technology but don't understand advantages). Same things should be achieved much simpler way. And specialy when you start to use things like JDBC different way than J2EE proposed, what is additional value of it for developer or customer?

Sorry Pavel but I am not sure whether to laugh or cry. :(

tested Spring more times. However I don't understand real value of IOC (I understand technology but don't understand advantages). Same things should be achieved much simpler way. And specialy when you start to use things like JDBC different way than J2EE proposed, what is additional value of it for developer or customer?

Sorry Pavel but I am not sure whether to laugh or cry. :(

I suggest thinking :)

Spring runs on Tomcat. It is not a servlet engine, it is an IOC container along with additional services. I guess you never tried Spring. You can run in on Weblogic.

I tested Spring more times. However I don't understand real value of IOC (I understand technology but don't understand advantages). Same things should be achieved much simpler way. And specialy when you start to use things like JDBC different way than J2EE proposed, what is additional value of it for developer or customer?

It is amazing to see peole comment on things they don't really know much about. Why are people so fond of expressing themselves in public? Need more attention?

It is amazing to see peole comment on things they don't really know much about. Why are people so fond of expressing themselves in public? Need more attention?

I'm not making press release, I'm asking in discussion group. However not everybody understand purpose of question and discussion. You are one of them but I don't understand why are you making such stupid messages to discussion.

In the last 2 years as a consultant I have only used Hibernate/Spring for big customers in the financial and telcom industries.
so yes, it is used in enterprise projects.

Will people ever stop giving crappy arguments like that? Where would Hibernate be? And Spring? And (list goes on)...

Hibernate will be where it is, without EJB 3.0 compatibility will never get enterprise attention.Spring - what is spring? You hope it's used in enterprise projects?

In the last 2 years as a consultant I have only used Hibernate/Spring for big customers in the financial and telcom industries.
so yes, it is used in enterprise projects.

Will people ever stop giving crappy arguments like that? Where would Hibernate be? And Spring? And (list goes on)...

Hibernate will be where it is, without EJB 3.0 compatibility will never get enterprise attention.Spring - what is spring? You hope it's used in enterprise projects?

This is a completely incorrect oberservation of what happened and is happening in the industry.

e.g. has Struts also been pushed by vendors (Oracle etc.)?? Most major financial institutions use Struts in some projects (if they have developed J2EE based Web applications) here in Australia. Some Federal government agencies (Australia) have also standardised on Struts for Java Web development. As Mr McL himself once said, the main obstacle for the adoption of JSF is the widespread use of Struts. Even there is huge support behind JSF from big vendors.

Also, JSF is probably too little, too late. As the trend will slowly move away from browser based to smart client (WinForm.NET type of smart client, not ASP.NET) for corporate Intranet applications (where J2EE is widely used, probably more so than other Web technologies such as ASP classic, or PPP (Perl/Python/PHP)), as corporate desktops slowly migrate to post Win2000/XP.

Also, JSF is probably too little, too late. As the trend will slowly move away from browser based to smart client (WinForm.NET type of smart client, not ASP.NET) for corporate Intranet applications (where J2EE is widely used, probably more so than other Web technologies such as ASP classic, or PPP (Perl/Python/PHP)), as corporate desktops slowly migrate to post Win2000/XP.

JSF was designed to cope with this sort of trend. Quoting from the JSF FAQ:

"Because the JavaServer Faces technology architecture separates the definition of a component from its rendering, you can render your components in different ways or even to different clients, such as a WML client."

So, JSF is not restricted to rendering web pages. RenderKits could be plugged in for almost any UI technology.

JSF was designed to cope with this sort of trend. Quoting from the JSF FAQ:"Because the JavaServer Faces technology architecture separates the definition of a component from its rendering, you can render your components in different ways or even to different clients, such as a WML client."So, JSF is not restricted to rendering web pages. RenderKits could be plugged in for almost any UI technology.

The problem is not in rendering, but rather in application state.
Rich clients completely control their state locally as opposing to ASP/JSP/PHP/Tapestry/WebWork/Struts and now JSF which handle application state on server side.

Of course you can say use AJAX bla bla. But that does not ease development and still presents web related issues like Back button, session expiring, etc.

JSF was designed to cope with this sort of trend. Quoting from the JSF FAQ:"Because the JavaServer Faces technology architecture separates the definition of a component from its rendering, you can render your components in different ways or even to different clients, such as a WML client."So, JSF is not restricted to rendering web pages. RenderKits could be plugged in for almost any UI technology.

The problem is not in rendering, but rather in application state.Rich clients completely control their state locally as opposing to ASP/JSP/PHP/Tapestry/WebWork/Struts and now JSF which handle application state on server side.Of course you can say use AJAX bla bla. But that does not ease development and still presents web related issues like Back button, session expiring, etc.

That brings us back to the start of this thread. Integrating Spring Web Flow with JSF helps with exactly these issues.

Integrating Spring Web Flow with JSF helps with exactly these issues.

How so ? Does Spring Web Flow eliminates server side state ?
I do not think so.
On the contrary, Spring Web Flow operates solely on server side, and is completely useless for rich clients, because it is fixing the problem rich clients do not have.

Integrating Spring Web Flow with JSF helps with exactly these issues.

How so ? Does Spring Web Flow eliminates server side state ?

Those were not the issues you described. You said:

But that does not ease development and still presents web related issues like Back button, session expiring, etc.

I do not think so.On the contrary, Spring Web Flow operates solely on server side, and is completely useless for rich clients, because it is fixing the problem rich clients do not have.

Spring Web Flow operates solely on the server side, but JSF need not. It can save state in the client and components can make use of client-side technologies (such as JavaScript and SVG).

Steve, you are confusing the discussion.
You answered
"JSF was designed to cope with this sort of trend. Quoting from the JSF FAQ:"

when George Jiang claimed, that with coming rich clients, do their job much better than JSF or JSP/ASP or any other web frameworks.

So you meant that JSF will render rich clients. ?
Because Ajax is not a rich client. It is a hack in web browser.

And if by rich clients you mean HTML + javascript? then we have different opinions on that.

But if you mean JSF can deliver full blown client side applications, then please show me how, because i do not know.

Steve, you are confusing the discussion.

I hope not.

You answered "JSF was designed to cope with this sort of trend. Quoting from the JSF FAQ:"when George Jiang claimed, that with coming rich clients, do their job much better than JSF or JSP/ASP or any other web frameworks.So you meant that JSF will render rich clients. ?

I believe that it will - see my comments below.

Because Ajax is not a rich client. It is a hack in web browser.

I know.

And if by rich clients you mean HTML + javascript?

I don't.

But if you mean JSF can deliver full blown client side applications, then please show me how, because i do not know.

I don't use 'rich client' to mean 'full blown client side'. There are already perfectly good APIs for that, such as Swing. I use 'rich client' to mean vastly better GUIs for applications that still have considerable server-side logic. You may have a different definition!

An example of a 'rich client' GUI is Flash. Well, some developers have, I believe, already demonstrated a Flash RenderKit for JSF. The ability to plug in such RenderKits is how JSF can deliver what I would consider to be 'rich client' GUIs. I apologise if I have been confusing terms here.

Good. We figured out confusion.
By rich client we mean different things.
Now when we know it, explain me please what does it give me to create screens in flash, if i have to use server side technology just to move from one screen to another ?
Obviously native apps and/or webstart swing clients have big advantage here. They do not need a server to tell them what screen to open next :)

Good. We figured out confusion.By rich client we mean different things.Now when we know it, explain me please what does it give me to create screens in flash, if i have to use server side technology just to move from one screen to another ?

You don't have to. You don't have to bind *every* event or component to JSF - just enough to do what you want to do on the server. Just because JSF can be set to render all the controls on a page or pages, doesn't mean that everything on a page or pages has to be under the control of JSF.

Obviously native apps and/or webstart swing clients have big advantage here. They do not need a server to tell them what screen to open next :)

Again, this depends on how much or how little logic you want to put on the client or server.

this depends on how much or how little logic you want to put on the client or server.

The title of this topic (WebFlow, remember ?) clearly defines what client wants from server. Which screen to go next !!! :))

Otherwise why whould you need a WebFlow ?

this depends on how much or how little logic you want to put on the client or server.

The title of this topic (WebFlow, remember ?) clearly defines what client wants from server. Which screen to go next !!! :))Otherwise why whould you need a WebFlow ?

LOL, is Vagif just another alias used by Konstantin for picking more arguments that lack any substantial conclusion and basically boil down to debates over interpretations of common terminology?

Smart client is the GUI tier of the classic 3 tier architecture (GUI/Business Component/Database)in a new jacket. This new jacket is made of materials such as on-demand deployment (instead of manual installation) and Web Services (in stead of DCOM/RMI/Remote EJB).

My apology for talking about smart client under the wrong title.

What does it give me to create screens in flash, if i have to use server side technology just to move from one screen to another?

I don't see no point at all to create screens in Flash, but this is another topic and more of a religious issue.

Obviously native apps and/or webstart swing clients have big advantage here. They do not need a server to tell them what screen to open next :)

That does not mean that they do not move next. What about wizard dialogs? You click Next or Back, and it shows you next or previous panel. The same can be done using web technologies. What is the difference? Ah, the Back button. Please, do me a favor. Go to the wizard demo, if you have not done it yet. Please, open this link in a new window. If you use Opera, I am screwed, but if you use MSIE or Mozilla/Firefox, you would notice, that Back and Forward button are not enabled at all, while you navigating forward and back in the wizard. Refresh works too. Even if you made a mistake, and error message is shown. Click refresh -- here is the same page, along with messages.
So, the only downside is whole page refresh, but with AJAX it won't be an issue.

<That does not mean that they do not move next. What about wizard dialogs? You click Next or Back, and it shows you next or previous panel. The same can be done using web technologies.

That's my point. If you do it with rich client, the logic of next and back buttons, as the screens themselves posessed by client.
In case of web technologies this logic and even those "Next" screens resides on server.
This means that VB developers do not need to ask Programmer Gurus like Rod Johnson, or Howard Lewis Ship develop for them quite complicated products just to do this simple task of progressing from screen to screen.

It is not about rendering, it is about bringing back ease of GUI development, that java and web programmers lost long time ago.
Look at this madness. Frameworks on top of frameworks, just to be able to go from 1 screen to another.

In case of rich client, server does not need to know at what screen you are and where you are heading next. It should merely serve your requests for data.
And lot's of statefull web applictaions can be made stateles just by developing rich clients for them, making developmet much simpler and faster, and rendering useless all those excelent but complicated products like WebFlows or Struts or whatever.

With rich client all you need is web services or just plain servlets.

So if you look from this point of view, eg making development of GUI realy easy. JSF or any other web technology does nothing in that matter.
And the only thing that still gives JSF/JSP time to live - is absence of good delivery technology for rich clients.

I think ClickOnce will change it. And in couple of years nobody will use JSF, JSP, ASP, or any other web technology for company projects.
Although for dealing with customers like Amazon or Ebay does web technologies are still preferrable. But that's not for long too.

<That does not mean that they do not move next. What about wizard dialogs? You click Next or Back, and it shows you next or previous panel. The same can be done using web technologies.

That's my point. If you do it with rich client, the logic of next and back buttons, as the screens themselves posessed by client.In case of web technologies this logic and even those "Next" screens resides on server.

I have just described that this need not be the case.

eg making development of GUI realy easy. JSF or any other web technology does nothing in that matter.

That is a strange comment, considering that JSF was designed specifically for the purpose of making server-side GUI development easy, and, in my opinion, it certainly does.

And the only thing that still gives JSF/JSP time to live - is absence of good delivery technology for rich clients.I think ClickOnce will change it. And in couple of years nobody will use JSF, JSP, ASP, or any other web technology for company projects.Although for dealing with customers like Amazon or Ebay does web technologies are still preferrable. But that's not for long too.

I completely disagree with this. There may be a progression to richer clients, but that will happen over a very long time indeed, certainly not in just a couple of years. Firstly, some sort of standard portable rich client system would have be accepted, and available on the increasingly wide range of platforms and devices that are coming into use. This is why a technology like JSF is important, as it allows a range of renderkits to be installed to deal with this range of clients.

That does not mean that they do not move next. What about wizard dialogs? You click Next or Back, and it shows you next or previous panel. The same can be done using web technologies.

That's my point. If you do it with rich client, the logic of next and back buttons, as the screens themselves posessed by client.In case of web technologies this logic and even those "Next" screens resides on server.

I would prefer logic to be on the server, but all rendering on the client, including standard UI primitives, cache for UI objects, etc. Something like NEWS.

I would prefer logic to be on the server, but all rendering on the client, including standard UI primitives, cache for UI objects, etc.

You mean you would agree to give up your mighty computer and replace it with dumb terminal ? :))

I would prefer logic to be on the server, but all rendering on the client, including standard UI primitives, cache for UI objects, etc.

You mean you would agree to give up your mighty computer and replace it with dumb terminal ? :))

NeWS is not a dumb terminal. It is a smart terminal.

JSF or any other web technology does nothing in that matter.And the only thing that still gives JSF/JSP time to live - is absence of good delivery technology for rich clients.I think ClickOnce will change it. And in couple of years nobody will use JSF, JSP, ASP, or any other web technology for company projects.Although for dealing with customers like Amazon or Ebay does web technologies are still preferrable. But that's not for long too.

Against my better judgement, I'm going to disagree with you. I've spent years in the dot com industry and what I've found is that 'common' users are more comfortable with interfacing with web sites now days than windows applications.

With web pages, there's no right clicking, no sub menus within menus, you have a screen with links. Your mom can understand that. As soon as you start tossing in all of these sub dialog flows and pop up menus, you've over engineered your application to a point of it being junk and unusable without a manual. Yeah, you the developer thinks it's special, but to the 'dumb' user--

I'm just talking from experience, web applications work for everyone. Rich client apps with all of over-engineered bells and whistles don't and consequently require training. In most cases, that means you've failed.

So I don't sound completely off topic, that client/server separation is great. Things like flow managment on the *server* take care of herding 'dumb' users through complicated flows by simplifying things to a request/response model.

-- Jacob Hookom (McKesson Medical-Surgical)

Rich client apps with all of over-engineered bells and whistles don't and consequently require training.

Some complicated UI requirements do require more complicated (or more sophisticated) screens than Web pages.

But UI is not the only shortcomings of browser based client. Response time and scalability are the two other as important issues with browser based application, which will be addressed by smart client. Think about a corporate Intranet application with 3000 concurrent users working with it all the the time, with multiple such applications deployed on the same server cluster.

Browser based application put too much unnecessary strain on the server (server session state) and the network (client session state) and the database (the same records are re-read again and again because the stateless nature of browser based client).

The only solution here, I think, is smart client.

Let me repeat someone else's statement from a previous post. With browser client, you are treating your powerful PC as a dumb terminal!!

Rich client apps with all of over-engineered bells and whistles don't and consequently require training. In most cases, that means you've failed.

I do not see the link between rich client and overengineering GUI.
Why do you think conventional GUI has to be overengineered ?
All i want is that grids allow users sort by clicking on columns and do not wait until page reloads.
All i want that they can edit records in grids with nice dropdowns and calendars. And do not see weird javascript errors, just because windows automaticaaly installed yet another patch on IE.
And nice tree components, and master-detail views.

Yes, all this can be done with HTML + javascript. But effort is overhelming. While in rich clients you just drop components on screen, setup some properties and they work.

Again. Nothing forces you use right click menus everywhere just because you have that ability.
Infact when you said that, i'm looking through lot's of windows client applications i made all these years, and do not remember a single right click menu in them :))

You are confusing somebodys problem with rich client platform altogether.

IMHO rich clients and web clients are not in direct competition. In some situations you want a rich client (e.g. complex Intranet apps), while other situations are better served using web clients (e.g. something like Amazon).

Trying to build a rich client using web technology can be painfull. The inverse is also true.

Having said that, I do think that currently web clients just have so much more momentum (e.g. widespread use, extensive body of knowledge available, a lot of experience developing this kind of app, 'corporate programmers' are familiar with it, company adoption, ...) that I don't see a drastic move to rich clients in the near future.

Erwin

All i want is that grids allow users sort by clicking on columns and do not wait until page reloads.All i want that they can edit records in grids with nice dropdowns and calendars. And do not see weird javascript errors, just because windows automaticaaly installed yet another patch on IE.And nice tree components, and master-detail views.Yes, all this can be done with HTML + javascript.

Apart from the 'wait until page reloads' for the grid sort, you have just described what current JSF implementations provide (and I'm sure someone could get around that for the grid sort).

If you are using components written by someone else, why should you care how it is done? You just use it.

While in rich clients you just drop components on screen, setup some properties and they work.Again.

You have just described how Studio Creator can be used.

Against my better judgement, I'm going to disagree with you. I've spent years in the dot com industry and what I've found is that 'common' users are more comfortable with interfacing with web sites now days than windows applications.With web pages, there's no right clicking, no sub menus within menus, you have a screen with links...

Then why do users keep asking for the functionality of a desktop client from the web client?

This "client-side-only" rich client would be wonderful indeed (back to client-server days), only if there would be only desktop computers in the future. But this does not seem to be the case: we have to take palmtops, cell phones, tablets into account too, so this "code once, deploy anywere" may not be so easily encompassing.
The closest I have ever come to this dream is thinlets, but even with this tool I am not sure universal deployment of client-server apps can be achieved, this is something only time will prove.
The problem, as always, is requiring a runtime at the client. There is already an universal "runtime" installed in every desktop: the browser. And every user knows how to use it. This will be a very hard to beat environment for a long time.

Regards,
Henrique Steckelberg

But this does not seem to be the case: we have to take palmtops, cell phones, tablets into account too, so this "code once, deploy anywere" may not be so easily encompassing.

Oh comon ! Where did you see web app that is written for the desktop format, and yet can be run on PDA ?
If you are targeting PDA with your web app, you will have to provide PDA version as well. Because otherwise your web app will be pain in the neck on PDA. It is not write once.

And as far as tablets. They run same OS as desktops - windows XP tablet edition, and have quite big screens.
So dotnet app can run on both desktop and tablet devices same way.

You just wait till MS gives developers and users painless way to distribute rich clients.
The rich client market will explode.
This alone will be enough to change once and for all the way we develop distributed apps.
I'm not saying that web technologies will die.
They will be used for huge internet sites dealing with millions of customers.

But for intranet/internet company/departamental Apps rich clients is the near future.

But this does not seem to be the case: we have to take palmtops, cell phones, tablets into account too, so this "code once, deploy anywere" may not be so easily encompassing.

Oh comon ! Where did you see web app that is written for the desktop format, and yet can be run on PDA ?If you are targeting PDA with your web app, you will have to provide PDA version as well. Because otherwise your web app will be pain in the neck on PDA. It is not write once.

Couple of years ago we delievered Struts-based app. Works with WML-enabled cell phones, voice phone interface using VoiceXML, and of course HTML. Oh, it has SMS link too, through separate web service.

The business classes, EJBs, database, Struts actions -- they all were written once. JSPs are different for each client. And yes, SMS web service does not use Struts actions.

Oh comon ! Where did you see web app that is written for the desktop format, and yet can be run on PDA ?If you are targeting PDA with your web app, you will have to provide PDA version as well. Because otherwise your web app will be pain in the neck on PDA. It is not write once.

That is very true!

But that's why JSF introduced renderkits-- wml, xhtml, etc. Take a component approach to UI development, yes, your WML UI isn't going to be the same as your HTML UI, but both UI's could be using the same component, just different renderkits. Example, a menu component that contains all of the logic for what a user can/can't use. This could have it's own inheritance heirarchy, but provide two different ways of rendering to the screen/device.

JSF also has the concept of UIData components. Your logic could be retained/reused within a UIData component, but pushed to different renderkits based on if the user was accessing that data via a phone or web browser.

-- Jacob

That is very true!But that's why JSF introduced renderkits-- wml, xhtml, etc. Take a component approach to UI development, yes, your WML UI isn't going to be the same as your HTML UI, but both UI's could be using the same component, just different renderkits. Example, a menu component that contains all of the logic for what a user can/can't use. This could have it's own inheritance heirarchy, but provide two different ways of rendering to the screen/device.

Or one can stream raw XML data to the client, format it with platform-dependent XSL and style it with platform-dependent CSS.

I think ClickOnce will change it. And in couple of years nobody will use JSF, JSP, ASP, or any other web technology for company projects.

It is not ClickOnce that will change it - but Microsoft (IBM and Sun) saying "web app developement stinks."

That's my point. If you do it with rich client, the logic of next and back buttons, as the screens themselves posessed by client.In case of web technologies this logic and even those "Next" screens resides on server.This means that VB developers do not need to ask Programmer Gurus like Rod Johnson, or Howard Lewis Ship develop for them quite complicated products just to do this simple task of progressing from screen to screen.It is not about rendering, it is about bringing back ease of GUI development, that java and web programmers lost long time ago.Look at this madness. Frameworks on top of frameworks, just to be able to go from 1 screen to another.In case of rich client, server does not need to know at what screen you are and where you are heading next. It should merely serve your requests for data.And lot's of statefull web applictaions can be made stateles just by developing rich clients for them, making developmet much simpler and faster, and rendering useless all those excelent but complicated products like WebFlows or Struts or whatever.With rich client all you need is web services or just plain servlets.So if you look from this point of view, eg making development of GUI realy easy. JSF or any other web technology does nothing in that matter.And the only thing that still gives JSF/JSP time to live - is absence of good delivery technology for rich clients.I think ClickOnce will change it. And in couple of years nobody will use JSF, JSP, ASP, or any other web technology for company projects.Although for dealing with customers like Amazon or Ebay does web technologies are still preferrable. But that's not for long too.

Very good points. But seems unproductive if try to argue with Zara.

And in couple of years nobody will use JSF, JSP, ASP, or any other web technology for company projects.Although for dealing with customers like Amazon or Ebay does web technologies are still preferrable. But that's not for long too.

Very good points. But seems unproductive if try to argue with Zara.

Yes, it is unproductive to argue with me unless you are prepared to provide evidence rather than opinion. I am quite prepared to change my mind about things if we are discussing matters of fact. For example, if someone is seriously suggesting that JSF, JSP and ASP are going to vanish in only a few years, that is such an extreme claim it needs strong evidence to back it.

this depends on how much or how little logic you want to put on the client or server.

The title of this topic (WebFlow, remember ?) clearly defines what client wants from server. Which screen to go next !!! :))Otherwise why whould you need a WebFlow ?

What it actually does is provide a system for managing server-side business processes which span several HTTP requests. In most cases this will be dealing with individual 'screens', but it need not. For example, there could be client-side components which open up dialogs within the screen, or all kinds of actions could happen client-side between one HTTP request and another.

I know that Craig is impressed with some of the ideas behind the WebFlow and he is actually making two logical steps:A. He is incorporating some of the very innovative techniques from the WebFlow 'as is' instead of re-implementing them as JSF.B. Spring is enjoying a tremendous popularity, and in order to get JSF/Shale more exposure he is trying to fit JSF/Shale with it.The key thing is that both Spring WebFlow team and Craig M. are actually very cooperative and reasonable people, so I expect that this may work out for both. Spring has nothing to loose, and JSF/Shale can only gain from it.This still does not warrant better adoption rate for JSF/Shale - it just gives it a better chance.

Well depends, I dont think JSF needs more exposure, lots of people here (including me) combine JSF with Spring, there are a few points where they overlap (but only a few), basically just in the area of IOC, nowhere else, so using JSF for the UI layer and using Spring for the other layers is a valid approach, Spring has heven integrated JSF connectors, however the ones you can find on Sourceforge are better.

As for webflow I dont really see yet (ok I have not checked it out fully) where it adds something, to the page flow handling JSF already has. JSF however lacks in scopes other than session,request and application, some kind of subsession scope with a uri based limiter is definitely needed.

Spring Web Flow seems more suitable for long flows. I think it is a little heavy for small dialogs and wizards. But wait, there is a lightweight alternative.

Why not to try a solution which uses only 3 tiny core classes and one one UI Manager class? No XML configuration files and parsing, no J2EE libraries to define and test the flow, can be reconfugured in runtime, no problems synchronizing wizard states with domain model state, no redundant state types, no Back button problem, already integrates with Struts and JSF.

Check out the live demo of Signup Wizard. Use Refresh, Back and Forward browser buttons to see that user experience is solid and robust.

Spring Web Flow seems more suitable for long flows. I think it is a little heavy for small dialogs and wizards. But wait, there is a lightweight alternative.Why not to try a solution which uses only 3 tiny core classes and one one UI Manager class? No XML configuration files and parsing, no J2EE libraries to define and test the flow, can be reconfugured in runtime, no problems synchronizing wizard states with domain model state, no redundant state types, no Back button problem, already integrates with Struts and JSF. Check out the live demo of Signup Wizard. Use Refresh, Back and Forward browser buttons to see that user experience is solid and robust.

Because it runs on top of struts ?

Because it runs on top of struts ?

Because what? It works with Struts and with JSF.

Craig,

I read your post with a certain eagerness and are looking
forward to a 'tighter' coupling of JSF into leading frameworks.

It'll be particularly interesting to see it placed within SWF and how much of the common areas, like validation,
will clash or be favoured on the JSF side. (+1)

We're looking at JSF integration within BeanPlanet; particularly integration with the JSF EL and validation.

Howard, we have encountered some performance issues with reflection-based EL ourselves. I've used OGNL quite
alot on my last couple of projects and also BeanShell. These are great tools for specific scripting jobs. With
OGNL though, unless you keep a reference to a parsed
expression, it'll keep parsing everytime before
it can execute -- potentially a very significant issue.

So far, we have overcome this problem in BeanPlanet (RC due
out late summer) by seperation of EL parser from
executer - gaining in performance and concurrency.

Good luck with V4 Howard!

Best,

Gary
________________________________________________________

Rather than monopolize this thread ... bring this up in the tapestry-dev or tapestry-user mailing lists. 4.0 uses OGNL more sparingly and efficiently.

Good point.

But it sounds like 4.0 has just scaled-down its use rather
than address the OGNL issue directly.

Taking it up in Tapestry Dev...

Craig McClanahan has announced a plan to integrate Spring Web Flow and JSF, with requirements and a possible approach, on the Spring framework developer mailing list. He goes into a lot of detail about existing technology (focusing on Shale), and then proposes using Spring Web Flow to manage dialogs.

The end result is an environment with some very important benefits resulting:* Outside of the dialogs world, standard JSF things work in the usual way.&nbsp;* Dialogs can reuse actions and view states (including those that are also accessed directly via standard JSF facilities), because the interpretation of the logical outcome is specialized per dialog.&nbsp;* As with SWF, the configuration of a dialog (or a flow) is very much amenable to tool-aided support like graphical drag-n-drop development of the overall flow -- as well as for more formal UML-based tool support.&nbsp;* Because of the other capabilities provided by Shale, an application will typically need fewer "setup" action states (because the prerender() method of a ViewController can take many of these responsibilities) and less work in what is typically a "bindAndValidate" action in Spring (because JSF has its own support for validation processing that preceeds such a state). But these are just icing on the cake -- the key values of having managed dialogs are independent of Shale.

Do you think this is a good approach? Does Spring Web Flow need Shale or JSF to fill certain needs, or vice versa, as Mr. McClanahan seems to see it?