The end result is an environment with some very important benefits resulting: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?
* 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.
-
A plan to integrate Spring Web Flow and JSF (69 messages)
- Posted by: Joseph Ottinger
- Posted on: May 03 2005 09:43 EDT
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.Threaded Messages (69)
- A plan to integrate Spring Web Flow and JSF by Edmon Begoli on May 03 2005 10:15 EDT
- Why not WebFlow + Tapestry by Vinicius Carvalho on May 03 2005 10:31 EDT
-
Why not WebFlow + Tapestry by Thad Smith on May 03 2005 11:41 EDT
-
That how the world dies !!! by Neeraj Kumar on May 04 2005 08:48 EDT
- That how the world dies !!! by Steve Zara on May 04 2005 10:32 EDT
-
That how the world dies !!! by Neeraj Kumar on May 04 2005 08:48 EDT
-
Why not WebFlow + Tapestry by Jacob Hookom on May 03 2005 11:41 EDT
-
Why not WebFlow + Tapestry by Konstantin Ignatyev on May 03 2005 12:17 EDT
-
Why not WebFlow + Tapestry by Jacob Hookom on May 03 2005 12:31 EDT
-
Why not WebFlow + Tapestry by Konstantin Ignatyev on May 03 2005 01:23 EDT
- Why not WebFlow + Tapestry by Jacob Hookom on May 03 2005 01:26 EDT
-
Why not WebFlow + Tapestry by Howard Lewis Ship on May 03 2005 02:05 EDT
- [OT] Why not WebFlow + Tapestry by Jacob Hookom on May 03 2005 03:57 EDT
-
Why not WebFlow + Tapestry by Konstantin Ignatyev on May 03 2005 01:23 EDT
- Why not WebFlow + Tapestry by Steve Zara on May 03 2005 12:33 EDT
-
Why not WebFlow + Tapestry by Jacob Hookom on May 03 2005 12:31 EDT
-
Why not WebFlow + Tapestry by Eelco Hillenius on May 03 2005 03:25 EDT
-
Why not WebFlow + Tapestry by Pavel Tavoda on May 04 2005 06:16 EDT
-
Why not WebFlow + Tapestry by Davide Baroncelli on May 04 2005 06:52 EDT
-
Why not WebFlow + Tapestry by Pavel Tavoda on May 04 2005 10:33 EDT
-
Why not WebFlow + Tapestry by Michael Jouravlev on May 04 2005 10:40 EDT
-
Why not WebFlow + Tapestry by Pavel Tavoda on May 04 2005 10:55 EDT
-
Why not WebFlow + Tapestry by Mark N on May 04 2005 03:28 EDT
- Why not WebFlow + Tapestry by Konstantin Ignatyev on May 04 2005 03:32 EDT
-
Why not WebFlow + Tapestry by Yan Hu on May 04 2005 06:45 EDT
- Why not WebFlow + Tapestry by Pavel Tavoda on May 05 2005 03:33 EDT
-
Why not WebFlow + Tapestry by Mark N on May 04 2005 03:28 EDT
-
Why not WebFlow + Tapestry by Pavel Tavoda on May 04 2005 10:55 EDT
-
Why not WebFlow + Tapestry by Michael Jouravlev on May 04 2005 10:40 EDT
-
Why not WebFlow + Tapestry by Pavel Tavoda on May 04 2005 10:33 EDT
- without starting a flame war... by Patria Lukman on May 04 2005 10:37 EDT
- without starting a flame war... by Patria Lukman on May 04 2005 10:39 EDT
-
Why not WebFlow + Tapestry by George Jiang on May 04 2005 07:40 EDT
-
Why not WebFlow + Tapestry by George Jiang on May 05 2005 07:10 EDT
-
Why not WebFlow + Tapestry by Steve Zara on May 05 2005 07:25 EDT
-
Why not WebFlow + Tapestry by Vagif Verdi on May 05 2005 02:24 EDT
-
Why not WebFlow + Tapestry by Steve Zara on May 05 2005 03:25 EDT
-
Why not WebFlow + Tapestry by Vagif Verdi on May 05 2005 04:19 EDT
-
Why not WebFlow + Tapestry by Steve Zara on May 05 2005 04:28 EDT
-
Why not WebFlow + Tapestry by Vagif Verdi on May 05 2005 04:39 EDT
-
Why not WebFlow + Tapestry by Steve Zara on May 05 2005 04:57 EDT
-
Why not WebFlow + Tapestry by Vagif Verdi on May 05 2005 06:19 EDT
-
Why not WebFlow + Tapestry by Steve Zara on May 05 2005 06:25 EDT
-
Why not WebFlow + Tapestry by Vagif Verdi on May 05 2005 06:30 EDT
-
Why not WebFlow + Tapestry by Jacob Hookom on May 05 2005 06:36 EDT
- Smart Client by George Jiang on May 05 2005 07:32 EDT
-
Back button is not a problem by Michael Jouravlev on May 05 2005 07:20 EDT
-
Back button is not a problem by Vagif Verdi on May 05 2005 08:13 EDT
- Back button is not a problem by Steve Zara on May 05 2005 08:28 EDT
-
Back button is not a problem by Michael Jouravlev on May 05 2005 08:36 EDT
-
Back button is not a problem by Vagif Verdi on May 05 2005 09:04 EDT
- Back button is not a problem by Michael Jouravlev on May 05 2005 09:41 EDT
-
Back button is not a problem by Vagif Verdi on May 05 2005 09:04 EDT
-
Back button is not a problem by Jacob Hookom on May 05 2005 11:21 EDT
-
Smart Client by George Jiang on May 06 2005 02:22 EDT
- Smart Client by George Jiang on May 06 2005 02:27 EDT
-
Back button is not a problem by Vagif Verdi on May 06 2005 02:37 EDT
- Rich Client vs. Web Client by Erwin Vervaet on May 06 2005 04:19 EDT
- Back button is not a problem by Steve Zara on May 06 2005 05:15 EDT
- Back button is not a problem by Mark N on May 06 2005 09:04 EDT
-
Smart Client by George Jiang on May 06 2005 02:22 EDT
-
Back button is not a problem by Henrique Steckelberg on May 06 2005 08:21 EDT
-
Write once and run on desktop and PDA ? by Vagif Verdi on May 06 2005 02:04 EDT
- Write once and run on desktop and PDA ? by Michael Jouravlev on May 06 2005 03:14 EDT
-
Write once and run on desktop and PDA ? by Jacob Hookom on May 06 2005 03:29 EDT
- Write once and run on desktop and PDA ? by Michael Jouravlev on May 06 2005 04:14 EDT
-
Write once and run on desktop and PDA ? by Vagif Verdi on May 06 2005 02:04 EDT
- Back button is not a problem by Mark N on May 06 2005 09:00 EDT
-
Back button is not a problem by George Jiang on May 07 2005 11:54 EDT
- Back button is not a problem by Steve Zara on May 07 2005 01:24 EDT
-
Back button is not a problem by Vagif Verdi on May 05 2005 08:13 EDT
- Why not WebFlow + Tapestry by Steve Zara on May 05 2005 07:24 EDT
-
Why not WebFlow + Tapestry by Jacob Hookom on May 05 2005 06:36 EDT
-
Why not WebFlow + Tapestry by Vagif Verdi on May 05 2005 06:30 EDT
-
Why not WebFlow + Tapestry by Steve Zara on May 05 2005 06:25 EDT
-
Why not WebFlow + Tapestry by Vagif Verdi on May 05 2005 06:19 EDT
-
Why not WebFlow + Tapestry by Steve Zara on May 05 2005 04:57 EDT
-
Why not WebFlow + Tapestry by Vagif Verdi on May 05 2005 04:39 EDT
-
Why not WebFlow + Tapestry by Steve Zara on May 05 2005 04:28 EDT
-
Why not WebFlow + Tapestry by Vagif Verdi on May 05 2005 04:19 EDT
-
Why not WebFlow + Tapestry by Steve Zara on May 05 2005 03:25 EDT
-
Why not WebFlow + Tapestry by Vagif Verdi on May 05 2005 02:24 EDT
-
Why not WebFlow + Tapestry by Steve Zara on May 05 2005 07:25 EDT
-
Why not WebFlow + Tapestry by George Jiang on May 05 2005 07:10 EDT
-
Why not WebFlow + Tapestry by Davide Baroncelli on May 04 2005 06:52 EDT
-
Why not WebFlow + Tapestry by Pavel Tavoda on May 04 2005 06:16 EDT
-
Why not WebFlow + Tapestry by Konstantin Ignatyev on May 03 2005 12:17 EDT
-
Why not WebFlow + Tapestry by Thad Smith on May 03 2005 11:41 EDT
- My thoughts by Werner Punz on May 14 2005 10:27 EDT
- Why not WebFlow + Tapestry by Vinicius Carvalho on May 03 2005 10:31 EDT
- A plan to integrate Spring Web Flow and JSF by Michael Jouravlev on May 03 2005 12:50 EDT
- A plan to integrate Spring Web Flow and JSF by sadfasdf asdadsf on May 04 2005 04:42 EDT
- A plan to integrate Spring Web Flow and JSF by Michael Jouravlev on May 04 2005 10:37 EDT
- A plan to integrate Spring Web Flow and JSF by sadfasdf asdadsf on May 04 2005 04:42 EDT
- Spring Web Flow and JSF and..Tapestry by Gary Watson on May 03 2005 14:58 EDT
- Spring Web Flow and JSF and..Tapestry by Howard Lewis Ship on May 03 2005 15:09 EDT
- Spring Web Flow and JSF and..Tapestry by Gary Watson on May 03 2005 03:12 EDT
- Spring Web Flow and JSF and..Tapestry by Howard Lewis Ship on May 03 2005 15:09 EDT
- A plan to integrate Spring Web Flow and JSF by sadfasdf asdadsf on May 04 2005 04:39 EDT
-
A plan to integrate Spring Web Flow and JSF[ Go to top ]
- Posted by: Edmon Begoli
- Posted on: May 03 2005 10:15 EDT
- in response to Joseph Ottinger
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. -
Why not WebFlow + Tapestry[ Go to top ]
- Posted by: Vinicius Carvalho
- Posted on: May 03 2005 10:31 EDT
- in response to Edmon Begoli
Well, since I belive tapestry is a much more well structured and mature project, why not this? Hasn't HLS ever think about it? -
Why not WebFlow + Tapestry[ Go to top ]
- Posted by: Thad Smith
- Posted on: May 03 2005 11:41 EDT
- in response to Vinicius Carvalho
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. -
That how the world dies !!![ Go to top ]
- Posted by: Neeraj Kumar
- Posted on: May 04 2005 08:48 EDT
- in response to Thad Smith
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 -
That how the world dies !!![ Go to top ]
- Posted by: Steve Zara
- Posted on: May 04 2005 10:32 EDT
- in response to Neeraj Kumar
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. -
Why not WebFlow + Tapestry[ Go to top ]
- Posted by: Jacob Hookom
- Posted on: May 03 2005 11:41 EDT
- in response to Vinicius Carvalho
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. -
Why not WebFlow + Tapestry[ Go to top ]
- Posted by: Konstantin Ignatyev
- Posted on: May 03 2005 12:17 EDT
- in response to Jacob Hookom
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. -
Why not WebFlow + Tapestry[ Go to top ]
- Posted by: Jacob Hookom
- Posted on: May 03 2005 12:31 EDT
- in response to Konstantin Ignatyev
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. -
Why not WebFlow + Tapestry[ Go to top ]
- Posted by: Konstantin Ignatyev
- Posted on: May 03 2005 13:23 EDT
- in response to Jacob Hookom
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 -
Why not WebFlow + Tapestry[ Go to top ]
- Posted by: Jacob Hookom
- Posted on: May 03 2005 13:26 EDT
- in response to Konstantin Ignatyev
...please lets not start that benchmark nonsense. You know better
Can't blame a guy for trying ;-) -
Why not WebFlow + Tapestry[ Go to top ]
- Posted by: Howard Lewis Ship
- Posted on: May 03 2005 14:05 EDT
- in response to Jacob Hookom
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. -
[OT] Why not WebFlow + Tapestry[ Go to top ]
- Posted by: Jacob Hookom
- Posted on: May 03 2005 15:57 EDT
- in response to Howard Lewis Ship
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) -
Why not WebFlow + Tapestry[ Go to top ]
- Posted by: Steve Zara
- Posted on: May 03 2005 12:33 EDT
- in response to Konstantin Ignatyev
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'. -
Why not WebFlow + Tapestry[ Go to top ]
- Posted by: Eelco Hillenius
- Posted on: May 03 2005 15:25 EDT
- in response to Jacob Hookom
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)... -
Why not WebFlow + Tapestry[ Go to top ]
- Posted by: Pavel Tavoda
- Posted on: May 04 2005 06:16 EDT
- in response to Eelco Hillenius
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? -
Why not WebFlow + Tapestry[ Go to top ]
- Posted by: Davide Baroncelli
- Posted on: May 04 2005 06:52 EDT
- in response to Pavel Tavoda
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. -
Why not WebFlow + Tapestry[ Go to top ]
- Posted by: Pavel Tavoda
- Posted on: May 04 2005 10:33 EDT
- in response to Davide Baroncelli
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. -
Why not WebFlow + Tapestry[ Go to top ]
- Posted by: Michael Jouravlev
- Posted on: May 04 2005 10:40 EDT
- in response to Pavel Tavoda
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. -
Why not WebFlow + Tapestry[ Go to top ]
- Posted by: Pavel Tavoda
- Posted on: May 04 2005 10:55 EDT
- in response to Michael Jouravlev
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? -
Why not WebFlow + Tapestry[ Go to top ]
- Posted by: Mark N
- Posted on: May 04 2005 15:28 EDT
- in response to Pavel Tavoda
Sorry Pavel but I am not sure whether to laugh or cry. :(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? -
Why not WebFlow + Tapestry[ Go to top ]
- Posted by: Konstantin Ignatyev
- Posted on: May 04 2005 15:32 EDT
- in response to Mark N
I suggest thinking :)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. :( -
Why not WebFlow + Tapestry[ Go to top ]
- Posted by: Yan Hu
- Posted on: May 04 2005 18:45 EDT
- in response to Pavel Tavoda
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? -
Why not WebFlow + Tapestry[ Go to top ]
- Posted by: Pavel Tavoda
- Posted on: May 05 2005 03:33 EDT
- in response to Yan Hu
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. -
without starting a flame war...[ Go to top ]
- Posted by: Patria Lukman
- Posted on: May 04 2005 10:37 EDT
- in response to Pavel Tavoda
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. -
without starting a flame war...[ Go to top ]
- Posted by: Patria Lukman
- Posted on: May 04 2005 10:39 EDT
- in response to Pavel Tavoda
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. -
Why not WebFlow + Tapestry[ Go to top ]
- Posted by: George Jiang
- Posted on: May 04 2005 19:40 EDT
- in response to Pavel Tavoda
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. -
Why not WebFlow + Tapestry[ Go to top ]
- Posted by: George Jiang
- Posted on: May 05 2005 07:10 EDT
- in response to George Jiang
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. -
Why not WebFlow + Tapestry[ Go to top ]
- Posted by: Steve Zara
- Posted on: May 05 2005 07:25 EDT
- in response to George Jiang
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. -
Why not WebFlow + Tapestry[ Go to top ]
- Posted by: Vagif Verdi
- Posted on: May 05 2005 14:24 EDT
- in response to Steve Zara
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. -
Why not WebFlow + Tapestry[ Go to top ]
- Posted by: Steve Zara
- Posted on: May 05 2005 15:25 EDT
- in response to Vagif Verdi
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. -
Why not WebFlow + Tapestry[ Go to top ]
- Posted by: Vagif Verdi
- Posted on: May 05 2005 16:19 EDT
- in response to Steve Zara
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. -
Why not WebFlow + Tapestry[ Go to top ]
- Posted by: Steve Zara
- Posted on: May 05 2005 16:28 EDT
- in response to Vagif Verdi
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). -
Why not WebFlow + Tapestry[ Go to top ]
- Posted by: Vagif Verdi
- Posted on: May 05 2005 16:39 EDT
- in response to Steve Zara
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. -
Why not WebFlow + Tapestry[ Go to top ]
- Posted by: Steve Zara
- Posted on: May 05 2005 16:57 EDT
- in response to Vagif Verdi
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. -
Why not WebFlow + Tapestry[ Go to top ]
- Posted by: Vagif Verdi
- Posted on: May 05 2005 18:19 EDT
- in response to Steve Zara
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 :) -
Why not WebFlow + Tapestry[ Go to top ]
- Posted by: Steve Zara
- Posted on: May 05 2005 18:25 EDT
- in response to Vagif Verdi
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. -
Why not WebFlow + Tapestry[ Go to top ]
- Posted by: Vagif Verdi
- Posted on: May 05 2005 18:30 EDT
- in response to Steve Zara
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 ? -
Why not WebFlow + Tapestry[ Go to top ]
- Posted by: Jacob Hookom
- Posted on: May 05 2005 18:36 EDT
- in response to Vagif Verdi
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[ Go to top ]
- Posted by: George Jiang
- Posted on: May 05 2005 19:32 EDT
- in response to Jacob Hookom
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. -
Back button is not a problem[ Go to top ]
- Posted by: Michael Jouravlev
- Posted on: May 05 2005 19:20 EDT
- in response to Vagif Verdi
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. -
Back button is not a problem[ Go to top ]
- Posted by: Vagif Verdi
- Posted on: May 05 2005 20:13 EDT
- in response to Michael Jouravlev
<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. -
Back button is not a problem[ Go to top ]
- Posted by: Steve Zara
- Posted on: May 05 2005 20:28 EDT
- in response to Vagif Verdi
<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. -
Back button is not a problem[ Go to top ]
- Posted by: Michael Jouravlev
- Posted on: May 05 2005 20:36 EDT
- in response to Vagif Verdi
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.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. -
Back button is not a problem[ Go to top ]
- Posted by: Vagif Verdi
- Posted on: May 05 2005 21:04 EDT
- in response to Michael Jouravlev
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 ? :)) -
Back button is not a problem[ Go to top ]
- Posted by: Michael Jouravlev
- Posted on: May 05 2005 21:41 EDT
- in response to Vagif Verdi
NeWS is not a dumb terminal. It is a smart 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 ? :)) -
Back button is not a problem[ Go to top ]
- Posted by: Jacob Hookom
- Posted on: May 05 2005 23:21 EDT
- in response to Vagif Verdi
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) -
Smart Client[ Go to top ]
- Posted by: George Jiang
- Posted on: May 06 2005 02:22 EDT
- in response to Jacob Hookom
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. -
Smart Client[ Go to top ]
- Posted by: George Jiang
- Posted on: May 06 2005 02:27 EDT
- in response to George Jiang
Let me repeat someone else's statement from a previous post. With browser client, you are treating your powerful PC as a dumb terminal!! -
Back button is not a problem[ Go to top ]
- Posted by: Vagif Verdi
- Posted on: May 06 2005 02:37 EDT
- in response to Jacob Hookom
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. -
Rich Client vs. Web Client[ Go to top ]
- Posted by: Erwin Vervaet
- Posted on: May 06 2005 04:19 EDT
- in response to Vagif Verdi
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 -
Back button is not a problem[ Go to top ]
- Posted by: Steve Zara
- Posted on: May 06 2005 05:15 EDT
- in response to Vagif Verdi
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. -
Back button is not a problem[ Go to top ]
- Posted by: Mark N
- Posted on: May 06 2005 09:04 EDT
- in response to Jacob Hookom
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? -
Back button is not a problem[ Go to top ]
- Posted by: Henrique Steckelberg
- Posted on: May 06 2005 08:21 EDT
- in response to Vagif Verdi
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 -
Write once and run on desktop and PDA ?[ Go to top ]
- Posted by: Vagif Verdi
- Posted on: May 06 2005 14:04 EDT
- in response to 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. -
Write once and run on desktop and PDA ?[ Go to top ]
- Posted by: Michael Jouravlev
- Posted on: May 06 2005 15:14 EDT
- in response to Vagif Verdi
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.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.
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. -
Write once and run on desktop and PDA ?[ Go to top ]
- Posted by: Jacob Hookom
- Posted on: May 06 2005 15:29 EDT
- in response to Vagif Verdi
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 -
Write once and run on desktop and PDA ?[ Go to top ]
- Posted by: Michael Jouravlev
- Posted on: May 06 2005 16:14 EDT
- in response to Jacob Hookom
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. -
Back button is not a problem[ Go to top ]
- Posted by: Mark N
- Posted on: May 06 2005 09:00 EDT
- in response to Vagif Verdi
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." -
Back button is not a problem[ Go to top ]
- Posted by: George Jiang
- Posted on: May 07 2005 11:54 EDT
- in response to Vagif Verdi
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. -
Back button is not a problem[ Go to top ]
- Posted by: Steve Zara
- Posted on: May 07 2005 13:24 EDT
- in response to George Jiang
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. -
Why not WebFlow + Tapestry[ Go to top ]
- Posted by: Steve Zara
- Posted on: May 05 2005 19:24 EDT
- in response to Vagif Verdi
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. -
My thoughts[ Go to top ]
- Posted by: Werner Punz
- Posted on: May 14 2005 10:27 EDT
- in response to Edmon Begoli
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. -
A plan to integrate Spring Web Flow and JSF[ Go to top ]
- Posted by: Michael Jouravlev
- Posted on: May 03 2005 12:50 EDT
- in response to Joseph Ottinger
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. -
A plan to integrate Spring Web Flow and JSF[ Go to top ]
- Posted by: sadfasdf asdadsf
- Posted on: May 04 2005 04:42 EDT
- in response to Michael Jouravlev
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 ? -
A plan to integrate Spring Web Flow and JSF[ Go to top ]
- Posted by: Michael Jouravlev
- Posted on: May 04 2005 10:37 EDT
- in response to sadfasdf asdadsf
Because it runs on top of struts ?
Because what? It works with Struts and with JSF. -
Spring Web Flow and JSF and..Tapestry[ Go to top ]
- Posted by: Gary Watson
- Posted on: May 03 2005 14:58 EDT
- in response to Joseph Ottinger
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
________________________________________________________ -
Spring Web Flow and JSF and..Tapestry[ Go to top ]
- Posted by: Howard Lewis Ship
- Posted on: May 03 2005 15:09 EDT
- in response to Gary Watson
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. -
Spring Web Flow and JSF and..Tapestry[ Go to top ]
- Posted by: Gary Watson
- Posted on: May 03 2005 15:12 EDT
- in response to Howard Lewis Ship
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... -
A plan to integrate Spring Web Flow and JSF[ Go to top ]
- Posted by: sadfasdf asdadsf
- Posted on: May 04 2005 04:39 EDT
- in response to Joseph Ottinger
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?