Tim Shadel says JSF isn't their choice for the future

Discussions

News: Tim Shadel says JSF isn't their choice for the future

  1. Tim Shadel, in a podcasted talk linked to from "JSF: The 7-Layer Burrito I Won't Eat Again," says that after using JavaServer Faces for months, they've decided that they wouldn't use JSF in the future. The primary reason? JSF uses POST, not GET, and as a result, links to specific aren't conversational state isn't preserved, unlike with REST.

    In the podcast, he says that the URL hiding affects JSF from start to finish. While he says JSF may be all right for applications that use internal state, it will be awful for applications that should expose content urls to, say, search engines – like blogs or other content applications. Further, the URL hiding affects deployment, because applications can't refer to other applications' states.

    The JavaServer Faces specification does indicate that POST is used exclusively; the form tag doesn't define a pass-through attribute for "method" to allow use of GET, and while it may be possible to create a render kit for JSF that enables use of alternate methods, this seems like a strange requirement for application developers. However, a quick search on Google does show a few examples of embedding data in a URL for use in JSF.

    Of further interest is the note that this is the "first of a long list of reasons why the JSF 7-layer burrito won't be on my round for seconds."

    What are your experiences and opinions about this? Is this a critical limitation of JSF? Would this affect your willingness to adopt JSF in public-facing applications? Why or why not?

    Threaded Messages (314)

  2. It's quite strange to say JSF isn't the choice for the future basing on past experience. I would say that JSF 1.1 isn't fully prepared and flexible enough for production, but we should wait for 1.2 and then make conclusions about the future. I believe JSF will evolve significally, the graphic tools for JSF will evolve too, it's powerful framework with great potential. Too early to throw JSF out.
  3. Lack of POST not a 'show stopper'[ Go to top ]

    I've never found the POST requirements to be a true limitation. You can always get to the core Servlet response/request stuff when you need it for legimate uses of URL parameters. I think that people who are stuck on the use of POST simply haven't crossed the bridge from the older web frameworks that are based heavily on response/request. You just need to re-think how you're trying to solve your problem.
  4. Lack of POST not a 'show stopper'[ Go to top ]

    I've never found the POST requirements to be a true limitation. You can always get to the core Servlet response/request stuff when you need it for legimate uses of URL parameters.

    I agree that this may not be a show stopper, but I think this kind of simple requirement SHOULD BE addressed by the framework. It is quite a simple and common requirement. Other framework address this nicely: For example in Tapestry it has ExternalPage for bookmark link, there are even option for you to design your own URL pattern (in T4) (very much like the apache mod_rewrite module).

    But of course, this is not the only reason why I don't use JSF, there are lots of little things here and there that just make people hard to develop, not make it easier.
  5. External page[ Go to top ]

    Actually having a difference between commandLink and ouputLink in jsf makes this difference as well.
    CommandLinks can be seen as internal links while outputlinks can be seen as external links which are bookmarkable.
    There are numerous issues like this why people dismiss jsf, although the things are usually there.
  6. Mr. Shadel[ Go to top ]

    Tim Shadel is a developer here in the Phoenix area.

    http://www.timshadel.com

    He podcasts his opinion semi-regularly on various dev related stuff.

    I worked with him in the recent past on the project of which JSF was being used. I have since moved on to greener pastures. :)
  7. Direction for Web Application[ Go to top ]

    Take a look at Microsoft world, you will find ASP.NET and JSF are the same technology which, I think, is the direction for the web application now and in the future.

    AjaxFaces: "General and Complete Integration Solution for JSF and Ajax"
  8. I hope Tim Shadel reads this thread before making his subsequent podcasts, since it was demonstrated clearly in this post that it's entirely possible to do GET parameters cleanly in JSF.
  9. The technical problems and dislikes that Tim Shadel describes about JSF are really just an example general problems with JSF. It seems everyone has issues with the technology.

    JSF has not got market traction (let alone critical mass) with the Java developer community.

    And THAT is the reason why it's not the choice for the future.




    PJ Murray

    CodeFutures Software

    Code Generation for Java Persistence
  10. It seems everyone has issues with the technology.
    JSF has not got market traction (let alone critical mass) with the Java developer community.

    These are strong statements. Have you evidence for them in terms of developer surveys or reports other than this one? Or are they just opinion?
  11. There are some definite (and fairly easy) ways to get around that limitation for sites that need to be Search Engine friendly.

    Having said that, those techniques should be formalized, and JSF does a poor job of supporting them out of the box.
  12. Waste of a Podcast...[ Go to top ]

    Ok, so I wrote before without listening to the whole thing... this was really quite boring.

    See also:
    http://www.jroller.com/page/jsight?entry=jsf_googlable_links_with_parameters

    Much easier than the crazy/hacked solution that they came up with.
  13. I am not about Tim's decision, but in general is it correct to compare JSF with REST? What does it mean component in REST?


    Marina
    http://www.servletsuite.com
  14. I am sorry[ Go to top ]

    but who is Tim Shadel? I tried to google him but not much came up. Any info will be appreciated.
  15. Matt Raible's JSF experience[ Go to top ]

    In Tim Shadel's post, he indirectly links to Matt Raible's JSF experience, in which Matt begins with:
    Of all the MVC Frameworks I've developed with in the last few weeks (Struts, Spring MVC, WebWork and Tapestry) - JSF was by far the worst. And it's *not* the implementations that are the problem, it's the spec itself (as far as I can tell). Plain and simple, it does not simplify web development.

    Tim also links to David Geary's response to Matt.

    Interesting stuff about JSF.. one thing's for sure it doesn't seem to be getting unanimity..

    Frederic
  16. We (major European manufacturing company) are currently finalizing very important application using JSF (MyFaces) and JBoss EJB3. And, once we learned it, it was real pleasure using JSF. Of course, there are some issues, i.e. detecting postbacks, but it was nothing compared to alternatives. Actually, most annoying thing was inability to use lazy relations transparently, but that was not an JSF issue but EJB3 issue. And there is Seam now.
    So, I believe that most of the negative comments from community are coming just because of the inertia. People approach it with arrogance (oh, I know this, must be like .NET/Struts/<arbitrary_web_framework>) without trying to really understand/learn how this stuff works. And then, they are frustrated that their natural intelligence can not compensate for the lack of information. On the end, it is much easier to say that something sucks than to admit that you were too lazy to go through documentation/samples.
  17. We (major European manufacturing company) are currently finalizing very important application using JSF (MyFaces) and JBoss EJB3. And, once we learned it, it was real pleasure using JSF. Of course, there are some issues, i.e. detecting postbacks, but it was nothing compared to alternatives. Actually, most annoying thing was inability to use lazy relations transparently, but that was not an JSF issue but EJB3 issue. And there is Seam now.So, I believe that most of the negative comments from community are coming just because of the inertia. People approach it with arrogance (oh, I know this, must be like .NET/Struts/<arbitrary_web_framework>) without trying to really understand/learn how this stuff works. And then, they are frustrated that their natural intelligence can not compensate for the lack of information. On the end, it is much easier to say that something sucks than to admit that you were too lazy to go through documentation/samples.

    I keep seeing people flaming JSF maybe because it is supported by a standard who knows. But I rarely technical or design arguments justifying their opinion, seems more like a philosophical issue. A lot of FUD is spread around JSF right now. I have used it for some times now and I must say I like it. There are some issues but overall I enjoys developping it espcially compare to Struts.
  18. I keep seeing people flaming JSF maybe because it is supported by a standard who knows. But I rarely technical or design arguments justifying their opinion, seems more like a philosophical issue. A lot of FUD is spread around JSF right now. I have used it for some times now and I must say I like it. There are some issues but overall I enjoys developping it espcially compare to Struts.

    I absolutely agree - I think you have got things exactly right. My view is that there is much vocal resistance to JSF simply because it is a JSR specification, and there is a philosphical resistance to 'imposed' standards.
  19. I keep seeing people flaming JSF maybe because it is supported by a standard who knows. But I rarely technical or design arguments justifying their opinion, seems more like a philosophical issue. A lot of FUD is spread around JSF right now. I have used it for some times now and I must say I like it. There are some issues but overall I enjoys developping it espcially compare to Struts.
    I absolutely agree - I think you have got things exactly right. My view is that there is much vocal resistance to JSF simply because it is a JSR specification, and there is a philosphical resistance to 'imposed' standards.
    Yes, I expect more from standards. JSF looks like experiment made in lab. Archtecture is very cool( managed beans,navigation, events) but there is no motivation to make it standard.
  20. I absolutely agree - I think you have got things exactly right. My view is that there is much vocal resistance to JSF simply because it is a JSR specification, and there is a philosphical resistance to 'imposed' standards.

    Steve, here's how "a lot of people" [1] see it:

    1. Someone [2] goes off an writes Struts, which is an abomination, but for some odd reason (kind of like MS DOS 3 beating MacOS in the market) lots of people end up using it, and most end up loathing it.

    2. The same someone who wrote Struts feels like his/her technology was validated, based solely on the large number of poor souls stuck using it.

    3. Unfortunately, the same someone who wrote Struts doesn't realize that Struts is a complete horror that makes Java look bad. Instead, he/she decides to build a bigger abomination, with roughly the same amount of input from people actually building web applications (read: zero).

    4. Sun decides, after most of the damage was already done and baked in to "JSF", to make it a JSR.

    So basically, this "large vocal group of people" recognizes someone who should not have been allowed near a keyboard in the first place, someone who they believe foisted a strutting abomination on a large number of unsuspecting and well-intentioned developers (who have all subsequently committed suicide or at least suffered from carpal tunnel syndrome), and realize that -- instead of putting said person in jail -- Sun endorses and standardizes his/her Frankensteinian 2.0 effort.

    [1] completely unsupported assertion; see here for explanation

    [2] names withheld to protect the guitly

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  21. +1

    I think this is exactly how "a lot of people" who have been burned by Struts feel.

    -Tim Fennell
    Stripes: Because web development should just be easier.
  22. +1 I think this is exactly how "a lot of people" who have been burned by Struts feel.-Tim FennellStripes: Because web development should just be easier.

    +1
    Whish I could write like that! Two things though. I'm still missing why JSP *had* to be part of JSF (something to do with SUN perhaps, or is it because of the number of people that were crazy about JSP?). And I think that while JSF could and should have been much better, it is still an improvement over Struts.
  23. Two things though. I'm still missing why JSP *had* to be part of JSF (something to do with SUN perhaps, or is it because of the number of people that were crazy about JSP?).

    It isn't part of JSF. The reference implementation (and all implementations that I know of) come with JSP versions of the rendering technology, but that is simply for convenience - JSP was a well-established way of producing web pages.
    And I think that while JSF could and should have been much better, it is still an improvement over Struts.

    It certainly is if you like component-based design.
  24. Plain JSP tags are components too, JSF duplicates this standard if JSF is an attempt to define component model for web pages.
     Probably JSF is a cool framework, but I think it is yet another web framework and it solves no problems (read uselesss) as standard.
  25. Plain JSP tags are components too, JSF duplicates this standard if JSF is an attempt to define component model for web pages.&nbsp;Probably JSF is a cool framework, but I think it is yet another web framework and it solves no problems (read uselesss) as standard.

    LOL, you don't have a clue.

    Near everyone assume that when we talk about components that they are *just* for rendering. Rendering is only one aspect of what components can do in the mvc lifecycle. Every framework on the earth has the same 5 phases: decode, validate, update, invoke, and encode (render). JSF and other component frameworks allow delegation of these concerns to these stateful, re-usable objects. With JSP, you can create a tag (not a component) that renders complex form input. As a JSF component, that entity could now actually carry validation logic, update/invoke methods on beans back at the server, etc.
  26. LOL,
    JSF is just a custom JSP tag library.
    http://java.sun.com/j2ee/javaserverfaces/overview.html
  27. LOL,JSF is just a custom JSP tag library. http://java.sun.com/j2ee/javaserverfaces/overview.html

    You should read what you quote.

    "JSF technology includes:
    [...].
    A JavaServer Pages (JSP) custom tag library."

    "includes" != "is just a"

    And, if you read on:

    "Designed to be flexible, JavaServer Faces technology leverages existing, standard UI and web-tier concepts without limiting developers to a particular mark-up language, protocol, or client device. The UI component classes included with JavaServer Faces technology encapsulate the component functionality, not the client-specific presentation, thus enabling JavaServer Faces UI components to be rendered to various client devices."

    To illustrate this, you may want to have a look at xulfaces - an implementation which uses XUL and AJAX rather than JSP.
  28. "Designed to be flexible, JavaServer Faces technology leverages existing, standard UI and web-tier concepts without limiting developers to a particular mark-up language, protocol, or client device. The UI component classes included with JavaServer Faces technology encapsulate the component functionality, not the client-specific presentation, thus enabling JavaServer Faces UI components to be rendered to various client devices."
    Yes, Servlets and JSP tags is a standard way to solve this problem (There is a standard JSP tag libray too). I see nothing wrong in JSF tag library, but JSF motivation is not clear for me: http://www.jcp.org/en/jsr/detail?id=252, I do not see problems to solve for new specifiation.
  29. Yes, Servlets and JSP tags is a standard way to solve this problem (There is a standard JSP tag libray too). I see nothing wrong in JSF tag library, but JSF motivation is not clear for me:

    I think the motivations were:

    1. Make something component-based, that could compete with ASP.NET and that could allow a market for components to develop.

    2. Make something that can work in visual design tools to ease development for those who want to work this way.

    3. Make something that is not restricted to JSP/HTML, so that it can handle future technologies for client-side presentation, or even simultaneous handle multiple current technologies.

    3. Make something that is very easy to extend. (This has led to projects like Shale and Seam, and JSF-Spring).
  30. I think the motivations were:1. Make something component-based, that could compete with ASP.NET and that could allow a market for components to develop.2. Make something that can work in visual design tools to ease development for those who want to work this way.3. Make something that is not restricted to JSP/HTML, so that it can handle future technologies for client-side presentation, or even simultaneous handle multiple current technologies.3. Make something that is very easy to extend. (This has led to projects like Shale and Seam, and JSF-Spring).

    Funny that none of these is "Make development easier for developers" or "Make testing and TDD easier". Lots of stuff for tool vendors and component vendors, nothing for developers.
  31. I think the motivations were:1. Make something component-based, that could compete with ASP.NET and that could allow a market for components to develop.2. Make something that can work in visual design tools to ease development for those who want to work this way.3. Make something that is not restricted to JSP/HTML, so that it can handle future technologies for client-side presentation, or even simultaneous handle multiple current technologies.3. Make something that is very easy to extend. (This has led to projects like Shale and Seam, and JSF-Spring).
    Funny that none of these is "Make development easier for developers" or "Make testing and TDD easier". Lots of stuff for tool vendors and component vendors, nothing for developers.


    The visual design tools are (of course) for developers.

    The protection of code so that it can work with future client-side technologies is for developers.

    The ability to handle multiple client-side technologies is for developers.

    About the only thing I have listed that is 'for vendors' (to use the term loosely) is the ability to extend JSF.

    So, sorry, but I just don't get the 'nothing for developers' argument.
  32. I think the motivations were:1. Make something component-based, that could compete with ASP.NET and that could allow a market for components to develop.2. Make something that can work in visual design tools to ease development for those who want to work this way.3. Make something that is not restricted to JSP/HTML, so that it can handle future technologies for client-side presentation, or even simultaneous handle multiple current technologies.3. Make something that is very easy to extend. (This has led to projects like Shale and Seam, and JSF-Spring).
    Funny that none of these is "Make development easier for developers" or "Make testing and TDD easier". Lots of stuff for tool vendors and component vendors, nothing for developers.

    Inherently, JSF benefits developers in two ways:

    1) there's [near] total separation between your object model and the UI. Not like some other frameworks where you have to extend a series of objects. This lends it self to easy unit testing since your objects have zero dependencies on the framework.

    2) Component based development benefits development tremendously as re-usable tools. There's a lot of frameworks carrying that spirit.
  33. Funny that none of these is "Make development easier for developers" or "Make testing and TDD easier". Lots of stuff for tool vendors and component vendors, nothing for developers.

    Jason, I encourage you to check out the new demo apps in Seam beta 2 when it is released this week and look at just how simple JSF can be, both to code and to test.

    I have heard all kinds of claims that JSF is complex, mostly from people with competing web frameworks, and I have to say that this simply does not match up with my own experience. Yes, there is more to learn in JSF than in Struts - just like there is more to learn in Hibernate or EJB3 than in EJB2. This is be because JSF/EJB3 do a lot more stuff than Struts/EJB2. But this does not translate into more complexity at the code level. In fact, the way I write JSF applications, they are a lot simpler than their Struts counterparts.

    When I was looking around for a web framework to marry to EJB3, I went in with the expectation that JSF was going to be a total steaming pile, totally on the basis of the blog/tss commentary I had been exposed to. But nevertheless, I thought I needed to learn it and make my own decision on the matter. When I actually sat down and did that, I was totally surprised. Not only did JSF do a lot of things in the way I had always wished Struts or WebWork would have done them, but a lot of the criticisms I had read of JSF - just like the one which sparked this thread - turned out to be just plain incorrect.

    Sure, there were some rough edges in JSF (I hate the XML, for example) but I was totally sold when I realized that just about every "piece" of JSF is pluggable. So I was -easily- able to replace those bits I hated or thought were insufficient:

    * XML -> Seam annotations
    * JSP -> Facelets
    * navigation rules -> navigation rules OR jBPM pageflow

    I'm not trying to say that there are *no* problems with JSF. (For example, I imagine most everyone here will happily accept that futzing with TLDs is a horrible way to extend the widgetry.) But I'm yet to meet any web framework which is without flaw. Don't try to tell me that there is nothing to criticise in WebWork or Tapestry.

    What I do believe is that the Java community would be incredibly well served if they migrated en masse away from Struts and on to JSF. This would massively improve the quality of a *lot* of Java code, and help Java continue to succeed as a platform for web development. This outpouring of hate against JSF for what are IMO relatively minor imperfections is helping keep people using a > 5 years old framework full of at-the-time-relatively-innovative-but-now-totally-outdated ideas.

    Would it also be good if everyone migrated en masse to to Tapestry? Certainly. Do I see this happening? Not really. Should the Java community be stuck on Struts-style coarse-grained action frameworks forever because of this? Hell no!

    Anyway, I'm seeing a lot of growth in JSF usage, and it appears to be finally taking off, which is great. Clearly, inclusion of JSF as a required piece of Java EE 5 will give it another big boost.
  34. totally[ Go to top ]

    When I was looking around for a web framework to marry to EJB3, I went in with the expectation that JSF was going to be a total steaming pile, totally on the basis of the blog/tss commentary I had been exposed to. But nevertheless, I thought I needed to learn it and make my own decision on the matter. When I actually sat down and did that, I was totally surprised.

    And I was like - totally - like .. that was totally three "totally"s in a row!
  35. Should the Java community be stuck on Struts-style coarse-grained action frameworks forever because of this?
    It looks action frameworks are not so bad.
  36. Should the Java community be stuck on Struts-style coarse-grained action frameworks forever because of this?
    It looks action frameworks are not so bad.

    Unfortunately pure action frameworks are dreadful, face it you cannot go without a component based approach in the immediate future, things are moving away from the broken html 4.01 protocol (broken in a way that you cannot do real applications with it without a serious fix from the framework side)

    pure action like protocols died out around 1980 and due to a pure joke in computing they were revived because some browser vendors refused to go with newer versions of the www protocol which was inherently broken for dynamic user interfaces.
  37. Actions / commands are very natural and simple way to handle HTTP request and to process transactions, probably there is something wrong in "JSF component based approach" if it doe's not work with old plain actions, HTTP and HTML.
  38. Actions / commands are very natural and simple way to handle HTTP request and to process transactions, probably there is something wrong in "JSF component based approach" if it doe's not work with old plain actions, HTTP and HTML.

    You can work with actions, nothing in JSF prevents that, it is just that a pure action based approach is contrary to an event system which is needed for complex user interface systems.
    The problem is more that html is inherently broken for classical user interface stuff, than JSF is broken because it adds an event system (for dealing with user interfaces the usual way) to an action system which still is in there.
  39. Actions / commands are very natural and simple way to handle HTTP request and to process transactions, probably there is something wrong in "JSF component based approach" if it doe's not work with old plain actions, HTTP and HTML.
    You can work with actions, nothing in JSF prevents that, it is just that a pure action based approach is contrary to an event system which is needed for complex user interface systems.The problem is more that html is inherently broken for classical user interface stuff, than JSF is broken because it adds an event system (for dealing with user interfaces the usual way) to an action system which still is in there.

    To give further explanation, an action basically is just one type of event, and the user himself has to deal with what happens at exactly this event. User interface systems usually have more than one type of event, you usually have resizing events, action events (which is similar to an action), events which are triggered at value changes etc...
    Having only one type of event is inherently problematic because you have to deal yourself with different types of events in a non standardized way.
    (Those events always happen)
  40. Probably it is usual way for VB developers, but it is very unusual for web developers and I do not think it is a good idea to sell it as "standard approach".
  41. Probably it is usual way for VB developers, but it is very unusual for web developers and I do not think it is a good idea to sell it as "standard approach".

    Actually, web development is the only thing where a pure action approach is chosen, and that is only because the wheel of time was rolled back 20 years at least with the start of having to build applications and complex user interfaces on top of the web.
    But things are moving swiftly into saner directions on the web as well. As we speak event based systems are basically hammered into browsers left and right. Even Microsoft basically moves into that direction with Xaml, face it, pure action based systems will die out within a five years timeframe, like they died out on rich client user interfaces (events are way older than VB, they root back into the Xerox Parc GUI and basically still are state of the art in every non html ui system) around 1980!
  42. Unfortunately pure action frameworks are dreadful, face it you cannot go without a component based approach in the immediate future, things are moving away from the broken html 4.01 protocol (broken in a way that you cannot do real applications with it without a serious fix from the framework side)
    Can you elaborate please, what is a "pure action framework", what is a "component based approach", why components cannot be applied to action frameworks and how exactly HTML 4.01 is broken? Links will suffice.
    an action basically is just one type of event
    Does your version of HTTP not support query parameters?

    ---
    Michael Jouravlev
    JSP Controls: Create page components with JSP
  43. Unfortunately pure action frameworks are dreadful, face it you cannot go without a component based approach in the immediate future, things are moving away from the broken html 4.01 protocol (broken in a way that you cannot do real applications with it without a serious fix from the framework side)
    Can you elaborate please, what is a "pure action framework", what is a "component based approach", why components cannot be applied to action frameworks and how exactly HTML 4.01 is broken? Links will suffice.
    an action basically is just one type of event
    Does your version of HTTP not support query parameters?---Michael JouravlevJSP Controls: Create page components with JSP

    http://weblogs.java.net/blog/jhook/archive/2006/01/experiment_goin_1.html
  44. Probably it is usual way for VB developers, but it is very unusual for web developers and I do not think it is a good idea to sell it as "standard approach".
    Actually, web development is the only thing where a pure action approach is chosen, and that is only because the wheel of time was rolled back 20 years at least with the start of having to build applications and complex user interfaces on top of the web.But things are moving swiftly into saner directions on the web as well. As we speak event based systems are basically hammered into browsers left and right. Even Microsoft basically moves into that direction with Xaml, face it, pure action based systems will die out within a five years timeframe, like they died out on rich client user interfaces (events are way older than VB, they root back into the Xerox Parc GUI and basically still are state of the art in every non html ui system) around 1980!

    Or maybe it's just because THAT'S THE WAY HTTP WORKS? I agree that component based UI kits are the way to go for desktop apps... Where communication between components is direct and in-memory, but across HTTP, a stateless text-based protocol to a remote server? Doesn't sound like a good fit to me.
  45. Or maybe it's just because THAT'S THE WAY HTTP WORKS? I agree that component based UI kits are the way to go for desktop apps... Where communication between components is direct and in-memory, but across HTTP, a stateless text-based protocol to a remote server? Doesn't sound like a good fit to me.

    Well, X has worked fine across a stateless protocol to a remote server for some time now.
  46. Or maybe it's just because THAT'S THE WAY HTTP WORKS? I agree that component based UI kits are the way to go for desktop apps... Where communication between components is direct and in-memory, but across HTTP, a stateless text-based protocol to a remote server? Doesn't sound like a good fit to me.
    Well, X has worked fine across a stateless protocol to a remote server for some time now.

    Is it binary, or text-based? Is it usually used to serve across continental boundaries? And to say X windows has "worked" is being kind... ;-)
  47. Is it binary, or text-based?

    Binary. Rather like much http content.
    Is it usually used to serve across continental boundaries?

    I often use it across far further than that... across geostationary satellite link. Painful, but possible (far slower than most websites).
    And to say X windows has "worked" is being kind... ;-)

    I think the millions of users of X on Linux right now might disagree.
  48. Or maybe it's just because THAT'S THE WAY HTTP WORKS? I agree that component based UI kits are the way to go for desktop apps... Where communication between components is direct and in-memory, but across HTTP, a stateless text-based protocol to a remote server? Doesn't sound like a good fit to me.
    Well, X has worked fine across a stateless protocol to a remote server for some time now.

    X only works because the server keeps the entire state and only sends the primitives and the events are sent back to the client.
    Sort of like a webapp with a session at the backend storing all the data and receving javascripted events which can trigger drawing updates (sounds like a very fine grained ajax, with everything kept in a single session)

    X has another set of problems however, it is too fine grained. X ran into severe network scaling problems a while ago, due to the fact that the drawing primitives were too fine grained for modern uis, several projects try to bypass that huge limitation by pushing a macro protocol or different other techniques on top of it.
    (Nomachine NX being one of the most interesting in
    this area)
     
    Also if people are here concerned about the impacts of state saving onto the server, then they probably would get the shudders in X ;-), due to the application running on the server basically entirely.
  49. Probably it is usual way for VB developers, but it is very unusual for web developers and I do not think it is a good idea to sell it as "standard approach".
    Actually, web development is the only thing where a pure action approach is chosen, and that is only because the wheel of time was rolled back 20 years at least with the start of having to build applications and complex user interfaces on top of the web.But things are moving swiftly into saner directions on the web as well. As we speak event based systems are basically hammered into browsers left and right. Even Microsoft basically moves into that direction with Xaml, face it, pure action based systems will die out within a five years timeframe, like they died out on rich client user interfaces (events are way older than VB, they root back into the Xerox Parc GUI and basically still are state of the art in every non html ui system) around 1980!
    Or maybe it's just because THAT'S THE WAY HTTP WORKS? I agree that component based UI kits are the way to go for desktop apps... Where communication between components is direct and in-memory, but across HTTP, a stateless text-based protocol to a remote server? Doesn't sound like a good fit to me.

    Ok here we are at a common ground, I do thing as well that HTTP is not really that suited for complex user interfaces. But the problem is, and we are all caught in this trap. That customers nowadays exactly demand complex user interfaces within the boundaries of HTTP.

    I will give you an example. The last smaller app I had to write had at 50% of the applicaiton due to customer demand a dynamic form which had to alter its visible state upon user input, but not that you could redirect to something different all this had to happen within the same form boundaries. Add to that that basic reporting also had to be added, dynamic error handling etc. and you see what we all have to face every day.

    Struts and pure action based frameworks do not cut it in those kind of applications, where you often have to deal with dyanmic trees, tabbing, tables, etc...
    You need something more dynamic. One answere after I gave him an example of such an app, that he did it with JSP or whatever adding ajax to the mix. Yes that works, but the problem is, you have to do the work yourself, or you run into a huge mess by combining different dynamic mechanisms.
    This poor guy probably wrot his own table, went for his own ajax bindings and as soon as he meshes the whole mix with another set of foreign controls he runs into myriads of problems or interferes with another event system.
    He also said he did not need events, while he basically wrote his own ajaxed event system for that (triggering state change events for ui alteration)

    I am not saying that JSF is the best you can get for such things, JSF definitely has some problems in the Ajax arena, (which are adressable and addressed by many extensions), but it is a good way to get this stuff without having to constantly reinventing the wheel is rather pointless.
    I am not saying JSF is state of the art in many things, probably other frameworks are, but it is a good common ground of proven concepts and extensibility which has integrated the works of many which have been proven worthwhile, while others explore new grounds (namely Tapestry currently)

    I would love to dump HTTP entirely except for maybe entire form changes and data callbacks, but as long as we are stuck with http and requirements of applications where http simply is not suitable to we are also stuck with frameworks which try to bypass those limitations, and pure action approaches do not cover enough ground for applications which in fact need component approaches and event systems.
    (X only works stateless because it pushes the burden of all the state handling onto the server and even the whole rendering, of the primitives, while http tries to push the rendering onto the client and forgoes the state handling entirely)
  50. I wish I knew what you were smoking... I'd see if I could get some myself.

    Struts 1.0 apps (not even 1.1, etc) won't even die out in 5 years, much less newer stuff.

    All of the rich web apps that you guys keep citing were not written in JSF, or even component based web frameworks. Google sparked the AJAX craze with their webapps... They use a custom framework for that stuff (not component based from what I've gathered), but a lot of their stuff is moving to WebWork. Just because you couldn't figure out how to do it doesn't mean it's not doable.

    You should at least look at what WebWork does before you say what we JUST SHIPPED IN 2.2 IS NOT DOABLE. We have a rich set of Ajax components which do in-page eventing and pub / sub using Dojo. It doesn't require a component tree deserialization and complex lifecycle to make powerful dynamic web pages. We've got this stuff pre-built, and using a much simpler request / response action paradigm, rather than the complex component lifecycle required by JSF.

    Make web pages which alter themselves based on session state, rather than the other way around, it just makes more sense.
    Probably it is usual way for VB developers, but it is very unusual for web developers and I do not think it is a good idea to sell it as "standard approach".
    Actually, web development is the only thing where a pure action approach is chosen, and that is only because the wheel of time was rolled back 20 years at least with the start of having to build applications and complex user interfaces on top of the web.But things are moving swiftly into saner directions on the web as well. As we speak event based systems are basically hammered into browsers left and right. Even Microsoft basically moves into that direction with Xaml, face it, pure action based systems will die out within a five years timeframe, like they died out on rich client user interfaces (events are way older than VB, they root back into the Xerox Parc GUI and basically still are state of the art in every non html ui system) around 1980!
    Or maybe it's just because THAT'S THE WAY HTTP WORKS? I agree that component based UI kits are the way to go for desktop apps... Where communication between components is direct and in-memory, but across HTTP, a stateless text-based protocol to a remote server? Doesn't sound like a good fit to me.
    Ok here we are at a common ground, I do thing as well that HTTP is not really that suited for complex user interfaces. But the problem is, and we are all caught in this trap. That customers nowadays exactly demand complex user interfaces within the boundaries of HTTP.I will give you an example. The last smaller app I had to write had at 50% of the applicaiton due to customer demand a dynamic form which had to alter its visible state upon user input, but not that you could redirect to something different all this had to happen within the same form boundaries. Add to that that basic reporting also had to be added, dynamic error handling etc. and you see what we all have to face every day.Struts and pure action based frameworks do not cut it in those kind of applications, where you often have to deal with dyanmic trees, tabbing, tables, etc...You need something more dynamic. One answere after I gave him an example of such an app, that he did it with JSP or whatever adding ajax to the mix. Yes that works, but the problem is, you have to do the work yourself, or you run into a huge mess by combining different dynamic mechanisms.This poor guy probably wrot his own table, went for his own ajax bindings and as soon as he meshes the whole mix with another set of foreign controls he runs into myriads of problems or interferes with another event system.He also said he did not need events, while he basically wrote his own ajaxed event system for that (triggering state change events for ui alteration)I am not saying that JSF is the best you can get for such things, JSF definitely has some problems in the Ajax arena, (which are adressable and addressed by many extensions), but it is a good way to get this stuff without having to constantly reinventing the wheel is rather pointless.I am not saying JSF is state of the art in many things, probably other frameworks are, but it is a good common ground of proven concepts and extensibility which has integrated the works of many which have been proven worthwhile, while others explore new grounds (namely Tapestry currently)I would love to dump HTTP entirely except for maybe entire form changes and data callbacks, but as long as we are stuck with http and requirements of applications where http simply is not suitable to we are also stuck with frameworks which try to bypass those limitations, and pure action approaches do not cover enough ground for applications which in fact need component approaches and event systems.(X only works stateless because it pushes the burden of all the state handling onto the server and even the whole rendering, of the primitives, while http tries to push the rendering onto the client and forgoes the state handling entirely)
  51. All of the rich web apps that you guys keep citing were not written in JSF, or even component based web frameworks. Google sparked the AJAX craze with their webapps... They use a custom framework for that stuff (not component based from what I've gathered)

    Your point was, I assumed, that highly interactive GUIs would not work over the web, because of response times. You can label bits of Javascript code that respond to UI events and change areas of a page through communication with a server what you like. I call them 'components'.
    We have a rich set of Ajax components which do in-page eventing

    And so, it seems, do you.
    It doesn't require a component tree deserialization and complex lifecycle to make powerful dynamic web pages. We've got this stuff pre-built, and using a much simpler request / response action paradigm, rather than the complex component lifecycle required by JSF.

    Excuse me while put my "web developer" hat on...

    What complex component lifecycle? I don't see any lifecycle: all I see are components I place on a page and events I can handle from those components.

    OK, I am taking it off now...

    Of course there is a complex component lifecycle. But so what? Most web developers need not see it or care about it. I I know Studio Creator users who sit at the screen and wire up code and probably have no idea that all this lifecycle exists. Of course if you are a JSF component writer, you need to know about all this. Also, the complex lifecycle allows features of JSF that some of us rather like - such as the ability to use components with different presentation technologies.
  52. All of the rich web apps that you guys keep citing were not written in JSF, or even component based web frameworks. Google sparked the AJAX craze with their webapps... They use a custom framework for that stuff (not component based from what I've gathered)
    Your point was, I assumed, that highly interactive GUIs would not work over the web, because of response times. You can label bits of Javascript code that respond to UI events and change areas of a page through communication with a server what you like. I call them 'components'.
    We have a rich set of Ajax components which do in-page eventing
    And so, it seems, do you.

    My point is that it's silly to make web pages use a paradigm of development that doesn't fit the medium for 95% of the pages in an application just to try to cover the complexity of the other 5%, especially when you can just as easily support that 5% with a framework that fits HTML over HTTP much better. Also that writing UI components doesn't have to be SO HARD and make you know SO MUCH about what's going on. The extra stuff JSF does isn't needed to get reusability in web applications, so why take it all on?
    It doesn't require a component tree deserialization and complex lifecycle to make powerful dynamic web pages. We've got this stuff pre-built, and using a much simpler request / response action paradigm, rather than the complex component lifecycle required by JSF.
    Excuse me while put my "web developer" hat on...What complex component lifecycle? I don't see any lifecycle: all I see are components I place on a page and events I can handle from those components.OK, I am taking it off now...Of course there is a complex component lifecycle. But so what? Most web developers need not see it or care about it. I I know Studio Creator users who sit at the screen and wire up code and probably have no idea that all this lifecycle exists. Of course if you are a JSF component writer, you need to know about all this.

    Yeah... abstractions never leak and you never have to know what's going on under the covers... Riiiight... Read the next post on Tim's blog where he talks about all of the leaks in the JSF abstractions.
    Also, the complex lifecycle allows features of JSF that some of us rather like - such as the ability to use components with different presentation technologies.

    Oh, yes, none of the rest of us could possibly do that. You do realize that WebWork has been doing that for like 4 years, right? And that adding a new template for a UI component in WebWork is just whipping up a template, not having to create a new class and do lots of out.println() like in a JSF Renderkit, right?
  53. My point is that it's silly to make web pages use a paradigm of development that doesn't fit the medium for 95% of the pages in an application just to try to cover the complexity of the other 5%, especially when you can just as easily support that 5% with a framework that fits HTML over HTTP much better.

    I think this is simply a matter of opinion. I find the way JSF works a paradigm of development that I really like. I honestly don't think that the fit with HTML over HTTP is that important. Much useful progress in IT has come from fitting new paradigms that are easier for the developer and user over old ones, even if that fit is not as elegant as it might be.
    Also that writing UI components doesn't have to be SO HARD and make you know SO MUCH about what's going on.

    I certainly agree it could and should be made easier.
    The extra stuff JSF does isn't needed to get reusability in web applications, so why take it all on?

    Because it is for more than just reusability - it is for features like renderkits, use in visual tools etc.
    It doesn't require a component tree deserialization and complex lifecycle to make powerful dynamic web pages. We've got this stuff pre-built, and using a much simpler request / response action paradigm, rather than the complex component lifecycle required by JSF.

    I agree it doesn't require all this. But JSF is about more than just dynamic web pages. It is a general server-side remote GUI system with all sorts of plug-in points for extensions and all features.
    Yeah... abstractions never leak and you never have to know what's going on under the covers...
    Riiiight... Read the next post on Tim's blog where he talks about all of the leaks in the JSF abstractions.

    I did not say that abstractions never leak. I said that for the majority of use, I simply don't believe they do for JSF. I will look at the blog with interest, but you are, I think, discussing problems that don't exist for the majority of developers.
    Oh, yes, none of the rest of us could possibly do that.

    I did not say that.
    You do realize that WebWork has been doing that for like 4 years, right?

    Show me visual design tools for WebWork (I don't like such tools, but co-workers do), multi-vendor support for components, the ability of components to detect different client types at render time. If I am mistaken and WebWork can do this, I would be interested.
    And that adding a new template for a UI component in WebWork is just whipping up a template, not having to create a new class and do lots of out.println() like in a JSF Renderkit, right?

    Sounds great, and I'm sure you have done a good job. JSF has flaws. But it suits me and the way I want to develop.

    I feel we have probably come to an impasse - as you are seeing problems where I don't, and I see features where you see irrelevancies!
  54. I honestly don't think that the fit with HTML over HTTP is that important.
    So, JSF is simply not for the web development? :-)
    Show me ... the ability of components to detect different client types at render time.

    again, you are pointing here to the trivial things and declare them as a first time achievement. The _ability_ to detect is trivial. It is just a header in HTTP request (user agent or supported mime types). It is how the development for the mobile world works in years already.

    ASP.NET (as it is only one vendor behind it) maintains a huge database for devices. In other words the framework (if ASP.NET is a framework) can tune the generated code according that database. And the value of "client type detection" is in this database. It is not so easy to collect, maintain etc. Where the _ability_ to detect itself is nothing. It is just a header in HTTP request. Any request from the mobile for example will be at the end of the deal just a normal HTTP request from the gateway on the mobile operator side. Request's header will tell you who is asking. That is how the Google mobile works etc.

    Dmitry
    Coldbeans
  55. I honestly don't think that the fit with HTML over HTTP is that important.
    So, JSF is simply not for the web development? :-)

    No. My point was that the way the developer can use a framework need not necessarily reflect the underlying mechanisms of transport. We use abstractions.
    Show me ... the ability of components to detect different client types at render time.
    again, you are pointing here to the trivial things and declare them as a first time achievement.

    I never said they were done first in JSF.
    The _ability_ to detect is trivial...It is just a header in HTTP request. Any request from the mobile for example will be at the end of the deal just a normal HTTP request from the gateway on the mobile operator side. Request's header will tell you who is asking.

    Great. So it is trival. So let's see it in more web frameworks.
  56. "Action paradigm" has nothing to do with transport, Struts users do not need to parse HTTP, web server doe's it. This is dictated by concurrent transactions and scalability requarements, Struts style programming solves this problem. "Stateful event model" is fine for single user and single threaded applications ( I used to be ActiveX developer myself and I like events too), but I am not sure it works for server applications and as I understand from this discussion JSF paradigm is not better than Struts or WW.
  57. And that adding a new template for a UI component in WebWork is just whipping up a template, not having to create a new class and do lots of out.println() like in a JSF Renderkit, right?

    That is one way to do it, Facelets provides a much easier way. (People who are checking out JSF should definitely look at Facelets, Jacob Hookum et al. has done a great job to mitigate some of the sour tastes people have with JSP/Renderkits).

    As far as WebWork simplicity, can you give us an example? Seems to me, the template still has to be wired via xml which seems to be one of the complaints of JSF and Struts.

    JSF has warts without a doubt, but the vitriole going on in this thread is baffling to the point of a British soccer match. No one is going to budge from the home team.

    The WebWorkers for years have been trashing Struts and now low and behold, Struts is a happy word since the groups have merged.

    I guess JSF is going to be the new poster child for Web Framework rants.

    JSF is trying, and admittedly their PR is bad, to go to an event driven type of display tree processing. Since everyone ripped off MVC from Smalltalk, the analogy I guess would be JSF <=> Morphic. I don't see how a graceful solution can work though.

    I think alot of people are bitching about frameworks here when the real culprit is the horrendous HTTP protocol which forces all frameworks(in every language) to do gymnastics to maintain dialog state machines.
  58. As far as WebWork simplicity, can you give us an example? Seems to me, the template still has to be wired via xml which seems to be one of the complaints of JSF and Struts.

    You're thinking of a different type of template. I'm talking about our UI component templates, which are found from the classpath based on a package structure like this:

    /template/themeName/templateName

    the templates can be in FreeMarker (templateName.ftl), Velocity (templateName.vm), or JSP (templateName.jsp). You can look at our distribution for what the templates look like... It's pretty easy to just copy one and make your own version.
    JSF has warts without a doubt, but the vitriole going on in this thread is baffling to the point of a British soccer match. No one is going to budge from the home team.The WebWorkers for years have been trashing Struts and now low and behold, Struts is a happy word since the groups have merged.

    Well, don't let the lack of trashing fool you :-) I'm still not a fan of Struts Classic, but I have a feeling Struts 2 is going to be better...
    I guess JSF is going to be the new poster child for Web Framework rants.JSF is trying, and admittedly their PR is bad, to go to an event driven type of display tree processing. Since everyone ripped off MVC from Smalltalk, the analogy I guess would be JSF <=> Morphic. I don't see how a graceful solution can work though.I think alot of people are bitching about frameworks here when the real culprit is the horrendous HTTP protocol which forces all frameworks(in every language) to do gymnastics to maintain dialog state machines.

    The problem is that it's been christened by Sun as a standard, and many of us feel that it's sub-standard. See also: JSP. See also: Entity EJB's {@spec < 3.0}.

    HTTP isn't ideal, but it's good enough if you accept that it's a stateless request / response paradigm. In many ways it's like JMS (forget the transactional bits). Unfortunately, some abstractions only work based on certain assumptions. My assertion is that the assumptions required for stateful event-driven user interface component frameworks are not met by HTTP.
  59. The problem is that it's been christened by Sun as a standard, and many of us feel that it's sub-standard. See also: JSP. See also: Entity EJB's {@spec < 3.0}.

    I agree with you here. But I've always treated standards(ie. 'Corporate Standards') as CYA auditing artifices.("Gee, I know my project failed, but we used all industry standards. Please don't fire me"). :)

    HTTP isn't ideal, but it's good enough if you accept that it's a stateless request / response paradigm. In many ways it's like JMS (forget the transactional bits). Unfortunately, some abstractions only work based on certain assumptions. My assertion is that the assumptions required for stateful event-driven user interface component frameworks are not met by HTTP.

    Http is still synchronous by nature, which is where the limitations lie. Frameworks need to inject all these state transition controls at the edge to provide reasonable usage patterns(At least for next-gen development). I wish it were more like JMS which I think would address the stateful event-driven problems you mention. I think this is why AJAX is becoming more and more visible, even though IMO it's a kludge.

    If the goal of these new frameworks is for "Web 2.0" or whatever the hell the buzzword is, maybe it's also time for a refactor/extension of infrastructure protocols too.

    HTTP-NG addressed these concerns, in theory, but unfortunately petered out for some reason.

    http://www.w3.org/Protocols/HTTP-NG/1998/08/draft-frystyk-httpng-arch-00.txt

    If you read the introduction, they specifically address the majority of gripes people have mentioned on this thread. Anyone know why it was scrapped?
  60. maybe it's also time for a refactor/extension of infrastructure protocols too.
    The workaround for Back button and now can be very simple: if response contains "this is a webapp" header, then browser should not accumulate URLs in a history list; Back button should transfer to the last page that was visited outside webapp domain. This will allow to focus on current app state and don't bother with state rollback/roll forward.

    ---
    Michael Jouravlev
    JSP Controls: Create page components with JSP
  61. HTTP-NG addressed these concerns, in theory, but unfortunately petered out for some reason.http://www.w3.org/Protocols/HTTP-NG/1998/08/draft-frystyk-httpng-arch-00.txtIf you read the introduction, they specifically address the majority of gripes people have mentioned on this thread. Anyone know why it was scrapped?
    It looks like an incomplete RPC framework, probably it was replaced by web services.
  62. It doesn't require a component tree deserialization and complex lifecycle to make powerful dynamic web pages. We've got this stuff pre-built, and using a much simpler request / response action paradigm, rather than the complex component lifecycle required by JSF.

    Right, because the component (well, non-JSF component) itself is not tied with the serialization/de-serialization by the default.

    Dmitry
    http://www.servletsuite.com
  63. Probably it is usual way for VB developers, but it is very unusual for web developers and I do not think it is a good idea to sell it as "standard approach".

    It will become the standard approach whether we like it or not. As for 'very unusual' - well, it is not the most common way to develop web pages right now, but I don't think you would call use of highly interactive technologies like AJAX unusual.
  64. I do not think standard framework can ignore developers and "best practices". Probably it will become the standard approach. It fine for Source Forge project, but I think it is too experimental for standard at this time.
  65. I do not think standard framework can ignore developers and "best practices". Probably it will become the standard approach.

    You seem to not want to listen to the point of view that many developers like component-based systems.

    If you did some research into user interface design, I think you would disover that component-based user interface design is best practice - it provides immediate, context-based interaction and feedback to the user. This has been the way quality user interfaces have been designed for decades. The current way that web interfaces work is far from best practice.
    It fine for Source Forge project, but I think it is too experimental for standard at this time.

    It is not experimental. Component-based web frameworks like Tapestry have been around for years, and are well established. I also don't think that many SourceForge developers would appreciate your association of "experimental" with their work. Many well-established high-quality projects are hosted there.
  66. I do not think standard framework can ignore developers and "best practices". Probably it will become the standard approach.
    You seem to not want to listen to the point of view that many developers like component-based systems. If you did some research into user interface design, I think you would disover that component-based user interface design is best practice - it provides immediate, context-based interaction and feedback to the user. This has been the way quality user interfaces have been designed for decades. The current way that web interfaces work is far from best practice.
    It fine for Source Forge project, but I think it is too experimental for standard at this time.
    It is not experimental. Component-based web frameworks like Tapestry have been around for years, and are well established. I also don't think that many SourceForge developers would appreciate your association of "experimental" with their work. Many well-established high-quality projects are hosted there.

    I hope I do not get this wrong, but the first serious web framework of all WebObjects by apple followed the component based approach instantly, from the beginning, it was just struts that did not follow this approach for some kind of reason. Even Turbine which is equally old as Struts did componentization to a certain degree via velocity.
    But that is not the point componentization if done right comes hand in hand with a good event system, and basically every user interface approach outside of the html space (and and other stone old terminal approaches like vt220) follow this design. It has been a best practice since the Xerox Sparc GUI and still is, which is a proof about the viability of this design. While pure action based rerender approaches on application scope died out outside of html around 20 years ago, when the last terminal based line based protocols became extinct.
  67. You seem to not want to listen to the point of view that many developers like component-based systems.

    Many developers like the idea of ODBMS too, but it doesn't make it a good solution for the enterprise.
    If you did some research into user interface design, I think you would disover that component-based user interface design is best practice - it provides immediate, context-based interaction and feedback to the user.

    In paradigms where the system can provide IMMEDIATE response to the user, then yes, a component based UI is a good idea. HTML across HTTP isn't such a case.
  68. In paradigms where the system can provide IMMEDIATE response to the user, then yes, a component based UI is a good idea. HTML across HTTP isn't such a case.
    With components you can direct request to a particular component instead of handling it in the main page action. Also, Ajax can provide immediate response, updating a single (or several) components on a page. Or did you have something different in mind?

    ---
    Michael Jouravlev
    JSP Controls: Create page components with JSP
  69. With components you can direct request to a particular component instead of handling it in the main page action. Also, Ajax can provide immediate response, updating a single (or several) components on a page. Or did you have something different in mind?---Michael JouravlevJSP Controls: Create page components with JSP

    Depends on your definition of "immediate" and, as we've seen, the Renderkit bound nature of JSF components has made AJAX support needlessly complicated.
  70. With components you can direct request to a particular component instead of handling it in the main page action. Also, Ajax can provide immediate response, updating a single (or several) components on a page. Or did you have something different in mind?---Michael JouravlevJSP Controls: Create page components with JSP
    Depends on your definition of "immediate" and, as we've seen, the Renderkit bound nature of JSF components has made AJAX support needlessly complicated.

    Not really, the Avatar concept I brought up on Java.net basically removes all need for any component to even worrry about AJAX. Also there's no need to break up your pages just to do partial-refreshes of content-- leaving a single document quite dynamic.
  71. You seem to not want to listen to the point of view that many developers like component-based systems.
    Many developers like the idea of ODBMS too, but it doesn't make it a good solution for the enterprise.

    Component-based systems have proved successful for enterprise GUs for ... some time now.

    (If you look around you will see that some enterprises run very well using ODBMSes - but that is another topic).
    If you did some research into user interface design, I think you would disover that component-based user interface design is best practice - it provides immediate, context-based interaction and feedback to the user.
    In paradigms where the system can provide IMMEDIATE response to the user, then yes, a component based UI is a good idea. HTML across HTTP isn't such a case.

    The huge success of apps such as Google Maps and GMail seems to indicate otherwise, I would suggest.

    Immediate response has never been a requirement of user interfaces, as anyone who used a Mac or Windows PC in the mid 80s will probably agree.
  72. The huge success of apps such as Google Maps and GMail seems to indicate otherwise, I would suggest.Immediate response has never been a requirement of user interfaces, as anyone who used a Mac or Windows PC in the mid 80s will probably agree.

    Funny you should mention 2 Google web apps... ;-)
  73. Actions / commands are very natural and simple way to handle HTTP request and to process transactions, probably there is something wrong in "JSF component based approach" if it doe's not work with old plain actions, HTTP and HTML.
    You can work with actions, nothing in JSF prevents that, it is just that a pure action based approach is contrary to an event system which is needed for complex user interface systems.The problem is more that html is inherently broken for classical user interface stuff, than JSF is broken because it adds an event system (for dealing with user interfaces the usual way) to an action system which still is in there.

    No, it is NOT needed. See all web apps written with Struts and WebWork as counter examples. Puhleaze.
  74. Actions / commands are very natural and simple way to handle HTTP request and to process transactions, probably there is something wrong in "JSF component based approach" if it doe's not work with old plain actions, HTTP and HTML.
    You can work with actions, nothing in JSF prevents that, it is just that a pure action based approach is contrary to an event system which is needed for complex user interface systems.The problem is more that html is inherently broken for classical user interface stuff, than JSF is broken because it adds an event system (for dealing with user interfaces the usual way) to an action system which still is in there.
    No, it is NOT needed. See all web apps written with Struts and WebWork as counter examples. Puhleaze.

    I'm still using Struts, and I can say that an event system would make it a bit cleaner. Perhaps this is the result of my Windows GUI days. :-)

    We've "faked" this by using the Struts LookupDispathcherAction derived class to give us a rough approximation of an event with callbacks.

    It works well and is reasonably easy. For example, If you have an "Add" button on the screen, the method that is automatically called is "executeAddLogic".
  75. You can work with actions, nothing in JSF prevents that, it is just that a pure action based approach is contrary to an event system which is needed for complex user interface systems.The problem is more that html is inherently broken for classical user interface stuff, than JSF is broken because it adds an event system (for dealing with user interfaces the usual way) to an action system which still is in there.
    No, it is NOT needed. See all web apps written with Struts and WebWork as counter examples. Puhleaze.
    I'm still using Struts, and I can say that an event system would make it a bit cleaner. Perhaps this is the result of my Windows GUI days. :-) We've "faked" this by using the Struts LookupDispathcherAction derived class to give us a rough approximation of an event with callbacks. It works well and is reasonably easy. For example, If you have an "Add" button on the screen, the method that is automatically called is "executeAddLogic".

    Seems that dispatch action gains popularity, at last. The truth is that you don't need Struts or other framework to process events, pure JSP is more than enough, for example:

    <code>
    <span id="LoginComponent">
      <jc:accept>
        <jc:handler event="login"> ... </jc:handler>
        <jc:handler event="logout"> ... </jc:handler>
      </jc:accept>
      <jc:render view="notloggedin"> ... </jc:render>
      <jc:render view="loggedin"> ... </jc:render>
    </span>
    </code>

    If all you need is to process events and to render component according to its state, JSP can do it with ease. Framework is optional.

    ---
    Michael Jouravlev
    JSP Controls: Create page components with JSP
  76. You can work with actions, nothing in JSF prevents that, it is just that a pure action based approach is contrary to an event system which is needed for complex user interface systems.The problem is more that html is inherently broken for classical user interface stuff, than JSF is broken because it adds an event system (for dealing with user interfaces the usual way) to an action system which still is in there.
    No, it is NOT needed. See all web apps written with Struts and WebWork as counter examples. Puhleaze.
    I'm still using Struts, and I can say that an event system would make it a bit cleaner. Perhaps this is the result of my Windows GUI days. :-) We've "faked" this by using the Struts LookupDispathcherAction derived class to give us a rough approximation of an event with callbacks. It works well and is reasonably easy. For example, If you have an "Add" button on the screen, the method that is automatically called is "executeAddLogic".
    Seems that dispatch action gains popularity, at last. The truth is that you don't need Struts or other framework to process events, pure JSP is more than enough, for example:<code><span id="LoginComponent">&nbsp;&nbsp;<jc:accept>&nbsp;&nbsp;&nbsp;&nbsp;<jc:handler event="login"> ... </jc:handler>&nbsp;&nbsp;&nbsp;&nbsp;<jc:handler event="logout"> ... </jc:handler>&nbsp;&nbsp;</jc:accept>&nbsp;&nbsp;<jc:render view="notloggedin"> ... </jc:render>&nbsp;&nbsp;<jc:render view="loggedin"> ... </jc:render></span></code>If all you need is to process events and to render component according to its state, JSP can do it with ease. Framework is optional.---Michael JouravlevJSP Controls: Create page components with JSP


    Of course JSP is enough, the problems start to arise once you have to combine multiple taglibs each using their own event mechanism for bypassing the one action limitation. Each using their own mechanism for backend interference etc...

    JSP more or less is a view tech only with everything else controllerwise not being very thoroughly standardized. And that is the main problem with JSP taglibs, they are fine as long as you do not start to combine some of them which use
    more sophisticated methods of communication.
  77. problems start to arise once you have to combine multiple taglibs each using their own event mechanism for bypassing the one action limitation. Each using their own mechanism for backend interference etc...JSP more or less is a

    And what do you mean under events for taglibs?
    1) many taglibs could be used for the rendering only. So there are no events.
    2) State saving could be optional for the taglibs too. That is one of my problems in JSF – how to discard (avoid) that for the certain components? Wrap them with verbatim tag? But what for? If you are declaring components in JSF why the JSP (of JSF) compiler could not detect what is it: JSF (what is a custom tag) or JSP (what is just another custom tag)

    3) Many taglibs are using JavaScript chunks. So events are being isolated inside of components.

    4) I am talking now about HTTP based stuff (so it is HTML, WAP/WML etc.) Regardless of the technology (framework) the final action is anyway HTTP request. Some of the taglibs need to raise a new request (e.g. submit a form etc.) It was simply to proceed in Struts because Struts is actually processing raw HTTP requests. JSF hides raw HTTP. So (again from my opinion) it adds complexity to my development. If forces me to stay entirely in JSF. Of I need some of the tricks to interact with JSF tree from non-JSF chunks. For example, Ajax integration for JSF looks very unnatural, because Ajax request is simply raw HTTP GET (or POST), what is not welcome in the framework.

    The components (and taglibs too) should be irrelevant to the backend and rely only on the stuff that exists 100% in your environment. For web it is HTTP. So the component should post/get to the backend and rest of the deal is up to the framework.

    I agreed that components based approach if a good movement. But there are several things regarding JSF:
    - JSF is not only existed components (despite the bad taste proclamation from JSF evangelists :-)
    - JSF is trying to combine two opposite things: components (they are distributed) and MVC (what is centralized). I could not buy the external navigation in XML file at all. Why do we need that?

    Dmitry
    http://www.servletsuite.com
  78. You can work with actions, nothing in JSF prevents that, it is just that a pure action based approach is contrary to an event system which is needed for complex user interface systems.The problem is more that html is inherently broken for classical user interface stuff, than JSF is broken because it adds an event system (for dealing with user interfaces the usual way) to an action system which still is in there.
    No, it is NOT needed. See all web apps written with Struts and WebWork as counter examples. Puhleaze.
    I'm still using Struts, and I can say that an event system would make it a bit cleaner. Perhaps this is the result of my Windows GUI days. :-) We've "faked" this by using the Struts LookupDispathcherAction derived class to give us a rough approximation of an event with callbacks. It works well and is reasonably easy. For example, If you have an "Add" button on the screen, the method that is automatically called is "executeAddLogic".
    Seems that dispatch action gains popularity, at last. The truth is that you don't need Struts or other framework to process events, pure JSP is more than enough, for example:<code><span id="LoginComponent">&nbsp;&nbsp;<jc:accept>&nbsp;&nbsp;&nbsp;&nbsp;<jc:handler event="login"> ... </jc:handler>&nbsp;&nbsp;&nbsp;&nbsp;<jc:handler event="logout"> ... </jc:handler>&nbsp;&nbsp;</jc:accept>&nbsp;&nbsp;<jc:render view="notloggedin"> ... </jc:render>&nbsp;&nbsp;<jc:render view="loggedin"> ... </jc:render></span></code>If all you need is to process events and to render component according to its state, JSP can do it with ease. Framework is optional.---Michael JouravlevJSP Controls: Create page components with JSP

    Well, I've glossed over a few other things, so I'm confident that pure JSP is not enough. Also, the Struts Dispatcher has been there for some time, so I don't think that it is "at last".

    My issue with what you've written is that it is just too far from html for, IMO, to be well receieved. I prefer to have my Struts "back-end" code handle the details and get the page as HTML-like as possible. Plus, I have more confidence in the extensibilty of a framework than some, forgive me, thrown together JSP approach.

    I think that frameworks provide value, like consistency of approach, for example, that raw JSP cannot match.
  79. Well, I've glossed over a few other things, so I'm confident that pure JSP is not enough. Also, the Struts Dispatcher has been there for some time, so I don't think that it is "at last".
    It has been there, but even many seasoned Struts users do not see benefits of DispatchAction-style input processing. DispatchAction is still not a "best practice" for Struts.
    My issue with what you've written is that it is just too far from html for, IMO, to be well receieved. I prefer to have my Struts "back-end" code handle the details and get the page as HTML-like as possible.
    You mean, a whole page? If you use any kind of components, that would be impossible since each component usually generates its own markup (JSF) or has its own template file (Tapestry). If you program your output in terms of full page rendering + full page preview, then you do not need my library or any other component library/framework ;-)
    Plus, I have more confidence in the extensibilty of a framework than some, forgive me, thrown together JSP approach.
    You have more confidence in the extensibilty of a framework that was thrown together six years ago by one person during Memorial Day weekend vacation trip "in between watching the surf and having the house shaken by a windstorm at night", I see ;-)
    I think that frameworks provide value, like consistency of approach, for example, that raw JSP cannot match.
    Facts:
    * Struts cannot render independent page components. Heck, standard Struts has no notion of components.
    * My library can render portlet-like components, but does not have data converters or validators or backing beans.
    * My library is the refactoring of a quite successful Struts Dialogs project, and as such, fully support Struts for input processing.

    The code snippet that I have shown several posts above, can be rewritten as:


    <span id="LoginComponent">
      <jc:accept>
        <jc:handler event="login">
          <jsp:include page="/login.do" />
        </jc:handler>
        <jc:handler event="logout">
          <jsp:include page="/logout.do" />
        </jc:handler>
      </jc:accept>
      <jc:render view="notloggedin"> ... </jc:render>
      <jc:render view="loggedin"> ... </jc:render>
    </span>


    or even as:


    <span id="LoginComponent">
      <jc:accept>
        <jsp:include page="/loginDispatch.do" />
      </jc:accept>
      <jc:render view="notloggedin"> ... </jc:render>
      <jc:render view="loggedin"> ... </jc:render>
    </span>


    where loginDispatch.do is a flavor of dispatch action that handles input events and updates component state.

    My "thrown together JSP approach" marries action-centric idea of Struts with page-centric fashion of JSF and with "view helper" technique of some other frameworks like Stripes for example. It may be a little early for earning confidence, but it sure has something to bring to Struts/JSP table ;-)

    ---
    Michael Jouravlev
    JSP Controls: Create page components with JSP
  80. Well, I've glossed over a few other things, so I'm confident that pure JSP is not enough. Also, the Struts Dispatcher has been there for some time, so I don't think that it is "at last".
    It has been there, but even many seasoned Struts users do not see benefits of DispatchAction-style input processing. DispatchAction is still not a "best practice" for Struts.
    My issue with what you've written is that it is just too far from html for, IMO, to be well receieved. I prefer to have my Struts "back-end" code handle the details and get the page as HTML-like as possible.
    You mean, a whole page? If you use any kind of components, that would be impossible since each component usually generates its own markup (JSF) or has its own template file (Tapestry). If you program your output in terms of full page rendering + full page preview, then you do not need my library or any other component library/framework ;-)
    Plus, I have more confidence in the extensibilty of a framework than some, forgive me, thrown together JSP approach.
    You have more confidence in the extensibilty of a framework that was thrown together six years ago by one person during Memorial Day weekend vacation trip "in between watching the surf and having the house shaken by a windstorm at night", I see ;-)
    I think that frameworks provide value, like consistency of approach, for example, that raw JSP cannot match.
    Facts:* Struts cannot render independent page components. Heck, standard Struts has no notion of components.* My library can render portlet-like components, but does not have data converters or validators or backing beans.* My library is the refactoring of a quite successful Struts Dialogs project, and as such, fully support Struts for input processing.The code snippet that I have shown several posts above, can be rewritten as:<span id="LoginComponent">&nbsp;&nbsp;<jc:accept>&nbsp;&nbsp;&nbsp;&nbsp;<jc:handler event="login">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<jsp:include page="/login.do" />&nbsp;&nbsp;&nbsp;&nbsp;</jc:handler>&nbsp;&nbsp;&nbsp;&nbsp;<jc:handler event="logout">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<jsp:include page="/logout.do" />&nbsp;&nbsp;&nbsp;&nbsp;</jc:handler>&nbsp;&nbsp;</jc:accept>&nbsp;&nbsp;<jc:render view="notloggedin"> ... </jc:render>&nbsp;&nbsp;<jc:render view="loggedin"> ... </jc:render></span>or even as:<span id="LoginComponent">&nbsp;&nbsp;<jc:accept>&nbsp;&nbsp;&nbsp;&nbsp;<jsp:include page="/loginDispatch.do" />&nbsp;&nbsp;</jc:accept>&nbsp;&nbsp;<jc:render view="notloggedin"> ... </jc:render>&nbsp;&nbsp;<jc:render view="loggedin"> ... </jc:render></span>where loginDispatch.do is a flavor of dispatch action that handles input events and updates component state.My "thrown together JSP approach" marries action-centric idea of Struts with page-centric fashion of JSF and with "view helper" technique of some other frameworks like Stripes for example. It may be a little early for earning confidence, but it sure has something to bring to Struts/JSP table ;-)---Michael JouravlevJSP Controls: Create page components with JSP

    First, when I said thrown-together JSP, that was refering to anything you've written. I was refering to the habit of most of the JSP developers that I've interacted with to just...well..throw together JSP.

    We could certainly benefit from a component approach, but your tags just look strange to me. No doubt caused by my unfamilarity with them.

    Now, when I said confidence in extensibility this is in an (implied) will thought out framework than in something that this just put together. Struts is not the pinnacle of web frameworks by any stretch, but it bought needed standards to the arena. Also, it is easy, in 20/20 to condemn it, but no one else has come close to doing what it did as well as it did it, a perfect storm of conditions if you will.

    I've said before that I'm looking forward to move our SSH(Struts, Spring, Hibernate) stack to the next level by moving us to a different presentation tier. Our framework has been designed and maintained with that in mind, but I have just don't think Struts is as bad as what is stated. While it is on the decline, I'd rather look at it as a good employee that served me well, and should be given an honourable retirement.

    The Dispatcher stuff, IMO, works better than Struts out of the box, but can and has only carried us so far, so I'm more than willing to entertain all options.

    I've been looking at Tapestry, JSF, and now the Struts/shale/webwork stuff, Ajax,lazlo to try to get a handle on our next generation presentation tier.

    Perhaps all of the above has markup similar to yours. If so, I'll adapt,but I'm looking for something that sticks as closely to HTML as possible, can possibly leverage some similar struts characteritstics(without the form/action) baggage, integrates with Spring, brings some interesting client side refreshing to the table(while still allowing me to do the things I want to do like validation on the server), is fun to use, and makes good business sense.

    This is not an assault on your technology. :-)
  81. First, when I said thrown-together JSP, that was refering to anything you've written. I was refering to the habit of most of the JSP developers that I've interacted with to just...well..throw together JSP.

    Argh!! That should b "wasn't refering"!

    When the hell is TSS going to let us edit??!!!?
  82. First, when I said thrown-together JSP, that was refering to anything you've written. I was refering to the habit of most of the JSP developers that I've interacted with to just...well..throw together JSP.
    Argh!! That should b "wasn't refering"!When the hell is TSS going to let us edit??!!!?

    ARRGGGHHHH!!! That should be "be", not "b".

    I've had enough.
  83. Actions / commands are very natural and simple way to handle HTTP request and to process transactions, probably there is something wrong in "JSF component based approach" if it doe's not work with old plain actions, HTTP and HTML.

    They may feel natural for you, but not for me and many others. It is good to have choice.

    As for transactions, it may be easier to handle them in an action-based approach, but user interface design should not be about what is easier for the developer - it should be about what is easier for the user. Component-based user interface systems that handle transactions have been around for decades. This approach may raise issues, but those issues are well understood, and developers have been dealing successfully with them for a long time.
  84. Should the Java community be stuck on Struts-style coarse-grained action frameworks forever because of this?
    It looks action frameworks are not so bad.
    Unfortunately pure action frameworks are dreadful, face it you cannot go without a component based approach in the immediate future, things are moving away from the broken html 4.01 protocol (broken in a way that you cannot do real applications with it without a serious fix from the framework side)pure action like protocols died out around 1980 and due to a pure joke in computing they were revived because some browser vendors refused to go with newer versions of the www protocol which was inherently broken for dynamic user interfaces.

    Give me a break. Talk to me when you have a real reference customer. This is just stupid arrogance, and not even vaguely technically reasonable. Google uses WebWork. Atlassian uses WebWork (ever used Jira? Confluence?) Who uses MyFaces in production? How many companies use Struts? How many tool vendors support Struts (here's a hint, it's more than JSF).
  85. Who uses MyFaces in production? How many companies use Struts?

    Well, I do for one.
    How many tool vendors support Struts (here's a hint, it's more than JSF).

    Yes, it is amazing how a framework that has been out for years longer has more tool support.... Or perhaps it isn't that surprising.

    Anyway, tool support for JSF is actually rather good. There is Studio Creator, JDeveloper, JBuilder, Exadel, MyEclipse, BEA Workshop for JSF, WebSphere Studio, NitroX Studio, Faces IDE, Rational Application Developer...

    As Struts has been out for four and a half years (since the release of 1.0), and JSF for just over a year and a half, this list of tools suggest (to me, anyway) that it is doing rather well.
  86. Who uses MyFaces in production? How many companies use Struts?
    Well, I do for one.

    No offense, but, so what? On what?
  87. It is great that Seam would help out with using JSF. The approaches you outlined would be excellent. It seems to me that when JSF first came out, its creators concentrated on the theoretical aspects of the framework, rather than its practical use. As if they did not have the time (or did not care) to observe how it would be used by real developers of average skill. As a result, the framework was certainly usable by experts, but in the general case you would very often get podcasts like the one that started this discussion, or many, many articles that express horrible experiences or confusion. What bugs me here is that many people prefer to insult Tim Shadel's intelligence, rather than ask themselves what can be done to make JSF more intuitive and simpler.

    In contrast, Tapestry has tried to accommodate the ease-of-use aspects and this is considered to be very important. The guiding principle there has always been "The easy way should be right way". If a particular feature is seen as confusing or complicated by the users, a serious consideration of alternative and simpler approaches is performed.

    Facelets (and Seam, based on what you've written) finally seem to walk those all important last 20% of the road. Hopefully they would not take too long and would fix important things like making the creation of components natural.

    Unfortunately, as I pointed in my posts above, the theory behind JSF is also rather impractical in important aspects. For example, the exclusively dynamic approach for building the component tree means that the developer would need to make one of the following choices:
    1) Store the component trees in the session, making the session rather large, which strains the memory resources and is dreadful for clusters.
    2) Store the component tree on the client, making the web pages huge with all consequent unpleasant effects.
    3) Do not cache the component trees at all, and significantly affect the performance of the system.
    It seems to me that none of these choices are acceptable for a large commercial application.

    A possible solution is the combined static/dynamic approach used by Tapestry. I am not sure when (and if at all) that will become a part of JSF. Unfortunately, that will not be soon in any case...
  88. It is great that Seam would help out with using JSF. The approaches you outlined would be excellent. It seems to me that when JSF first came out, its creators concentrated on the theoretical aspects of the framework, rather than its practical use. As if they did not have the time (or did not care) to observe how it would be used by real developers of average skill. As a result, the framework was certainly usable by experts, but in the general case you would very often get podcasts like the one that started this discussion, or many, many articles that express horrible experiences or confusion. What bugs me here is that many people prefer to insult Tim Shadel's intelligence, rather than ask themselves what can be done to make JSF more intuitive and simpler.

    Undoubtedly JSF has had some teething problems. In particular, I hope no-one will be offended if I say that the JSF guys have done, overall, a bad job on communications. I still can't buy any really great book about JSF that explains it from a user rather than theoretical point of view. I really hope that this gets fixed soon.

    I also get the impression that JSF implementations have only recently got to a decent level of maturity. My late-coming-ass has only been using JSF for about 6 months, so I guess I've not been exposed the problems that some of the early adopters experienced, since they have been fixed in the meantime.
    For example, the exclusively dynamic approach for building the component tree means that the developer would need to make one of the following choices: ... A possible solution is the combined static/dynamic approach used by Tapestry.

    I'm pretty sure that we will soon start to see JSF implementations pop up that do this kind of optimizations. I agree that Tapestry's approach is nicer than the approaches defined in the JSF spec.

    OTOH, I've not really seen any major performance problem using client-side state saving. It turns out that in practice the serialized component tree is not that huge compared to the size of the rest of the page. I think this is a thing that bothers guys like you and Jacob, but is in practice no problem for typical users. (As others have pointed out in this thread, this was the same approach taken at Redmond, so I guess it is percieved to have some things going for it...)

    I would never use JSF server-side state saving, however. AFAICT, there is no way to implement server-side state saving that is both non-broken (tolerant of the back button and of multi-window operation) and reasonably efficient. Unfortunately, JSF implementations are doing server-side state saving by default, which is a definite Bad Thing, IMO. If my analysis of this stuff is correct, we need to be teaching users to ALWAYS use client-side state saving with JSF. (I may be wrong on this, Jacob and Werner should correct me here.)
  89. AFAICT, there is no way to implement server-side state saving that is both non-broken (tolerant of the back button and of multi-window operation) and reasonably efficient. Unfortunately, JSF implementations are doing server-side state saving by default, which is a definite Bad Thing, IMO. If my analysis of this stuff is correct, we need to be teaching users to ALWAYS use client-side state saving with JSF. (I may be wrong on this, Jacob and Werner should correct me here.)

    The back button issue is solved both in the RI as well as in MyFaces on server side state saving. There is code which restores the last 20 possible states in case of a back to my knowledge.
  90. AFAICT, there is no way to implement server-side state saving that is both non-broken (tolerant of the back button and of multi-window operation) and reasonably efficient. Unfortunately, JSF implementations are doing server-side state saving by default, which is a definite Bad Thing, IMO. If my analysis of this stuff is correct, we need to be teaching users to ALWAYS use client-side state saving with JSF. (I may be wrong on this, Jacob and Werner should correct me here.)
    The back button issue is solved both in the RI as well as in MyFaces on server side state saving. There is code which restores the last 20 possible states in case of a back to my knowledge.
    Sorry to reply myself, the back button restore probably is not in MyFaces 1.1.1, the current nightlies definitely have them in there. I think it was added to the codebase shortly after 1.1.1.
  91. Re: backbutton[ Go to top ]

    (I may be wrong on this, Jacob and Werner should correct me here.)
    The back button issue is solved both in the RI as well as in MyFaces on server side state saving. There is code which restores the last 20 possible states in case of a back to my knowledge.

    Now my assumption is that the only way to implement this is to actually keep 20 copies of the component tree sitting there in memory, right?

    Well, maybe its OK, but it strikes me as pretty costly.
  92. Re: backbutton[ Go to top ]

    (I may be wrong on this, Jacob and Werner should correct me here.)
    The back button issue is solved both in the RI as well as in MyFaces on server side state saving. There is code which restores the last 20 possible states in case of a back to my knowledge.
    Now my assumption is that the only way to implement this is to actually keep 20 copies of the component tree sitting there in memory, right?Well, maybe its OK, but it strikes me as pretty costly.

    Not really that costly... due to the fact that the server either serializes to memory or to disk whatever, if you do not like that you always can switch to client side state saving.
    But the state saving is not really that much of an issue, never has been outside of this discussion forum in the real world. JSF has some problems, keeping a handful of states as history definitely is not one of them.
    As someone pointed out already, there is not too much data state saved anyway, due to the fact, that the components themselves minimize the data they save. Not the entire component is serialized only the data which is needed to restore the state (if you look into the code, internal arrays are built which are filled with the data instead of going a generic serialisation route)

    On the other hand without state saving some stuff never would have been possible a certain way. For instance myfaces has the saveState component which allows scoping over multiple pages of data, on component level, such a thing never would have been possible without state saving. Another thing to note is that most apps I have seen in the past had to deal with back buttons etc, in one way or the other and they either went the session route or keeping track of an input history. So the mechanism of keeping a server side input history is very common, due to the brokeness of html itself of not being able to keep states.
  93. Re: backbutton[ Go to top ]

    Sorry I forgot, it either is 20 or 10 states, I cannot remember the exact number. Fact is the RI has had that mechanism for ages to my knowledge and it only recently was introduced as similar but not the same implementation in MyFaces because issues with server side state saving regarding back buttons constantly were cropping up.
    Dont ask me for the exact history of state saving and which costs it causes, but runtime tests of this mechanism were done in the MyFaces devs list after introduction and can be looked up.
  94. Re: backbutton[ Go to top ]

    I've not really seen any major performance problem using client-side state saving. It turns out that in practice the serialized component tree is not that huge compared to the size of the rest of the page. I think this is a thing that bothers guys like you and Jacob, but is in practice no problem for typical users.
    Client-side state (do you mean _viewstate-like hidden field that is passed in response/request back and forth?) assumes that requests are properly sequence and this sequence is orchestrated by server. If in the middle of conversation I enter an address in browser address line, client state is gone (unless it has been saved with Javascript. Can JSF do that? Even if it can, Javascript might be turned off).

    Volleying app state over wire each time is simply a bad concept from an engineering point of view. Appstate should either sit on a client (Javascript) or on the server. Application can check for Javascript availability and if it is available save state in client-side Javascript objects, otherwise store state in the session.
    I would never use JSF server-side state saving, however. AFAICT, there is no way to implement server-side state saving that is both non-broken (tolerant of the back button and of multi-window operation) and reasonably efficient.
    Webapp is not a hyperdocument, you cannot enter the same waters twice. What is your idea of proper Back button support? Go back and restore the page as it was along with its state? This is what Opera tries to to according to HTTP 1.1 spec, section 13.13. But this does not work well for applications. Application state already has been changed, say credit card has been charged. Or do you suggest to rollback the model/database change? And to inform about it all third-party agencies you work with, and they has to support this rollback feature too?

    Who decides the boundaries of UI and model transactions? When the changes should be committed to database? Or the whole conversation should be a large single transaction? Does not seem convenient for me.

    I prefer to save state on server. You click Back, non-cachable page is reloaded and reflects updated state of application. If the page previously contained "Add" button, this time it would have "Edit" button. Yes, this approach contradicts with browser history list recommendations, but is simple and works well.
    Unfortunately, JSF implementations are doing server-side state saving by default, which is a definite Bad Thing, IMO. If my analysis of this stuff is correct, we need to be teaching users to ALWAYS use client-side state saving with JSF. (I may be wrong on this, Jacob and Werner should correct me here.)

    I'd say, that saving state on the server was a JSF selling point for me when I first tried it. If not for this feature, I would not even have looked at JSF at all. Your late-coming-ass probably still has Struts imprints on it, where request scope is the King.
    [Werner Punz:] The back button issue is solved both in the RI as well as in MyFaces on server side state saving. There is code which restores the last 20 possible states in case of a back to my knowledge.
    So the transaction size is 20 pages. Why not 5 or 200? Does this mechanism has its ways into data model to get hints about when business transaction has finished? This approach is at the same level as Struts token, both of them know nothing about what really happens with data, they just keep the flag/counter in web layer.
    The back button issue is solved both in the RI as well as in MyFaces on server side state saving. There is code which restores the last 20 possible states in case of a back to my knowledge.
    Now my assumption is that the only way to implement this is to actually keep 20 copies of the component tree sitting there in memory, right?Well, maybe its OK, but it strikes me as pretty costly.

    This is not costly, this is plain stupid. What strikes me is that after all preaching that HTML/HTTP is not appropriate for building applications, MyFaces tries to squeeze itself back into the Prokrustes bed of browser history list, essentialy requiring from an applicaiton to keep a 20-back-clicks-long ongoing UI transaction. Incredible. Great minds think alike I guess, Wicket has the similar bright idea of "Back button support".
  95. Re: backbutton[ Go to top ]

    [Werner Punz:] The back button issue is solved both in the RI as well as in MyFaces on server side state saving. There is code which restores the last 20 possible states in case of a back to my knowledge.
    So the transaction size is 20 pages. Why not 5 or 200? Does this mechanism has its ways into data model to get hints about when business transaction has finished? This approach is at the same level as Struts token, both of them know nothing about what really happens with data, they just keep the flag/counter in web layer.
    The back button issue is solved both in the RI as well as in MyFaces on server side state saving. There is code which restores the last 20 possible states in case of a back to my knowledge.
    Now my assumption is that the only way to implement this is to actually keep 20 copies of the component tree sitting there in memory, right?Well, maybe its OK, but it strikes me as pretty costly.
    This is not costly, this is plain stupid. What strikes me is that after all preaching that HTML/HTTP is not appropriate for building applications, MyFaces tries to squeeze itself back into the Prokrustes bed of browser history list, essentialy requiring from an applicaiton to keep a 20-back-clicks-long ongoing UI transaction. Incredible. Great minds think alike I guess, Wicket has the similar bright idea of "Back button support".
    First of all I looked it up, the value is parametrizable everything above that value is weak referenced, so you can trim it down to one and have the garbage collector either keep it or drop it, the cost is selective there.
    Secondly, I said HTTP is broken for application design yes you are right. But MyFaces tries to be in the boundaries of JSF and tries to extend it in many ways, having such a mechanism is an extension. MyFaces is not a project like Tapestry which tries to built its own framework but it tries to stay within the JSF standardization thats basically it.
    As for keeping the states, you cannot have it one way or the other without altering the stateless http protocol on one level you need at least some state saving, it is either on the server or client side of things, that is the culprit of a stateles protocol you try to plug an application base on top.

    As I said I have seen many webapps and most which reached a certain boundary either used excessively sessions, or introduced a state saving history of their own. In MyFaces and in the RI, the framework can take care of that, but only if you wish. I did not say the entire state saving issue is perfect it is somewhat too course grained, it could have been done on component level as well, but it is not a huge boundary which prevents the usage of JSF, due to the fact that the components minimize themselves the amount of data which is serialized. (in many cases only a handful of bytes)
    Due to the fact that all the normal serialization administrative data is bypassed by a raw, we only save what we really need in the most minimalistic data structures possible way.

    If you are not fine with that, feel free to use alternatives ;-)
  96. Re: backbutton[ Go to top ]

    MyFaces is not a project like Tapestry which tries to built its own framework but it tries to stay within the JSF standardization thats basically it.
    Does JSF require to rollback model when you click Back, so that model would be in sync with an old page?
    As for keeping the states, you cannot have it one way or the other without altering the stateless http protocol on one level you need at least some state saving, it is either on the server or client side of things, that is the culprit of a stateles protocol you try to plug an application base on top.
    Why? Comparing to X or Windows GDI, HTML/HTTP is just view technology. It does not have to be stateful besides keeping relation of user's browser window to an application (session tracking, that is). The problem arises when people stick state into HTML.
    Due to the fact that all the normal serialization administrative data is bypassed by a raw, we only save what we really need in the most minimalistic data structures possible way.
    You need to encrypt it as well, right? Wasting processor time on a job that can be skipped entirely if state was stored on server.
    If you are not fine with that, feel free to use alternatives ;-)
    That is what I am trying to do ;-) Let's see what choices do we have (I'd love to see more options):

    1) Click Back, page is cached, or page is non-cached but browser honors history list (Opera). Stale page is shown, server is not notified ==> server and page are out of sync.
    2) Click Back, page is non-cached and browser agrees to reload a page from server. Page is updated according to server state, say by changing "Add" button to "Edit" button for the same data ==> server and page are in sync.
    3) Click Back, page is non-cached and browser agrees to reload a page from server. Application recognizes that browser reloads a page corresponding to previous state. Viewstate is rolled back, page is displayed with data corresponding to that state. ==> server and page are in sync.

    Seems like MyFaces (and Wicket? would like to hear their comment on this matter) uses approach (3). I prefer approach (2).

    * What happens in case (3) when a user clicks Forward after clicking Back? Will the viewstate be rolled forward?
    * How does viewstate correspond to model state in case (3)? What if I use third party to charge a credit card, how do I roll the business transction back? And then roll it forward?
    * Approach (3) works when page is reloaded by browser. What if it is not? The browser would show stale page and it would be out of sync with server.

    So, approach (3) works only if page is actually reloaded, as well as approach (2). With both techniques, browser and server go out of sync if page is not loaded. So, approach (3) still sucks when page is being cached, but requires more efforts when page is reloaded. Is the result worth the labor? Do you really think that a user who just payed for his new digital camera online, expects to see the same "Confirm your order" page when he hits Back button? I think that he would shit in his pants trying not to click submit button again, but your experience may differ.

    ---
    Michael Jouravlev
    JSP Controls: Create page components with JSP
  97. Re: backbutton[ Go to top ]

    State on server is not so trivial too. It can be concurrency and scalability issue, I need both ways to store state in the same application and I can not use "the best way".
  98. Wicket Back Button Support[ Go to top ]

    Wicket allows the browser to cache pages as it normally would. If the user goes back to a stale page and the page is versioned (you can turn off versioning for pages or components on pages), a version manager object is consulted to retrieve the earlier version of the page and execute the request against that page component. Presently, the UndoPageVersionManager is the only such version manager (although one could easily implement other schemes). The undo version manager stores the deltas between renderings of the same page back to the browser and is capable of reverting the page object to the state that it was in when the rendering happened. In most cases, this means that versioning is transparent and the back button just works the way you would think it ought to. There will, of course, be cases where you want to tweak this behavior. The amount of session state used to track page versions is limited by the page map eviction strategy. By default, page versions are considered in evicting pages and so state can be kept to roughly "last N pages", even if it's just 10 versions of the same page object (for example). Hope this helps.

       Jonathan Locke
  99. Wicket Back Button Support[ Go to top ]

    Uh, I meant to emphasize that the correct page version is not retrieved until it is needed. Going back in your browser will not result in any round trip to the server (if that's what one of these other techniques does). It is only when you actually submit from a browser-cached rendering of a page that is out of date with respect to the page object that the page object will be adjusted to match. Make sense?
  100. Wicket Back Button Support[ Go to top ]

    I also forgot to mention that the more obvious version-by-cloning technique is something that we played with and rejected because object versioning is both more time and space efficient. There is some ongoing need in the framework to version relevant state, but that is something that only the core developers (and developers of complex components that require versioning) need to think about. For the end user, it just works.
  101. OTOH, I've not really seen any major performance problem using client-side state saving.

    I am pretty sure that in the past many people complained bitterly about client-side state saving in Microsoft web products. The consensus was that the approach is okay for intranet applications, but is highly unsuitable for internet ones due to the traffic and delays it generates.

    I am not sure how this applies to JSF, of course, given what Werner is explaining, but in any case this issue needs to be approached carefully, especially for complex pages.
  102. OTOH, I've not really seen any major performance problem using client-side state saving.
    I am pretty sure that in the past many people complained bitterly about client-side state saving in Microsoft web products. The consensus was that the approach is okay for intranet applications, but is highly unsuitable for internet ones due to the traffic and delays it generates. I am not sure how this applies to JSF, of course, given what Werner is explaining, but in any case this issue needs to be approached carefully, especially for complex pages.

    There is indeed a performance gap between server side and client side state saving, one of the reasons why Matthias Broeckelmann (to my knowledge) added the restore history
    to server side state saving in MyFaces shortly after 1.1.1 was released.
    My personal guess is that it really depends on the application and probably on the complexity of the forms, whether one method or the other is suitable.
    The JSF state saving tries to minimize data by bypassing the generic serialisation in favor of an array which only has the data necessary to restore the single components. But most people I know still have switched to pure server side state saving now the state saving history is in place.
    (and yes the performance gap is visible)

    here is the thread where the mechanism is described:
    http://marc.theaimsgroup.com/?l=myfaces-dev&m=112964902727448&w=2

    I cannot find the tests yet but they are either to be found in the users or devs list...
  103. OTOH, I've not really seen any major performance problem using client-side state saving.
    I am pretty sure that in the past many people complained bitterly about client-side state saving in Microsoft web products. The consensus was that the approach is okay for intranet applications, but is highly unsuitable for internet ones due to the traffic and delays it generates. I am not sure how this applies to JSF, of course, given what Werner is explaining, but in any case this issue needs to be approached carefully, especially for complex pages.

    For an internal app here done in .NET they've been ripping out the client-side state and replacing it with DB driven one... This was in response to HTML pages that were on the order of 500K. That's the risk you face copying Redmond :-)
  104. For an internal app here done in .NET they've been ripping out the client-side state and replacing it with DB driven one... This was in response to HTML pages that were on the order of 500K. That's the risk you face copying Redmond :-)

    I've been questioning the reasons for even maintaining state in component based frameworks and if there was opportunity to have a hybrid approach with request-scoped components-- leaving you with something vaguely like XWork's Interceptors (parent components) and Actions, except that since they are components, they can validate/update/invoke and render themselves within the request cycle. With Facelets, I could add a single line of code to the 'createView' call to have this happen.
  105. For an internal app here done in .NET they've been ripping out the client-side state and replacing it with DB driven one... This was in response to HTML pages that were on the order of 500K. That's the risk you face copying Redmond :-)
    I've been questioning the reasons for even maintaining state in component based frameworks and if there was opportunity to have a hybrid approach with request-scoped components-- leaving you with something vaguely like XWork's Interceptors (parent components) and Actions, except that since they are components, they can validate/update/invoke and render themselves within the request cycle. With Facelets, I could add a single line of code to the 'createView' call to have this happen.

    I manage my state with Session and Request scoped components in Spring which can be wired up or down with different scoped components. It's all very natural and transparent. I'd assume something similar could be wired together with JSF.
  106. For an internal app here done in .NET they've been ripping out the client-side state and replacing it with DB driven one... This was in response to HTML pages that were on the order of 500K. That's the risk you face copying Redmond :-)
    I've been questioning the reasons for even maintaining state in component based frameworks and if there was opportunity to have a hybrid approach with request-scoped components-- leaving you with something vaguely like XWork's Interceptors (parent components) and Actions, except that since they are components, they can validate/update/invoke and render themselves within the request cycle. With Facelets, I could add a single line of code to the 'createView' call to have this happen.
    I manage my state with Session and Request scoped components in Spring which can be wired up or down with different scoped components. It's all very natural and transparent. I'd assume something similar could be wired together with JSF.

    I look at lifecycle management as a concern of the business process and IoC frameworks (Seam/Spring) do a great job of that for you-- so why have a stateful UI when JSF UIComponents are completely separate from any actual references (member variables) to business objects (instead by proxy via EL). So there's tons of opportunity here to treat stateful JSF as a niche case that needs to be explored further. This may open the doors to use JSF as a presentation tier for other MVC frameworks.
  107. I look at lifecycle management as a concern of the business process and IoC frameworks (Seam/Spring) do a great job of that for you-- so why have a stateful UI when JSF UIComponents are completely separate from any actual references (member variables) to business objects (instead by proxy via EL). So there's tons of opportunity here to treat stateful JSF as a niche case that needs to be explored further. This may open the doors to use JSF as a presentation tier for other MVC frameworks.

    That sounds like a much better idea... of course, it also kind of sounds like the UI components we have for WebWork already ;-)
  108. I look at lifecycle management as a concern of the business process and IoC frameworks (Seam/Spring) do a great job of that for you-- so why have a stateful UI when JSF UIComponents are completely separate from any actual references (member variables) to business objects (instead by proxy via EL). So there's tons of opportunity here to treat stateful JSF as a niche case that needs to be explored further. This may open the doors to use JSF as a presentation tier for other MVC frameworks.
    That sounds like a much better idea... of course, it also kind of sounds like the UI components we have for WebWork already ;-)

    Heheh, yeah-- well not really-- but you don't see companies like Crystal Reports or Oracle creating components for WebWork, I guess it comes with the JSR territory ;-)
  109. Heheh, yeah-- well not really-- but you don't see companies like Crystal Reports or Oracle creating components for WebWork, I guess it comes with the JSR territory ;-)

    Well, at least in the case of Crystal Reports, I'm not sure if that's a positive or a negative...
  110. Unfortunately, JSF implementations are doing server-side state saving by default, which is a definite Bad Thing, IMO. If my analysis of this stuff is correct, we need to be teaching users to ALWAYS use client-side state saving with JSF. (I may be wrong on this, Jacob and Werner should correct me here.)

    This was originally an issue with server-side state saving such that there was a 1:1 relationship between URI and state. You can immediately realize the problem. Now, I know the RI does this, it actually writes a unique id to the page that allows a 1:many views to be stored on the server, tuned as appropriate.
  111. and MyFaces does, too.

    regards,

    Martin
  112. 3) Do not cache the component trees at all, and significantly affect the performance of the system.It seems to me that none of these choices are acceptable for a large commercial application. A possible solution is the combined static/dynamic approach used by Tapestry. I am not sure when (and if at all) that will become a part of JSF. Unfortunately, that will not be soon in any case...

    Actually, that's how Facelets works. When we talk about saving the state of the document, it doesn't mean 'everything' is saved-- just your jsf components. I understand that there is still some redunancy, with the save state across all threads, but the optimization you describe above is there. Facelets actually just injects transient nodes into the component tree that represent common parts of the page, reducing the overall state that must be saved.

    As for re-building the page-- it's cheaper than dealing with serialization and or rendering.
  113. Jason, I encourage you to check out the new demo apps in Seam beta 2 when it is released this week and look at just how simple JSF can be, both to code and to test.

    Post something when it's out and I'll take a look. I'll look for what we can learn from it for ease of use :-)

    I fundamentally disagree that component-based frameworks are a better a fit for the web, and the discussion later in this thread about saving the component state in the page or the session is a good example, but I have no doubt that you've made a much nicer developer experience, so I'll see what we can learn.
  114. Jason, I encourage you to check out the new demo apps in Seam beta 2 when it is released this week and look at just how simple JSF can be, both to code and to test.
    Post something when it's out and I'll take a look. I'll look for what we can learn from it for ease of use :-)I fundamentally disagree that component-based frameworks are a better a fit for the web, and the discussion later in this thread about saving the component state in the page or the session is a good example, but I have no doubt that you've made a much nicer developer experience, so I'll see what we can learn.

    Try to make a decent table with sort ordering, which also interacts into an html editor and probably into a few other fields, and also a form which readjusts itself upon a given state in a normal and in an event driven component system, and then reavaluate your experiences.

    You will have a code reduction of 90% probably in the second approach.
  115. Jason, I encourage you to check out the new demo apps in Seam beta 2 when it is released this week and look at just how simple JSF can be, both to code and to test.
    Post something when it's out and I'll take a look. I'll look for what we can learn from it for ease of use :-)I fundamentally disagree that component-based frameworks are a better a fit for the web, and the discussion later in this thread about saving the component state in the page or the session is a good example, but I have no doubt that you've made a much nicer developer experience, so I'll see what we can learn.
    Try to make a decent table with sort ordering, which also interacts into an html editor and probably into a few other fields, and also a form which readjusts itself upon a given state in a normal and in an event driven component system, and then reavaluate your experiences. You will have a code reduction of 90% probably in the second approach.

    Just like models have walk-off's, we should have a code-off between frameworks!!! booya.
  116. Jason, I encourage you to check out the new demo apps in Seam beta 2 when it is released this week and look at just how simple JSF can be, both to code and to test.
    Post something when it's out and I'll take a look. I'll look for what we can learn from it for ease of use :-)I fundamentally disagree that component-based frameworks are a better a fit for the web, and the discussion later in this thread about saving the component state in the page or the session is a good example, but I have no doubt that you've made a much nicer developer experience, so I'll see what we can learn.
    Try to make a decent table with sort ordering, which also interacts into an html editor and probably into a few other fields, and also a form which readjusts itself upon a given state in a normal and in an event driven component system, and then reavaluate your experiences. You will have a code reduction of 90% probably in the second approach.
    Just like models have walk-off's, we should have a code-off between frameworks!!! booya.


    Useless, Rails probably would come out as winner most of the times ;-)
  117. Try to make a decent table with sort ordering, which also interacts into an html editor and probably into a few other fields, and also a form which readjusts itself upon a given state in a normal and in an event driven component system, and then reavaluate your experiences. You will have a code reduction of 90% probably in the second approach.

    Oh my God! I never thought of making reusable UI components! Wow! What a revelation!

    In case you don't get it, that's sarcasm. It's not the reusable UI component bit I disagree with... WebWork has (arguably) a much better story here than I've seen in JSF since our UI components are themed and templated, so you can modify what they output VERY easily and build up your own theme with related templates for all / some of the UI components.

    What I disagree with is that these pieces should send roundtrips back to the server to refresh the page for fine-grained component-to-component event stuff. When I need this I can very easily wire it together by using AJAX templates for my UI components and refreshing just the pieces that have to change.

    ...and for the record, yes, I've got a pre-built sortable pageable table JSP tag backed by templates which is AJAX enabled for just this sort of thing.
  118. Migrating vs. New Development[ Go to top ]

    <gavin>
    What I do believe is that the Java community would be incredibly well served if they migrated en masse away from Struts and on to JSF.
    </gavin>

    I don't agree with "migrating". Why should I migrate if:
    - the frameworks (Struts, Webwork, etc.) work without any problems? Performance is good (this is not the same with Entity Beans 1.1, or 2.1 to compare with Hibernate, DODS), you have enough developers who know how to work with them...
    - at the end we develop applications not because we love doing it, but we want to solve domain problems. Struts, JSF whatsoever give us the *same* output: web browser oriented user interface (server-side presentation layer with web browser) no more, no less. Users of the applications *won't care* whether they are written in Struts, JSF, etc. So they are only a means to an end, IMO.

    This is *very different* if you are talking about "writing new applications/functions*. Yes, in this case I would go for JSF/Facelets.

    So, we need a new layer on which we can define our presentation layer independently from all these techniques (JSP/Struts, Facelets/JSF, XMLC/EAF, Tapestry, etc.), so we are going to be able to *mix and match* them and use them in the right place as they can serve to solve our problems. Read: MDA. ;-)

    Cheers,
    Lofi.
  119. With JSP, you can create a tag (not a component) that renders complex form input. As a JSF component, that entity could now actually carry validation logic, update/invoke methods on beans back at the server, etc.

    Component is just a reusable piece of code with the formalized interface. And nothing more, IMHO. So I am afraid what you wrote is not correct. You can create components with JSP or PHP or whatever you use. JSF offers a model for the communications between own components – that is what any framework is about.
    Rendering is only one aspect of what components can do in the mvc lifecycle
    Are you sure? Struts taglibs carry validation, update/invoke methods on beans back at the server, etc. for years. Are they components or not?
  120. With JSP, you can create a tag (not a component) that renders complex form input. As a JSF component, that entity could now actually carry validation logic, update/invoke methods on beans back at the server, etc.
    Component is just a reusable piece of code with the formalized interface. And nothing more, IMHO. So I am afraid what you wrote is not correct. You can create components with JSP or PHP or whatever you use. JSF offers a model for the communications between own components – that is what any framework is about.
    Rendering is only one aspect of what components can do in the mvc lifecycle
    Are you sure? Struts taglibs carry validation, update/invoke methods on beans back at the server, etc. for years. Are they components or not?

    No, because those tags aren't self contained in the functionality they provide. I don't want to get into a debate of terms just that JSP pages are compiled with one event type for rendering pages. JSF components have N event types for providing any amount of behavior, including rendering that are, at their core, protocol agnostic. With JSF you literally end up with a mutable tree of components, just like Swing that you can prune or add to for coordinating specific requirements. Rendering is a huge aspect of MVC frameworks, but people can't define JSF components simply by their rendered output-- its the tip of the iceberg.
  121. No, because those tags aren't self contained in the functionality they provide.

    So SendMail tag does not send mail (no functionality), SQL taglib does not request server etc. Great, how do we program right now?
    JSF components have N event types for providing any amount of behavior, including rendering that are, at their core, protocol agnostic.

    no words to be honest, especially about _any_ behavior :-)
  122. No, because those tags aren't self contained in the functionality they provide.
    So SendMail tag does not send mail (no functionality), SQL taglib does not request server etc. Great, how do we program right now?

    I understand what you are saying...
    JSF components have N event types for providing any amount of behavior, including rendering that are, at their core, protocol agnostic.
    no words to be honest, especially about _any_ behavior :-)

    JSF has an event system like swing-- so you can take an example from Oracle and have your components pass around any custom even types, such as 'onClick' or 'valueChanged' or there are custom ones for tree models or tables too. So you could have a component (like a menu) somewhere else in the document and have it communicate with a text area elsewhere in the document w/o having to worry about state of everything else in the document.
  123. With JSP, you can create a tag (not a component) that renders complex form input. As a JSF component, that entity could now actually carry validation logic, update/invoke methods on beans back at the server, etc.
    Component is just a reusable piece of code with the formalized interface. And nothing more, IMHO. So I am afraid what you wrote is not correct. You can create components with JSP or PHP or whatever you use. JSF offers a model for the communications between own components – that is what any framework is about.
    Rendering is only one aspect of what components can do in the mvc lifecycle
    Are you sure? Struts taglibs carry validation, update/invoke methods on beans back at the server, etc. for years. Are they components or not?
    No, because those tags aren't self contained in the functionality they provide. I don't want to get into a debate of terms just that JSP pages are compiled with one event type for rendering pages. JSF components have N event types for providing any amount of behavior, including rendering that are, at their core, protocol agnostic. With JSF you literally end up with a mutable tree of components, just like Swing that you can prune or add to for coordinating specific requirements. Rendering is a huge aspect of MVC frameworks, but people can't define JSF components simply by their rendered output-- its the tip of the iceberg.
    Protocol-agnostic web frameworks is a gimmick, as well as multi-device rendering abilities. I would love to hear about someone who implemented a *non-web* project using JSF or WebWork, or about HTML/WML/VoiceXML application that uses *exactly the same* set of components and events. I did such an application several years ago with Struts. The markup, input procesing model, memory requirements are different enough to justify three different sets of markup files. The business model, validation, error handling, this all stayed the same though.

    On the other counts, it *is* possible to create components in JSP that are:

    * self-contained;
    * independent from a page they aggregated into;
    * have individual lifecycle;
    * process input data and [any number of] user events;
    * activated with either POST or GET;
    * render themselves;
    * do not require central controller or portlet engine.

    For example, this page contains two absolutely independent JSP components. Its source code reveals tho JSP include actions, that is it. Who handles the requests? The trick is that instead of encapsulating common rendering functionality into tags, the composite page dynamically includes JSP files. Old-fashioned? Nah! JSP files can be addressed and therefore can be submitted to. Voila, every included JSP is therefore is component, because it handles its input and renders itself. The tricky part is to make composite page unaware of that and to re-render it properly after request is processed. This is handled by five or so tags, that is it, everything else comes from your JSP or JSP/Struts or JSP/WebWork toolbox (as you see, JSP is essential part of this).

    Try the above example with Javascript turned on and off. Use your favorite HTTP sniffer and see the difference in request routing. Visually the result is absolutely the same. Unlike many Ajax-only solutions, my JSP components work in ancient browsers too. Try them in Netscape4 for a change. The whole page is reloaded if Javascript or XHR is not available, but programming model does not change and user experience does not differ too.

    The point I am trying to make is that it is possible to create true componentized web application using good old JSP and just half a dozen tags. Of course, there is no built-in data conversion, or component viewstate, or validation or error messages. These are the benefits that a real framework like JSF provides. But if all you need is to make simple portlet-like page components using nothing more than JSP, you can do it.

    ---
    Michael Jouravlev
    JSP Controls: Create page components with JSP
  124. Michael, with your tabs, now lets say you wanted to tie that into a button from another part of the page-- that maybe hops to a different tab-- or changes the text of that tab?

    What standards/functionality does it have in place to accomodate the kind of features that would be practical for others who want to add similar components?
  125. Michael, with your tabs, now lets say you wanted to tie that into a button from another part of the page-- that maybe hops to a different tab-- or changes the text of that tab?
    In my universe a user does not hop to a tab, he send a command, an event, a humble request to do something (this approach is a telltale of Struts user, is not it? ;) ) The event may change system's state. Or not. It depends on current state and on the business rules. With tab component, states are not that prominent so you can put equal sign between state and a current tab. For other components the difference can be more evident.

    In your example the button would correspond to a different component and would sent event to it. Obviously, the button component should know either about tab component existence, or all components should share common command/state object, where commands can be delivered. Anyhow, the button changes (oops, tries to change) state of the tab component. After command is processed, the page is refreshed and tab component picks up its new state during render phase and draws itself according to the state. Simple. With Ajax it is a little bit more involved because button has to refresh tab component only. This is possible, but the process is not as well hidden yet as I want it to be. I did three alpha releases now, and I expect another one or two for the library to mature.
    What standards/functionality does it have in place to accomodate the kind of features that would be practical for others who want to add similar components?
    The library has only five or so tags. These tags provide a *lifecycle* for an independent component: receive request, analyze its type. If it is a command the handle it and redirect (non-Ajax) or render a view (Ajax). If it is a simple GET, then render component according to its state. This is it.

    The bells and whistles are all up to a developer. Creating completely independent component is a breeze. Creating components that interact with each other would require to build some kind of API, this is the serious task and I do not plan anything like it at this moment. But even if/when this API were released, the components themselves *can* be independent. If they do not need to interact with other components, they do not *need* this API or a Portlet container. I think that this independence, ability to work on older appservers and with ancient browsers is something that worth considering.

    Anyhow, I think that my library is already practical enough to be considered by a JSP developer. But it is not a rival to JSF in any way ;-)

    ---
    Michael Jouravlev
    JSP Controls: Create page components with JSP
  126. Nobody is saying use the same PAGE, we're saying you can use the same COMPONENTS on different devices.

    You still have to code the PAGES to fit the platform you're developing for, but you would use the same components, with different renderkits for each (HTML/WML/VoiceXML/XUL etc...).

    For example, if I were to code a page using a JSP-based JSF implementation, I might use a <h:outputLabel/> and <h:inputText/> tags for a login web page. I can uses these same tags for a page that is targeted at WML devices. The tags are the same, the page is different because of the screen limitations and the renderkit is different because I want WML instead of HTML.
  127. Tags can support different formats without JSF. You do not need framework for that. Tag (or component in JSP, ASP etc) outputLabel can take care and provide HTML/WML etc.

    Dmitry
    Coldbeans
  128. Tags can support different formats without JSF. You do not need framework for that. Tag (or component in JSP, ASP etc) outputLabel can take care and provide HTML/WML etc. Dmitry

    But if you don't have a standard framework, you can't have a community of developers producing compatible components that work with the same API and in the same tools. You would not have situations like Oracle donating a large number of components to the Apache MyFaces project.
  129. But if you don't have a standard framework, you can't have a community of developers producing compatible components that work with the same API and in the same tools. You would not have situations like Oracle donating a large number of components to the Apache MyFaces project.

    Again nothing against JSF but what Servlets API (or JSP) are not standard anymore?

    Dmitry
    Coldbeans
  130. But if you don't have a standard framework, you can't have a community of developers producing compatible components that work with the same API and in the same tools. You would not have situations like Oracle donating a large number of components to the Apache MyFaces project.
    Again nothing against JSF but what Servlets API (or JSP) are not standard anymore?

    They remain essential standards. JSP is very widely used, and JSF is being adapted so that it can work better with JSP (if you choose JSP as your presentation mechanism).

    The Servlet API is vital to JSF - if you look at web.xml in a Faces app you will see mention of the Faces Servlet.

    You can add your own servlets (or JSP pages) to a JSF app to add additional functionality if you find this convenient.
  131. Nobody is saying use the same PAGE, we're saying you can use the same COMPONENTS on different devices.You still have to code the PAGES to fit the platform you're developing for, but you would use the same components, with different renderkits for each (HTML/WML/VoiceXML/XUL etc...).

    For example, if I were to code a page using a JSP-based JSF implementation, I might use a <h:outputLabel/> and <h:inputText/> tags for a login web page. I can uses these same tags for a page that is targeted at WML devices. The tags are the same, the page is different because of the screen limitations and the renderkit is different because I want WML instead of HTML.
    Will JSF component cut one monolithic page into several? Or vice versa, combine several pages into a deck? Will it make sure that the size of generated WML does not exceed the memory size of a certain mobile phone? (Maybe memory constraints are not a big deal now, I did my WML project several years ago).

    Anyway, there is nothing special in creating different output for different devices after all. A regular JSP tag can do this too. Note, that I am not arguing that JSP is better than JSF, I am just saying that this particular feature can be implemented with JSP quite easily if needed.

    ---
    Michael Jouravlev
    JSP Controls: Create page components with JSP
  132. Two things though. I'm still missing why JSP *had* to be part of JSF (something to do with SUN perhaps, or is it because of the number of people that were crazy about JSP?).
    It isn't part of JSF. The reference implementation (and all implementations that I know of) come with JSP versions of the rendering technology, but that is simply for convenience - JSP was a well-established way of producing web pages.
    And I think that while JSF could and should have been much better, it is still an improvement over Struts.
    It certainly is if you like component-based design.

    Lets say it that way, people who dislike component based designs should have to do very interactive applications with lots of high level controls in pure html without any componentization and then should row up and give their opinion about going non component based design routes. I rather doubt if you have 100 people in a row which have to do that that more than 2 people still hate component based designs ;-).

    Face it HTML was a step back 25 years application development wise. Suddenly for some strange kind of reason things became en vogue again, which were killed off by better designs which originated in the Xerox PARC around 1975 (namely, component/object based user interfaces with clear event systems)

    But not because the system was better, just because the money was there (namely the Web) and you simply had problems to sell rich client based systems. Everything had to be browser based although HTML in its shoddy by Microsoft artificially frozen state was the worst of all available application bases.

    I can remember in the early eighties times when everyone was exited that finally the whole server side rendering drag became obsohlete (can anyone remember VT220), text based and later windowing frameworks popped up left and right, and then suddenly something came up which never was intended to be an application base and now we deal with myriads of frameworks which try to bypass the deficiencies of such approaches and try to find routes to saner grounds where there are none.

    Sorry to say that, but give me a decnent component based UI and event system over any server side rendered stuff again and I will be the happiest guy on earth. And face it things also in the web world finally are moving to saner grounds. For years there have been XUL which was basically ignored, there are popping up rich client frameworks on saner ui technologies (while being flash based, at least they are stateful and have components). And Microsofts long term plans are also to eliminate HTML entirely with XAML which is basically a XUL fork!

    So people who scream for non stateful server side component less UIs probably will have to find a job in a few years or have to adjust to saner grounds again.
    JSF definitely is not the end of the road but definitely a step in the right direction of trying to fix a broken application base at least to a certain extent, the same goes for Tapestry.
  133. And I think that while JSF could and should have been much better, it is still an improvement over Struts.

    big +1

    That's the whole point. Craig M starting and leading JSF spec (and not just being on the commitee) is a problem, not a benefit.

    Here is why: Craig realized Struts was not doing so well, sensed that there may be a future in components-based frameworks, BUT instead of looking what was already available, he decided to "start fresh" or more precisely - challange his intellectual potential. Which, I am sure was lots of fun for him, but not so much for the industry.

    Neither Struts nor WebWorks are components-based frameworks so JSF should not have been based on it. Yet, Craig tried to build JSF on the Struts experience - WRONG! If I remember correctly, I think there was even an attempt, initially, to have JSF compatible with Struts (!!!!).

    As far as "tool support" goes. It's not that JSF has good tool support but the reality is - it is almost useless without GUI tools to cover-up bloated XML and structure :)'

    First, I do not agree it is less bloated than anything, even in Java. Tapestry does exist, thanks God and I would claim is much better.

    Secondly, Java is not the only player and that's exactly the problem - trying to establish JSF as the framework in Java, may cause loosing a lot of web-developers. Turning them off towards non-Java systems.

    That is sad to me. Because Java is a very strong platform - not just a language but the whole wealth of different libraries, not having alternatives in Ruby or even Python.
  134. And I think that while JSF could and should have been much better, it is still an improvement over Struts.
    big +1That's the whole point. Craig M starting and leading JSF spec (and not just being on the commitee) is a problem, not a benefit.Here is why: Craig realized Struts was not doing so well, sensed that there may be a future in components-based frameworks, BUT instead of looking what was already available, he decided to "start fresh" or more precisely - challange his intellectual potential. Which, I am sure was lots of fun for him, but not so much for the industry.Neither Struts nor WebWorks are components-based frameworks so JSF should not have been based on it. Yet, Craig tried to build JSF on the Struts experience - WRONG! If I remember correctly, I think there was even an attempt, initially, to have JSF compatible with Struts (!!!!).As far as "tool support" goes. It's not that JSF has good tool support but the reality is - it is almost useless without GUI tools to cover-up bloated XML and structure :)'First, I do not agree it is less bloated than anything, even in Java. Tapestry does exist, thanks God and I would claim is much better.Secondly, Java is not the only player and that's exactly the problem - trying to establish JSF as the framework in Java, may cause loosing a lot of web-developers. Turning them off towards non-Java systems.That is sad to me. Because Java is a very strong platform - not just a language but the whole wealth of different libraries, not having alternatives in Ruby or even Python.

    Once again, you provide no technical arguments. You just throw some random personal attacks, facts and avoid the question. You should consider become a politician. Jacob is right, I had forgot about UIX :)
  135. Tool support[ Go to top ]

    As far as "tool support" goes. It's not that JSF has good tool support but the reality is - it is almost useless without GUI tools to cover-up bloated XML and structure :)
    Have you tried to create ASP.NET application without an IDE (er... without the IDE)? Have you looked at the code that is generated by Visual Studio? Some would call it horrible, I would say - impossible to type from scratch in Notepad. Have you developed Windows app using nothing but windows.h, C compiler and resource editor? Have you done the same with Delphi or at least with VB? Have you noted the difference? Do you or your web designer create HTML pages in vi or Notepad? In this case I am out of arguments ;-)

    A true component must have design-time interface. On that count my own library for JSP is limited, it does not have it. But ASP.NET components have design-time interface, Delphi components have design-time interface and JSF components have design-time inteface (Javabean spec is not limited to get/set notation). The GUI/IDE is needed to provide support for design-time interface. Have you lately developed anything that has a window frame and an [x] button on it, or you stuck with standard output? Hello, Windows95 has turned 10 years already ;-)

    ---
    Michael Jouravlev
    JSP Controls: Create page components with JSP
  136. Tool support - for more fun try 2.0[ Go to top ]

    Have you tried to create ASP.NET application without an IDE
    The new version introduces "Partial Classes". Try that without an IDE.
  137. Tool support[ Go to top ]

    Have you tried to create ASP.NET application without an IDE (er... without the IDE)? Have you looked at the code that is generated by Visual Studio?

    actually it is possible and we did. You do not need to generate code instead of Visual Studio. And for writing tags text editor is enough.

    And being honest it is possible to work with JSF without IDE too. And again it is curiously, but the deployment in ASP.NET is simpler than in JSF -:). Or is it me only dislikes XML navigation?

    Dmitry
    Coldbeans
  138. Tool support[ Go to top ]

    actually it is possible and we did
    Eating soup with a fork is possible to. :)
    but the deployment in ASP.NET is simpler than in JSF -:)
    Except when things don't work. And it happens all to often. And as long as Windows doesn't update itself. Happened to me today.
  139. Tool support[ Go to top ]

    As far as "tool support" goes. It's not that JSF has good tool support but the reality is - it is almost useless without GUI tools to cover-up bloated XML and structure :)
    Have you tried to create ASP.NET application without an IDE (er... without the IDE)? Have you looked at the code that is generated by Visual Studio? Some would call it horrible, I would say - impossible to type from scratch in Notepad. Have you developed Windows app using nothing but windows.h, C compiler and resource editor? Have you done the same with Delphi or at least with VB? Have you noted the difference? Do you or your web designer create HTML pages in vi or Notepad? In this case I am out of arguments ;-)
    Yes, looong, loong time ago I have used VB, Delphi and Visual C++. I had nightmares with the kind of code Microsoft tools had generate all these environments.

    When I am writing a Swing application - yes, I am writing the UI code manually. I do this because I tried to use GUI builders (from JBuilder and NetBeans if you want me to be more specific) and the result sucked. But, anyway, I do not write many desktop applications.

    Yes, I am absolutely sure templates ("pure" HTML is long deprecated) should be hand-coded by very knowledgable designers who know how to produce proper DIV-based layout and put proper CSS on it. Web Standards, baby. Welcome to Web 2.0. Even though I believed in hand-coded, before, too - now it is just a must.
    A true component must have design-time interface. On that count my own library for JSP is limited, it does not have it. But ASP.NET components have design-time interface, Delphi components have design-time interface and JSF components have design-time inteface (Javabean spec is not limited to get/set notation). The GUI/IDE is needed to provide support for design-time interface. Create page components with JSP
    I love "vi" as much as I adore IntelliJ. Good IDE improved productivity but I do not believe in a framework that you can not use outside an IDE.

    Sorry, I am not a Microsoft fan, so - the example of .NET, you brought, just proves, once more, to me that big m$ sucks. I am glad I have nothing to do with them. My personal computer is a Mac and all our servers are Linux.

    They can be peeing in their own pants, as far as I am concerned - I would not care.

    And yes, I do realize 90% of desktops is M$, right now, but since I am mostly on serverside - I don't care. Also - there are too many nice cross-platform technologies (Java and Python, two of my favorite) not to be able to write on Mac and run on Windows.

    cheers
  140. Tool support[ Go to top ]

    Correction: Delphi was not a microsoft tool, of course. And Borland was not half as sinful, as MS, actually. Yet, I can not say Delphi-generated code was any close to hand-written.
  141. Tool support[ Go to top ]

    But ASP.NET components have design-time interface, Delphi components have design-time interface and JSF components have design-time inteface (Javabean spec is not limited to get/set notation). The GUI/IDE is needed to provide support for design-time interface. Create page components with JSP
    I love "vi" as much as I adore IntelliJ. Good IDE improved productivity but I do not believe in a framework that you can not use outside an IDE.

    Just because a set of components has a design-time interface does not necessarily mean that these components can't be used easily outside of an IDE.

    The design-time interface is often there to allow developers who want to use visual design tools to use those tools, but does not force use of design tools or an IDE.

    I prefer to code JSF outside of a design tool because I find it easier to produce quality web pages this way - I am not relying on generation of possibly sub-standard code by the IDE. Like you I want proper design with good CSS. Hand-coding JSF allows me to get do this. You can code JSF with vi :)
  142. Tool support[ Go to top ]

    The design-time interface is often there to allow developers who want to use visual design tools to use those tools, but does not force use of design tools or an IDE.I prefer to code JSF outside of a design tool because I find it easier to produce quality web pages this way - I am not relying on generation of possibly sub-standard code by the IDE. Like you I want proper design with good CSS. Hand-coding JSF allows me to get do this. You can code JSF with vi :)

    http://weblogs.java.net/blog/jhook/archive/2005/07/programmer_frie_1.html

    Also, Facelets intelligently watches for file modifications and will allow you do develop/design UIs, realtime with JSF.
  143. Tool support[ Go to top ]

    http://weblogs.java.net/blog/jhook/archive/2005/07/programmer_frie_1.htmlAlso, Facelets intelligently watches for file modifications and will allow you do develop/design UIs, realtime with JSF.

    Nice
  144. Steve, here's how "a lot of people" [1] see it:

    Heh.

    The flaw in your argument is that the same debate seems to arise around a number of JCP specifications....

    Usually with one or more of the following arguments, often about the same specification:

    "Our product is better than [JSR] because it only does [X]. Because we only support [X] we obviously do it better. Nothing as versatile as [JSR] can be good."

    "Of course our product doesn't do [X] like [JSR]. No-one needs this, and no-one has asked for this."

    "What do you mean, we don't support feature [X] of [JSR]? You have the source code, implement it yourself."

    "[JSR] was only designed to make money for vendors."

    "[JSR] is too academic."

    "Of course our product doesn't work like that! You shouldn't be doing that anyway, no matter what vendors of [JSR] say."

    "[JSR] is dead"

    "[JSR] is slow"

    "Not enough vendors support [JSR]"

    "[JSR] ties you in to vendors"

    "[JSR] can't be efficient because it doesn't allow you to use vendor-specific features"

    "[JSR] can't do/isn't [1]" [1] = Capability/Feature of [JSR] usually locatable within a few seconds of Google use.

    "No-one uses [JSR]"

    "The large number of people who use [JSR] are only doing it because it is imposed on them by management."

    I believe there is a general anti-JSR mood in some areas... I think it is a very interesting aspect of the 'Java Community'.
  145. I believe there is a general anti-JSR mood in some areas... I think it is a very interesting aspect of the 'Java Community'.

    I think you are right about that for some JSRs. However, what about people that don't agree with the standard for technical reasons? Take JSF's life cycle (part):

        * Apply requests values
        * Process validations
        * Update model values

    I considered supporting JSF's life cycle for the framework I'm working on, but I didn't because it would break the whole idea of encapsulated objects/ components in my case (in which components themselves are responsible for such things instead of some request handler). Having such a life cycle in a spec *might* look like it is universal, but I think it is debatable. Same goes for things like validators and converters and the fact that as a component developer you still have to comply at least partly to JSP related things. My point here is that for a standard, I think it isn't as generic as it could have been.
  146. I believe there is a general anti-JSR mood in some areas... I think it is a very interesting aspect of the 'Java Community'.
    I think you are right about that for some JSRs. However, what about people that don't agree with the standard for technical reasons?

    I think you make a good point. I agree there are technical issues with JSF, but there are such issues with many current web frameworks. However, the sheer (and often amusing) strength of dislike of JSF does seem to me to imply more than just technical arguments - there is some political/philosophical objection to "standards". The 'JSR' label on anything seems like a red flag to a bull for some people.

    But I guess this topic is a debate probably for another thread at another time.
  147. I considered supporting JSF's life cycle for the framework I'm working on, but I didn't because it would break the whole idea of encapsulated objects/ components in my case (in which components themselves are responsible for such things instead of some request handler).

    Have you really used JSF?? Each component are responsibled of those part. The lifecycle objets are only responsible to traverse the component tree in the correct order and call the components methods. Basically it is a delegator objet with a complex algorithm.
  148. I believe there is a general anti-JSR mood in some areas... I think it is a very interesting aspect of the 'Java Community'.
    sort of like this? http://www.sdtimes.com/article/opinion-20060115-01.html
  149. I believe there is a general anti-JSR mood in some areas... I think it is a very interesting aspect of the 'Java Community'.
    sort of like this? http://www.sdtimes.com/article/opinion-20060115-01.html

    Well, I did not say that concerns about the JCP are always mistaken, just that I found it interesting. It adds another factor to be taken into account when researching reports and other's views on different technologies. I admit I have a (probably obvious) bias towards products that conform to specifications.
  150. I believe there is a general anti-JSR mood in some areas... I think it is a very interesting aspect of the 'Java Community'.

    I think that's healthy. There has to be a balance between what is needed by enterprises - reliable specifications and standards - and what is required for innovation - people who push the technology at the edges.

    PJ Murray
    CodeFutures: Code Generation for Java Persistence
  151. I believe there is a general anti-JSR mood in some areas... I think it is a very interesting aspect of the 'Java Community'.
    I think that's healthy. There has to be a balance between what is needed by enterprises - reliable specifications and standards - and what is required for innovation - people who push the technology at the edges.

    +1... It's a healthy symbiosis ;-)
  152. Oh great[ Go to top ]

    Wow. Up until about message #197821 we were actually having a productive technical discussion about the percieved and real technical flaws and advantages of JSF. As adults.

    Then along comes Cameron with his 100%-technical-content-free (and wrong-on-history) ad hominem attack against Craig, and this thread turns into the usual TSS fare.

    I really, really hate TSS.
  153. Oh great[ Go to top ]

    Wow. Up until about message #197821 we were actually having a productive technical discussion about the percieved and real technical flaws and advantages of JSF. As adults.Then along comes Cameron with his 100%-technical-content-free (and wrong-on-history) ad hominem attack against Craig, and this thread turns into the usual TSS fare.I really, really hate TSS.
    +1.

    The really funny thing is Cameron is well respected in the Java community and his company's products are very well recieved in the financial industry (according to his many posts). For such a public face of the company to loiter around in TSS making meaningless posts is really sad.
  154. Re: Oh great[ Go to top ]

    Wow. Up until about message #197821 we were actually having a productive technical discussion about the percieved and real technical flaws and advantages of JSF. As adults.Then along comes Cameron with his 100%-technical-content-free (and wrong-on-history) ad hominem attack against Craig, and this thread turns into the usual TSS fare.I really, really hate TSS.
    +1. The really funny thing is Cameron is well respected in the Java community and his company's products are very well recieved in the financial industry (according to his many posts). For such a public face of the company to loiter around in TSS making meaningless posts is really sad.

    Question: does that qualify as another ad hominem attack? ;-)
  155. Oh great[ Go to top ]

    Gavin:
    Wow. Up until about message #197821 we were actually having a productive technical discussion about the percieved and real technical flaws and advantages of JSF. As adults.

    Then along comes Cameron ..

    By "productive technical discussion", I assume you mean the message that I was replying to:
    My view is that there is much vocal resistance to JSF simply because it is a JSR specification, and there is a philosphical resistance to 'imposed' standards.

    Much as I respect Steve, I do not agree with him in this case, and felt that I should relay the reasons why.

    As for:
    .. his 100%-technical-content-free (and wrong-on-history) ad hominem attack against Craig ..

    Get over yourself. I wasn't attacking anyone.

    (BTW Your wording is an ad hominem attack against the latin language, but you won't likely understand the irony of this statement.)

    Furthermore, I wasn't trying to explain how I feel, since I do not develop with either Struts or JSF, (although what I've seen in terms of the complexity of Struts applications has certainly left a bad taste in my mouth.) I was trying to explain what I've heard, and it appears that I was successful, since one of the next comments was "I think this is exactly how "a lot of people" who have been burned by Struts feel."
    I really, really hate TSS.

    Be careful; I hear that hate leads to the dark side.

    Peace,

    Cameron Purdy
    Tangosol Coherence: The Java Data Grid
  156. Oh great[ Go to top ]

    Much as I respect Steve, I do not agree with him in this case, and felt that I should relay the reasons why.

    Actually, I didn't think I put my point across well. I should have said:

    "My view is that at least part of the vocal resistance to JSF may be simply because it is a JSR specification, and there is a philosphical resistance to 'imposed' standards."

    I did not mean to imply that I did not sympathise with at least some of the objections to JSF.

    Although I posted a somewhat flippant reply, I do seriously think that 'anti JSR bias' is a significant matter, as it can help to obscure attempts at clear technical debates. I often see 'JCP' generally (and therefore, falsely) associated with the ideas 'proprietary' and 'closed source'. Because of this, I think that there is at least some resistance from some developers to an API simply because it is a JSR; in the same way that there may be resistance to use of Microsoft products for political/philosophical reasons. This is certainly not limited to JSF.

    Of course, when I say 'JSR bias', I am not excluding myself - as I admit I am pro-specifications (I was going to say 'pro-standards', but have been reprimanded on earlier threads for using this word) prejudice, and so probably fail to be objective.
  157. Oh great[ Go to top ]

    Get over yourself. I wasn't attacking anyone.

    Oh not at all. So you did not type this then:
    So basically, this "large vocal group of people" recognizes someone who should not have been allowed near a keyboard in the first place, someone who they believe foisted a strutting abomination on a large number of unsuspecting and well-intentioned developers (who have all subsequently committed suicide or at least suffered from carpal tunnel syndrome), and realize that -- instead of putting said person in jail -- Sun endorses and standardizes his/her Frankensteinian 2.0 effort.

    Cameron, if you don't have something positive to contribute, don't contribute. That rant would have been much better left unranted.
    (BTW Your wording is an ad hominem attack against the latin language, but you won't likely understand the irony of this statement.)

    Presumably I should have written "attack ad hominem", but I don't know latin grammar and don't very much care.

    http://dictionary.reference.com/search?q=pedant
    Furthermore, I wasn't trying to explain how I feel, since I do not develop with either Struts or JSF, (although what I've seen in terms of the complexity of Struts applications has certainly left a bad taste in my mouth.)


    FYI, I am also not a fan of Struts. JSF is not Struts. In fact, JSF is nothing at all like Struts. But it's nice to hear you admit you don't know JSF very well.
    Be careful; I hear that hate leads to the dark side.

    I was under the impression that I had been swallowed up by The Dark Side the minute I joined JBoss :-)
  158. Oh great[ Go to top ]

    Hi Gavin,
    Cameron, if you don't have something positive to contribute, don't contribute. That rant would have been much better left unranted.

    Unfortunately, it appears that you are right and I was wrong. The post did not communicate my point well, and based on peoples' perception of what was said, it would have been better not being said. I could have much more effectively made a response to Steve's assertion (which I believe to be erroneous) had I not appeared to be attacking someone / something. Trust me, it was not my intent.
    FYI, I am also not a fan of Struts. JSF is not Struts. In fact, JSF is nothing at all like Struts. But it's nice to hear you admit you don't know JSF very well.

    The reason I was reading the thread was to gain more understanding of JSF. It's hard to keep up with all of the various technologies, and since I don't often get to _build_ applications, it's hard for me to appreciate the differences among the various frameworks (Tapestry, JSF, Struts, WebWork, Rife, Wicket, ....)

    (As an aside, Simon Brown has been comparing web frameworks on his blog, and Matt Raible does a presentation comparing various web frameworks for various speaking venues, including JIA and NFJS IIRC.)

    Regarding Struts, I do have a bad taste in my mouth _about_ Struts, just from seeing applications built with it and knowing that they should have had 90% less code (perhaps if they had they had a better framework). Not having been the architect on these projects, I cannot honestly say whether it is "Strut's fault" or the fault of the teams that implemented the applications or the design that they were working from.
    Be careful; I hear that hate leads to the dark side.

    I was under the impression that I had been swallowed up by The Dark Side the minute I joined JBoss :-)

    Keep the sense of humor, and you'll be fine ;-)

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  159. Oh great[ Go to top ]

    Not having been the architect on these projects, I cannot honestly say whether it is "Strut's fault" or the fault of the teams that implemented the applications or the design that they were working from.
    Having been on and seen a few Struts apps, I would go with "E: All of the above."
  160. +1

    This is right on the money!! Nice one.
  161. +1 This is right on the money!!

    Nice one.

    Digital High Five to you Chris.... anything to add other than more exclamation points?
  162. Digital High Five to you Chris.... anything to add other than more exclamation points?

    I didn't realise that agreeing with another post, admittedly with some enthusiasm, warranted such a reply. Unfortunately coming in at the end of a long discussion most points have already been made and one has little choice but to agree or repeat. I did choose the former easier option. Let me try and get into the spirit of things here... 'in the future I will try and act a little more subdued and keep to a minimum the posts that I agree with but which I have nothing further to add.' ;)

    On a more positive note I like what you've done with Facelets, it has made JSF much more approachable by bringing a much needed templating alternative to JSPs and taglibs. We've enjoyed our own in house templating architecture based on XMLC for the last six years. I'm not sure if Facelets is enough to convince me to use JSF which seems to be a little more brain damaged than other current alternatives such as Tapestry and Wicket, please excuse the lack of technical support for this comment, but hopefully after some more investigation I will have a better idea.

    As Cameron says, peace.
  163. I keep seeing people flaming JSF maybe because it is supported by a standard who knows. But I rarely technical or design arguments justifying their opinion, seems more like a philosophical issue. A lot of FUD is spread around JSF right now. I have used it for some times now and I must say I like it. There are some issues but overall I enjoys developping it espcially compare to Struts.
    I absolutely agree - I think you have got things exactly right. My view is that there is much vocal resistance to JSF simply because it is a JSR specification, and there is a philosphical resistance to 'imposed' standards.

    The reason why people are not happy with JSF is the fact that is not better than the other frameworks. Yes, you can say that it is only 1.x version, and that you should not expect the world from the first spec/implementation take.

    But it is not the first take. They should have learnt from the already existing frameworks, and built on top of it. There is no excuse for coming out with a spec (and implementation) that is inferior to an existing framework. And I do not mean bugs here, bugs are allowed; but design flaws are something different.
  164. When you say "there are some issues, i.e. detecting postbacks, but it was nothing compared to alternatives.", which alternatives did you explore? How deeply?
    We (major European manufacturing company) are currently finalizing very important application using JSF (MyFaces) and JBoss EJB3. And, once we learned it, it was real pleasure using JSF. Of course, there are some issues, i.e. detecting postbacks, but it was nothing compared to alternatives. Actually, most annoying thing was inability to use lazy relations transparently, but that was not an JSF issue but EJB3 issue. And there is Seam now.So, I believe that most of the negative comments from community are coming just because of the inertia. People approach it with arrogance (oh, I know this, must be like .NET/Struts/<arbitrary_web_framework>) without trying to really understand/learn how this stuff works. And then, they are frustrated that their natural intelligence can not compensate for the lack of information. On the end, it is much easier to say that something sucks than to admit that you were too lazy to go through documentation/samples.
  165. When you say "there are some issues, i.e. detecting postbacks, but it was nothing compared to alternatives.", which alternatives did you explore? How deeply?
    We (major European manufacturing company) are currently finalizing very important application using JSF (MyFaces) and JBoss EJB3. And, once we learned it, it was real pleasure using JSF. Of course, there are some issues, i.e. detecting postbacks, but it was nothing compared to alternatives. Actually, most annoying thing was inability to use lazy relations transparently, but that was not an JSF issue but EJB3 issue. And there is Seam now.So, I believe that most of the negative comments from community are coming just because of the inertia. People approach it with arrogance (oh, I know this, must be like .NET/Struts/<arbitrary_web_framework>) without trying to really understand/learn how this stuff works. And then, they are frustrated that their natural intelligence can not compensate for the lack of information. On the end, it is much easier to say that something sucks than to admit that you were too lazy to go through documentation/samples.

    I ment alternative technologies and issues that they have. i.e. ASP.NET.
  166. +1

    I agree with you. I had the same problem as author of this but I find solution which initializes bean from GET parameters in faces-config.xml. It took some time but I read a lot of documentation and get deeper understanding of JSF.
  167. Pertaining to Restful state issues with JSF, read:

    http://weblogs.java.net/blog/jhook/archive/2006/01/experiment_goin_1.html

    Maybe one can complain about the JSF lifecycle, but in reality, there's a lot of good pieces in there that can be tweaked in the future.

    And you can't necessarily blame JSF for stateful issues-- everyone has problems with things like open session/transaction in view with working in any session-scoped data, no matter what framework.

    -- Jacob
  168. Tim Shadel should try the Taco Supreme![ Go to top ]

    I've used JSF and have had no problems. There are ways to do what you need, you just have to research. Thats true with anything newish. I have the feeling that Mr. Shadel is just a Blog and Quote type. I wonder if he's really dug deep, or just found something to latch on to so he can blog or podcast about and whine alittle?!?
  169. Tim Shadel should try the Taco Supreme![ Go to top ]

    I've used JSF and have had no problems. There are ways to do what you need, you just have to research. Thats true with anything newish. I have the feeling that Mr. Shadel is just a Blog and Quote type. I wonder if he's really dug deep, or just found something to latch on to so he can blog or podcast about and whine alittle?!?

    If you would have bothered to listen to the podcast, you would have learned Tim had just finished using JSF for 9 months or so in several projects, but I guess you are just one of those people that found something to latch on to so you can comment and whine a little...
  170. sure[ Go to top ]

    I did, and I still stand by my opinion, but thanks for yours.
  171. I've used JSF and have had no problems. There are ways to do what you need, you just have to research. Thats true with anything newish. I have the feeling that Mr. Shadel is just a Blog and Quote type. I wonder if he's really dug deep, or just found something to latch on to so he can blog or podcast about and whine alittle?!?
    If you would have bothered to listen to the podcast, you would have learned Tim had just finished using JSF for 9 months or so in several projects, but I guess you are just one of those people that found something to latch on to so you can comment and whine a little...

    Well, I also hate eating fish, although I tried it many times! No good - yuck! The difference is that I won't publish that fact on CNN and expect that rest 6 billion blindly agree with me. though if they would, it could have huge positive impact on ocean ecosystems!

    The problem is not author's personal opinion. The problem is author's PUBLIC opinion. I would assume that he wouldn't make it public if he expected that everyone would agree, would he?

    I am just trying to point out that his generalizations are narrow and that there are different opinions which are also based on experience. That's all!
  172. Well, I also hate eating fish, although I tried it many times! No good - yuck! The difference is that I won't publish that fact on CNN and expect that rest 6 billion blindly agree with me. though if they would, it could have huge positive impact on ocean ecosystems!The problem is not author's personal opinion. The problem is author's PUBLIC opinion. I would assume that he wouldn't make it public if he expected that everyone would agree, would he?I am just trying to point out that his generalizations are narrow and that there are different opinions which are also based on experience. That's all!

    This is his blog. No one is requiring, or even expecting, you to agree with everything you read on a blog. A blog is someone's opinion, pure and simple. Criticizing someone for expressing their opinion on their own blog seems to miss the point.
  173. Well, I also hate eating fish, although I tried it many times! No good - yuck! The difference is that I won't publish that fact on CNN and expect that rest 6 billion blindly agree with me. though if they would, it could have huge positive impact on ocean ecosystems!The problem is not author's personal opinion. The problem is author's PUBLIC opinion. I would assume that he wouldn't make it public if he expected that everyone would agree, would he?I am just trying to point out that his generalizations are narrow and that there are different opinions which are also based on experience. That's all!
    This is his blog. No one is requiring, or even expecting, you to agree with everything you read on a blog. A blog is someone's opinion, pure and simple. Criticizing someone for expressing their opinion on their own blog seems to miss the point.

    Well, I couldn't agree more with you! Only, if it stayed his blog and was not published on the TSS...
  174. Well, I couldn't agree more with you! Only, if it stayed his blog and was not published on the TSS...

    Well, that was a decision by the TSS staff, so don't knock this guy and his blog... I think it was a good decision... Just look at the interesting debates it's sparked already :-)
  175. Well, I couldn't agree more with you! Only, if it stayed his blog and was not published on the TSS...
    Well, that was a decision by the TSS staff, so don't knock this guy and his blog... I think it was a good decision... Just look at the interesting debates it's sparked already :-)

    :o)

    At least, It seems that benefits of his post on TSS will exceed the benefits of the content of his post, that's for sure! ;-)

    But really, you just need a little bit of eloquence and capability of logical thinking and there you are! You could trash anything in the world! In Sweden is too rainy; in Mauritius you can catch malaria; when it's cloudy it's depressive; when it's sunny you can get skin cancer...
    Nothing is perfect, that's clear!

    Have fun!
    Vlada
  176. Tim Shadel should try the Taco Supreme![ Go to top ]

    I've used JSF and have had no problems. There are ways to do what you need, you just have to research. Thats true with anything newish. I have the feeling that Mr. Shadel is just a Blog and Quote type. I wonder if he's really dug deep, or just found something to latch on to so he can blog or podcast about and whine alittle?!?
    If you would have bothered to listen to the podcast, you would have learned Tim had just finished using JSF for 9 months or so in several projects, but I guess you are just one of those people that found something to latch on to so you can comment and whine a little...

    Just because he used it for 9 months or in so many projects doesn't mean he knows how to use every aspect of it, effectively. The same goes for anyone on anything.
  177. I don´t know what is happening but this type of POST is becomming very constant in the last few months and I have an strong opinion about JSF, it´s a new technology, a new approach in web development to the JEE community and every java developer need to LEARN before kick it. I was working with JSF about a year and I LIKE IT!!! Yes there are problems with the specification but many of the issues are being resolved in the 1.2 release. All the problems that I found have an workaround LIKE ANY OTHER FRAMEWORK!!!
    I think that many of the rejection on JSF is because IT IS VERY CLOSE TO ASP.NET and people don´t like MS, but good things need to be used and MS do a great job on the ASP.NET IMHO.
    If you don´t like JSF don´t use it, but don´t try discourage other people that want to learn a new technology.

    Sorry for my poor english...
  178. JSF IDE[ Go to top ]

    I think the true power of JSF lies in the ability for IDE's to provide drag and drop functionality. That said, once major players start developing IDE's with true JSF support, the framework should catch much more momentum.

    So for most developers, the laziness of learning a new framework would be eliminated and replaced with a drag and drop solution to reusable components. This of course all depends on how sophisticated the JSF support would be in the IDE's.
  179. Who cares about HTTP semantics?[ Go to top ]

    AJAX could be dismissed also for not making easy to use URLs, and very few people complaint about it. GMail is not bookmarkable, and it is one of the paradigms of a good Internet application.

    Although the author says he was developing internal applications, he keeps on putting out Internet examples (Google, del.icio.us). The podcast ellaborates about the importance of links, HTTP, URL, REST and web resources. Something about which typical business users are not worried about at all; they just demand that the application works. "This application does not respect the HTTP semantics" does not sound like an argument to a business executive. Web applications are still applications which are supposed to perform useful functions, regardless of whether you can bookmark its state or not. We should think in user terms, not in technological terms.

    The author describes how they had to hyperlink two different web applications, and how they had to resort to what he calls "a hack", and that many other people would call just "a workaround". If they are so purist that using such "hack" offends them more than losing the power of a component-based framework, good for them - this alone is not enough for me. The productivity gains seem much more relevant to me that the purity of the HTTP GET semantics. And at any rate, the promise of component based development is well worth of proposing enhancements to the framework to support GET for simple states, instead of throwing it all away. These "7 burrito layers" are pluggable, I think.

    JSF has, for more than 3 years, proven unable to achieve enough popularity. 2006 will be its year: either it will be a success, or a definitive failure. It is not that it has to succeed even if proves not good enough, but I hope it is, because experience has shown that using components is the best way to build user interfaces, and web applications are not an exception to this. And if the Java world is unable to produce such a framework that is popular to the majority of developers, it will be a shameful failure. And I think it would have more to do with cultural barriers, than with technological ones.
  180. Strange[ Go to top ]

    It is a little bizarre to see in the browsers site bar the URL to a view JSP but be presented content from a completely different view JSP. It just seems that some unwritten fundamental rule of web application design has been violated :)

    My beef with JSF is that it doesn't define a security model and there is not a per page view load event.

    The only way I found out how to enforce user authentication outside J2EE container security was to build a custom phase listener and enforce authentication there. I didn't think it was a clean solution and since every web application needs authentication it should be clearly defined in the JSF spec.

    Also it is difficult to build custom navigation logic on a per view bases before the view is rendered. While navigation based on user events is clearly defined, once a view is selected there is no easy way to forward to a different view if certain conditions were not met.

    I believe both of these concerns are suppose to be addressed in JSF 1.2 so I guess I will wait and see.
  181. Strange[ Go to top ]

    It is a little bizarre to see in the browsers site bar the URL to a view JSP but be presented content from a completely different view JSP. It just seems that some unwritten fundamental rule of web application design has been violated :)
    Have you tried using <redirect/> tag in the navigation config file?
  182. Strange[ Go to top ]

    For a MyFaces application I used acegi security managed by the Spring framework to secure it. A perfect match. Much more flexible than any EJB security I used before.
  183. Who cares about HTTP semantics?[ Go to top ]

    AJAX could be dismissed also for not making easy to use URLs, and very few people complaint about it. GMail is not bookmarkable, and it is one of the paradigms of a good Internet application.Although the author says he was developing internal applications, he keeps on putting out Internet examples (Google, del.icio.us). The podcast ellaborates about the importance of links, HTTP, URL, REST and web resources. Something about which typical business users are not worried about at all; they just demand that the application works. "This application does not respect the HTTP semantics" does not sound like an argument to a business executive. Web applications are still applications which are supposed to perform useful functions, regardless of whether you can bookmark its state or not. We should think in user terms, not in technological terms.The author describes how they had to hyperlink two different web applications, and how they had to resort to what he calls "a hack", and that many other people would call just "a workaround". If they are so purist that using such "hack" offends them more than losing the power of a component-based framework, good for them - this alone is not enough for me. The productivity gains seem much more relevant to me that the purity of the HTTP GET semantics. And at any rate, the promise of component based development is well worth of proposing enhancements to the framework to support GET for simple states, instead of throwing it all away. These "7 burrito layers" are pluggable, I think.JSF has, for more than 3 years, proven unable to achieve enough popularity. 2006 will be its year: either it will be a success, or a definitive failure. It is not that it has to succeed even if proves not good enough, but I hope it is, because experience has shown that using components is the best way to build user interfaces, and web applications are not an exception to this. And if the Java world is unable to produce such a framework that is popular to the majority of developers, it will be a shameful failure. And I think it would have more to do with cultural barriers, than with technological ones.

    +1

    Not to mention that, in internal business applications, bookmarking pages is exactly what I would rather like prevent. (at least in the most of use-cases I can think of)
    I am trying to imagine posting typical Power Substation Sales Configurator page using GET... That would be veeery looong URL! ;-) Oh, and there is nightmare of duplicate posts, too...
  184. Who cares about HTTP semantics?[ Go to top ]

    "The podcast ellaborates about the importance of links, HTTP, URL, REST and web resources. Something about which typical business users are not worried about at all; they just demand that the application works."

    "This application does not respect the HTTP semantics" does not sound like an argument to a business executive."

    I beg to differ. While many users and executives don't understand these technical details, they *do* want to be able to do things like:

    * Bookmark an item on Amazon.com
    * Bookmark their eBay auction
    * Bookmark an order confirmation page
    * Send a link to a blog post or news article via email

    That's not to say that POST-only frameworks couldn't support 'bookmarkable items' without GET. I'm not really familiar with JSF. Does it have no support for such a thing?
  185. Who cares about HTTP semantics?[ Go to top ]

    "The podcast ellaborates about the importance of links, HTTP, URL, REST and web resources. Something about which typical business users are not worried about at all; they just demand that the application works.""This application does not respect the HTTP semantics" does not sound like an argument to a business executive."I beg to differ. While many users and executives don't understand these technical details, they *do* want to be able to do things like:* Bookmark an item on Amazon.com* Bookmark their eBay auction* Bookmark an order confirmation page* Send a link to a blog post or news article via emailThat's not to say that POST-only frameworks couldn't support 'bookmarkable items' without GET. I'm not really familiar with JSF. Does it have no support for such a thing?

    Yes, JSF does not block it, it just is that the standard form method is post, but you still are able to set parametrized links, which is basically the same as a get.
    Nothing theoretically would prevent you to implement the same logic as the normal jsf forms does with gets, but the fact that there already exist hundreds of controls and no one ever has done it seems to be indication enough that it is not really top priority, because you have static links.
    A form get is a case which does not happen too often, and in most cases is neglectable.
    A paramterized link can happen often, and is covered by jsf as mentioned before.
  186. Who cares about HTTP semantics?[ Go to top ]

    The productivity gains seem much more relevant to me that the purity of the HTTP GET semantics.

    Do you have numbers which back up claims of productivity gains? Over what?
    It is not that it has to succeed even if proves not good enough, but I hope it is, because experience has shown that using components is the best way to build user interfaces, and web applications are not an exception to this.

    Who's experiences? Lots of people disagree with you, me included. At least when you use the term "components" to mean the way JSF manages a big lifecycle and interactions between all of the moving pieces in JSF.
  187. Who cares about HTTP semantics?[ Go to top ]

    JSF has, for more than 3 years, proven unable to achieve enough popularity.

    JSF has not been out that long as a finalized JSR. The final release was 11 March 2004. Many of us are not keen to use things in production use before this stage.

    Also, what evidence is there about poor JSF popularity? I have no good way to measure this, except I do see a number of companies investing in JSF components and marketing them, and an increasing number of job offers for JSF developers. I see Oracle donating over a hundred JSF components to open source. I see JSF and JSF-based libraries being highly rated by surveys (OK, these surveys may be questionable, there seems to be a pattern).

    I guess JSF success stories aren't as exciting as stories as failures!
  188. Who cares about HTTP semantics?[ Go to top ]

    JSF has, for more than 3 years, proven unable to achieve enough popularity.
    JSF has not been out that long as a finalized JSR. The final release was 11 March 2004. Many of us are not keen to use things in production use before this stage.Also, what evidence is there about poor JSF popularity? I have no good way to measure this, except I do see a number of companies investing in JSF components and marketing them, and an increasing number of job offers for JSF developers. I see Oracle donating over a hundred JSF components to open source. I see JSF and JSF-based libraries being highly rated by surveys (OK, these surveys may be questionable, there seems to be a pattern). I guess JSF success stories aren't as exciting as stories as failures!

    Add to that myriads of components (Around 40-50 in tomahwak alone) for JSF freely available from the net, besides myfaces several other open source dedicated component projects. Add to that several commercial component packs and at least three implementations of the standard (Sun, IBM, MyFaces)
    Add to that several excellent extension frameworks, like Shale, Seam and even Spring has some extension points into JSF and that basically every tool builder already has a working or semi working JSF support in its tools, or plans to add it.

    Everything seems to indicate that JSF has gained huge momentum the last year, no sign for a slow adoption, giving the short timeframe JSF now has been finalized in its 1.o incarnation.
  189. I agree[ Go to top ]

    I agree. Having the custom components, or components from other vendors, you can develop your apps very fast. You can also sell your own components, and fill the need of others. It makes JSF marketable and it increases the progress and inovation.
  190. AJAX is different[ Go to top ]

    AJAX is different at least as I understand it. I think AJAX makes possible to move complex applications like a calendar, spreadsheet or word processor which are now working on a desktop, to a web browser. In MVC model you completely move a view from a server to a client and use HTTP to work with a controller and model.

    In case of JSF I think the author of this post is wrong. JSF doens't say that you have to use JSF in every piece of your application. JSF is good thing when you want to create a complex UI (in this sense it is very similar to AJAX), but when you create some pages that creates rather static view of JSP it doens't prevent you from using simple servlets and JSPs. And even with JSFs you can use parameters in urls. You don't have to make all links work through a JSF page layout. They are created to make processes that involves several steps like a user registration, shop ordering or setup wizard easier to work with.
  191. Philisophical Differences[ Go to top ]

    I have followed JSF much more closely than I would otherwise, precisely because it is a JSR standard. I would prefer to use a web framework that has broad vendor support and competing implementations.

    But some of the most damning quotes come from the linked David Geary article.

    "I don't think that one of JSF's top priorities is to simplify Web development."

    "JSF was designed primarily for use with tools."

    "I'm not sure that spending a few days [developing in JSF] is really enough to allow someone to recommend one framework over another."

    "Testability is another area that could use some improvement."


    He also adds some qualifiers, but these quotes seem to accurately reflect his core position.

    If you're going to design a new Web framework, it seems that you can appeal to either of these two camps of developers:

    1) Developers who are happy with the functionality of Struts, but would like something easier and faster to work with. Something you can just pick up and be productive with immediately. Simpler to develop with, and simpler to test.

    2) Developers who want, first and foremost, more powerful functionality out of their web framework. They are willing to add complexity, develop their own set of helper libraries, invest in specialized toolsets, and sacrifice testability to get the most powerful, extensible framework available. A few days of developing with the framework may be frustrating, but after a few months of experience it won't seem so difficult to work with.

    Mr. Geary and his associates have clearly put all their eggs in the #2 basket. This does not seem to be a winning proposition. They seem to be ignoring the fact that frameworks like Spring, Hibernate, and, yes, even EJB3 have gotten a lot of traction with developers by appealing to the #1 mindset.
  192. Funny, I had no trouble creating links, appending parameters to it and processing those parameters on the other side. It was really quite easy. Not sure where the difficulty is on this one. Maybe he got sandboxed by the defaults of a gui.
  193. GET works in JSF as well[ Go to top ]

    "JSF uses POST" sounds like "JSF does not work with GET". However, it does not true. It is possibe to replace POST with GET and the rest stuff will work the same way. Of course, GET does not allow to send as much data as POST does. It is a browser limitation, but not the JSF fault.

    --
    Sergey : jsfTutorials.net
  194. Well, I also hate eating fish, although I tried it many times! No good - yuck! The difference is that I won't publish that fact on CNN and expect that rest 6 billion blindly agree with me. though if they would, it could have huge positive impact on ocean ecosystems!

    The problem is not author's personal opinion. The problem is author's PUBLIC opinion. I would assume that he wouldn't make it public if he expected that everyone would agree, would he?

    I am just trying to point out that his generalizations are narrow and that there are different opinions which are also
    based on experience. That's all!
    +1
  195. Tapestry?[ Go to top ]

    Did anyone in the JSF community explain why Tapestry was adopted and improved? Why reinvent the wheel?
  196. Tapestry?[ Go to top ]

    Did anyone in the JSF community explain why Tapestry was adopted and improved? Why reinvent the wheel?

    JSF is different from Tapestry in many ways. Tapestry is HTML. JSF is a general server-side GUI system, and has been used to render a range of presentation mechanisms, not just HTML.
  197. Tapestry?[ Go to top ]

    JSF is different from Tapestry in many ways. Tapestry is HTML. JSF is a general server-side GUI system, and has been used to render a range of presentation mechanisms, not just HTML.

    Actually, this is not the reason at all. Tapestry could relative easily be modified to support that feature if it was requested. In fact, it is not hard at all to plug in something like that with HiveMind. The matter is just not requested and is not deemed necessary as a result.

    If there is any "incompatibility", it is in the handling of the request cycle, specifically the fully dynamic nature of JSF versus the combined static/dynamic nature of Tapestry. As you know, the ServerSide article on the topic discusses that that issue as well.

    There is also the little issue of details such as ease-of-use, error reporting, etc, but this is apparently more subjective than objective.
  198. Tapestry?[ Go to top ]

    JSF is different from Tapestry in many ways. Tapestry is HTML. JSF is a general server-side GUI system, and has been used to render a range of presentation mechanisms, not just HTML.
    Actually, this is not the reason at all.

    I am not sure I understand what you mean here. I was simply stating that JSF was most likely not a 'reinvention' of concepts introduced by Tapestry. They have different features, and both have been in development for a long time. (JSF was in development for years before the 'Final Draft').
    Tapestry could relative easily be modified to support that feature if it was requested. In fact, it is not hard at all to plug in something like that with HiveMind. The matter is just not requested and is not deemed necessary as a result.

    Well, there must have been some demand for it, as in the excellent Oracle JSF implementation all components can render HTML, WML and can even display on Telnet. JSF (being a specification, not a product) allows vendors to cater for such niches, whereas as single product may not have the resources to do so.

    Tapestry is a great product, but personally I find this particular aspect of JSF very exciting.
  199. Tapestry?[ Go to top ]

    Steve, you are talking about producers (tool-vendors) and I am talking about consumers (developers). The Tapestry mailing lists have tens of thousands of messages a year, and I can assure you that this feature is definitely not among the requested ones. If it becomes requested, well, it is easy to be added. But like Tapestry's HTML-only templates, this feature can be easily implemented in the other framework if it is required (just as Facelets implements it for JSF).

    What I am talking about in my message is that there are fundamental differences between two frameworks that cannot be bridged easily. For example, a loop with 100 iterations in Tapestry would generate one component that is invoked 100 times. If I am not mistaken, that same loop would generate 100 different components in JSF and then these components would be stored somewhere (in the session or on the client). This is a direct consequence of the dynamic vs. static approach of building pages that determines most of the core differences between the frameworks.

    I guess that in the short run, things like ease of use and general simplicity of the frameworks would make a difference. In the long run fundamental differences like the above would be decisive, as they cannot be resolved. And I believe this topic is about the long run prospects.
  200. Tapestry?[ Go to top ]

    Steve, you are talking about producers (tool-vendors) and I am talking about consumers (developers). The Tapestry mailing lists have tens of thousands of messages a year, and I can assure you that this feature is definitely not among the requested ones. If it becomes requested, well, it is easy to be added.

    I am assuming that producers produce based on demand. The point about JSF is that I know such features are already there. Just because it is not in demand for Tapestry does not mean it is not in demand. Tapestry is a highly successful framework that has been known from the start for providing ease of design of HTML pages, and I suppose it will therefore attract primarily HTML designers. From the start JSF has been pitched as a multi-presentation technology.

    The thing is, I am not after a product to which things can be potentially added if I request it. I am after features already present and tested and supported. I believe there are a lot of developers in my situation.
    For example, a loop with 100 iterations in Tapestry would generate one component that is invoked 100 times. If I am not mistaken, that same loop would generate 100 different components in JSF and then these components would be stored somewhere (in the session or on the client).

    I can't comment on this, as I don't know enough about this aspect of JSF.
  201. Tapestry?[ Go to top ]

    I am assuming that producers produce based on demand.

    Heh. I was drilled to believe that when I studied marketing. *Latent* demand they called it, which is very different from actual needs that live right now :)
  202. Tapestry?[ Go to top ]

    What I am talking about in my message is that there are fundamental differences between two frameworks that cannot be bridged easily. For example, a loop with 100 iterations in Tapestry would generate one component that is invoked 100 times. If I am not mistaken, that same loop would generate 100 different components in JSF and then these components would be stored somewhere (in the session or on the client). This is a direct consequence of the dynamic vs. static approach of building pages that determines most of the core differences between the frameworks.

    You are kind of correct-- JSF is two phased (faced) such that there is a build phase, then a render phase. The build phase is supported by things like direct Java, JSP, and Facelets whose only job is to construct a component tree. In the case of a build phase based iterator (which is sometimes required), you would end up with 100 components (ex c:forEach).

    If it was an interator 'component', then in the render phase, it would act like Tapestry/JSP and evaluate that component 100 times. I will spare the minor, ugly details of niche issues with this in JSF.

    The weight difference between JSF and Tapestry is that with Tapestry I believe you have more ability to assert static content, where in JSF, everything is dynamic and we have to do some magic hand waving to manage transient state in the component tree ala Facelets or JSP.
  203. One component at a time[ Go to top ]

    Hi there,

    what you say is wrong. Please don't talk about frameworks you haven't actually used or checked out.

    JSF will use exactly one component.

    + (as it seems to suggest that JSF is not widely used) the MyFaces mailing lists have around 4000 messages a year - not so far off from Tapestry, huh?

    regards,

    Martin
  204. One component at a time[ Go to top ]

    the MyFaces mailing lists have around 4000 messages a year - not so far off from Tapestry, huh?regards,Martin

    They have rather more than that. They are currently running at a rate of thousands a month. That would suggest more messages for just one implementation of JSF than for Tapestry.

    Whether this is a good measure of actual use is questionable, but I find it impressive nevertheless.
  205. Tapestry?[ Go to top ]

    It is not against JSF, but I am just interesting: what is useful in WML rendering? Do you expect to port existing application as is to the mobile? No way to be honest, the most important issue here is a form factor for the mobile (small screen in other words). You will need a different concept (design). So practically you need the special components for the mobile anyway (in my opinion/experience of course – we did a lot of WAP development).

    Dmitry
    http://www.servletsuite.com
  206. Tapestry?[ Go to top ]

    It is not against JSF, but I am just interesting: what is useful in WML rendering? Do you expect to port existing application as is to the mobile? No way to be honest, the most important issue here is a form factor for the mobile (small screen in other words). You will need a different concept (design). So practically you need the special components for the mobile anyway

    To me, the attraction is that you can use the same framework to develop such pages, and you can use familiar JSF components, with validation and event handling. You don't need special components. I don't honestly expect to be able to design 'technology portable' web pages, but I do expect to get considerable re-use of code between presentation technologies.
  207. Tapestry?[ Go to top ]

    It is not against JSF, but I am just interesting: what is useful in WML rendering? Do you expect to port existing application as is to the mobile? No way to be honest, the most important issue here is a form factor for the mobile (small screen in other words). You will need a different concept (design). So practically you need the special components for the mobile anyway

    The more interesting Renderkits I've seen (WML is not of interest to me), but the XUL (XUL Faces) and some of the *animation* work that Roger Kitain has demonstrated with SVG and JSF.
  208. Tapestry?[ Go to top ]

    It is not against JSF, but I am just interesting: what is useful in WML rendering? Do you expect to port existing application as is to the mobile? No way to be honest, the most important issue here is a form factor for the mobile (small screen in other words). You will need a different concept (design). So practically you need the special components for the mobile anyway
    To me, the attraction is that you can use the same framework to develop such pages, and you can use familiar JSF components, with validation and event handling. You don't need special components. I don't honestly expect to be able to design 'technology portable' web pages, but I do expect to get considerable re-use of code between presentation technologies.

    Explain. For example, with our Struts, Spring, Hibernate series of code, I've successfully pulled validation from the presentation tier. My domain objects are persisted using Hibenate and is injected into both ActionForm and business tier using Spring. In fact, validation is an interface(DataValidator) that is injected into the domain object. I use Struts' validate method to invoke the domain object's validator, but it is complete decoupled from Struts.

    I can use the validation even outside the presentation tier. So the reuse is there.

    If JSF doesn't offer the ability to easily move from say PDF to HTML to WML by just changing implemenation, why use it?
  209. Tapestry?[ Go to top ]

    To me, the attraction is that you can use the same framework to develop such pages, and you can use familiar JSF components, with validation and event handling. You don't need special components. I don't honestly expect to be able to design 'technology portable' web pages, but I do expect to get considerable re-use of code between presentation technologies.Explain. For example, with our Struts, Spring, Hibernate series of code, I've successfully pulled validation from the presentation tier. My domain objects are persisted using Hibenate and is injected into both ActionForm and business tier using Spring. In fact, validation is an interface(DataValidator) that is injected into the domain object. I use Struts' validate method to invoke the domain object's validator, but it is complete decoupled from Struts.I can use the validation even outside the presentation tier. So the reuse is there.If JSF doesn't offer the ability to easily move from say PDF to HTML to WML by just changing implemenation, why use it?Vendors' pressure (they don't want to dump money to create different tools for different frameworks, they want one standard)? Tool support? Viewstate? Validation/conversion? Components, after all? For the last one I have an answer: it is possible to create components with pure JSP as well.

    ---
    Michael Jouravlev
    JSP ControlsBuild independent page components with JSP
  210. Tapestry?[ Go to top ]

    If JSF doesn't offer the ability to easily move from say PDF to HTML to WML by just changing implementation, why use it?

    Because it does offer this. You can do this without changing implementation. UI Components can determine the appropriate rendering technology at runtime. It would be possible in principle to have a page that detected the client rendering method and based on that conditionally included or excluded mark-up and then allowed the components to render appropriately. Even if you did not want this level of dynamic portability of your web pages, you would - by choosing a good JSF implementation - have a set of tested components that you knew you could use with confidence for different types of client, without losing the ability to design high-quality pages for each rendering type.
    Vendors' pressure (they don't want to dump money to create different tools for different frameworks, they want one standard)? Tool support? Viewstate? Validation/conversion? Components, after all?

    I don't understand this 'Vendor's pressure' argument. I am a developer, and I want this sort of support. I want multiple implementations of an API; I want alternative, competing offerings. This gives me a feeling of security and confidence.
    For the last one I have an answer: it is possible to create components with pure JSP as well

    Supposing I don't want to use JSP? Also, there is the question of why I should bother to use JSP components when there are already a number of quality JSF components, both free and commercial, ready for me to use? I am great believer in convenience.
  211. Tapestry?[ Go to top ]

    I don't understand this 'Vendor's pressure' argument. I am a developer, and I want this sort of support. I want multiple implementations of an API; I want alternative, competing offerings.

    That's funny, what do you call oracle's appserver? Do you know how many engineers are employed by oracle? I'm sure with a company that large they can afford to more or less "blow their wad" at every technology that comes out and hope something sticks ;)

    Sorry, I was going to say anything until the argument kept going..and going.
  212. Tapestry?[ Go to top ]

    It is not against JSF, but I am just interesting: what is useful in WML rendering? Do you expect to port existing application as is to the mobile? No way to be honest, the most important issue here is a form factor for the mobile (small screen in other words). You will need a different concept (design). So practically you need the special components for the mobile anyway (in my opinion/experience of course – we did a lot of WAP development).Dmitryhttp://www.servletsuite.com
    It is less that you can switch on the fly, which in my opinion is a theoretical option, it is more that you get a huge code reuse that way, because you work with the same backend code and basically the same tag code just altered to the format needed, if done right.
  213. Tapestry? isn't just HTML[ Go to top ]

    Saying that Tapestry is just HTML isn't accurate. You can use Tapestry to render any kind of markup you want. For example, I've used it successfully to create VoiceXML applications and WML components are included right out of the box. That said, it is true that Tapestry's first order of business is HTML, but it is fully capable of rendering any other markup.

    To me JSF's renderkit looks good on paper, but I find it difficult to believe that you can create an effective GUI on a completely different platform simply by changing out the way a component is rendered. Each platform is simply different and may call into question the actual components involved, not just they way they are rendered, in order to get the best user experience.
  214. Tapestry? isn't just HTML[ Go to top ]

    Saying that Tapestry is just HTML isn't accurate. You can use Tapestry to render any kind of markup you want. For example, I've used it successfully to create VoiceXML applications and WML components are included right out of the box. That said, it is true that Tapestry's first order of business is HTML, but it is fully capable of rendering any other markup.

    Is it? From the Tapestry website:

    "Developing Tapestry applications involves creating HTML templates using plain HTML,"

    Even if it is, then as you say, Tapestry's first order of business is HTML. JSF was designed from the start for flexibility. This may not appeal to some developers, but it appeals a lot to me. I like the 'value add' of JSF, where you can get a library of components with alternative renderings available, and where many vendors and groups are working to add even more value, both by designing new components and by extending what existing components can do. I think the potential value (to both developers and vendors) of this increasing 'component market' is not yet widely realised.
    To me JSF's renderkit looks good on paper, but I find it difficult to believe that you can create an effective GUI on a completely different platform simply by changing out the way a component is rendered. Each platform is simply different and may call into question the actual components involved, not just they way they are rendered, in order to get the best user experience.

    Exactly, but I don't think anyone is saying that a single set of page designs will be effective for a range of presentation technologies. I think the advantage is that you can use the same techniques and the same components for these different technologies; and, I am sure that there can be considerable code re-use both within and behind the presentation layer.
  215. Tapestry? isn't just HTML[ Go to top ]

    Saying that Tapestry is just HTML isn't accurate. You can use Tapestry to render any kind of markup you want. For example, I've used it successfully to create VoiceXML applications and WML components are included right out of the box. That said, it is true that Tapestry's first order of business is HTML, but it is fully capable of rendering any other markup.
    Is it? From the Tapestry website:"Developing Tapestry applications involves creating HTML templates using plain HTML,"Even if it is, then as you say, Tapestry's first order of business is HTML. JSF was designed from the start for flexibility. This may not appeal to some developers, but it appeals a lot to me. I like the 'value add' of JSF, where you can get a library of components with alternative renderings available, and where many vendors and groups are working to add even more value, both by designing new components and by extending what existing components can do. I think the potential value (to both developers and vendors) of this increasing 'component market' is not yet widely realised.

    Tapestry's website may say that but you can generate any kind of markup with Tapestry. It doesn't force anything on you. Now, the default component set may be HTML focused, but Mindbridge already explained that, no one is interested in anything but HTML components. That said, I generate XML documents with Tapestry right now. And it comes with WML components out of the box. So I'm not sure where you're getting this the idea that Tapestry isn't designed for flexibility from the start.
  216. Tapestry? isn't just HTML[ Go to top ]

    And it comes with WML components out of the box. So I'm not sure where you're getting this the idea that Tapestry isn't designed for flexibility from the start.

    I tend to go by what the developers of a product say about their product on their website! No matter what a product can do, if the developers say its is primarily for one approach, I take them at their word. Tapestry is primarily for HTML (yes, and WML) pages. However take a look at the documentation - you use different components for these different rendering technologies. This is not the flexibility of JSF where you use the same components which can determine the renderkit to use dynamically at run-time, and you can have significant code re-use - even of the web page text.
  217. Tapestry? isn't just HTML[ Go to top ]

    I think the potential value (to both developers and vendors) of this increasing 'component
    >market' is not yet widely realised.

    That is because (IMHO again) the creation of components is not so easy in JSF

    Marina
    Coldbeans
  218. Tapestry? isn't just HTML[ Go to top ]

    >I think the potential value (to both developers and vendors) of this increasing 'component >market' is not yet widely realised.That is because (IMHO again) the creation of components is not so easy in JSFMarinaColdbeans

    This is a fair point, although it has not stopped many companies and groups developing components.
  219. Tapestry? isn't just HTML[ Go to top ]

    I think component development doe's not need to be simple, move "complex" stuff to component to reuse it in an easy way. So I think standard component model must solve reusability and integration issues first and it must not force component user to use component model, specific architecture or dogma (I think this stuff must be interesting for component providers only).
  220. Tapestry? isn't just HTML[ Go to top ]

    I think component development doe's not need to be simple, move "complex" stuff to component to reuse it in an easy way. So I think standard component model must solve reusability and integration issues first and it must not force component user to use component model, specific architecture or dogma (I think this stuff must be interesting for component providers only).

    That depends on how you develop applications I guess. I think it is extremely valuable to be able to create custom components easily. Not only is it easier to force consistency throughout your applications that way, but it can also save you from a lot of copy 'n paste code (e.g. the same parameterization over and over again). And if you have the mind set for it, there are usually a lot of things you can re-use even within the same project (e.g. customer search and result panels).
  221. Tapestry? isn't just HTML[ Go to top ]

    >I think the potential value (to both developers and vendors) of this increasing 'component >market' is not yet widely realised.That is because (IMHO again) the creation of components is not so easy in JSFMarinaColdbeans
    This is a fair point, although it has not stopped many companies and groups developing components.

    Yes the component API could be simpler, but it is managable, but for having a quick hack at a component which is project specific it is too complicated. Facelet and Shale Clay and others are more suitable for in project reuse components.

    But overall the API is managable and parts of the complexity stem from the fact, that it can do way more than simple html rendering, but there is lots of room for improvement in that area. But as a normal app programmer you should not be too concerned with the component programming API that should be a problem for the component programmers themselves, so it is not really that much of a problem.
  222. JSF is a general server-side GUI system, and has been used to render a range of presentation mechanisms, not just HTML.

    Remind you anything? EJB will be a universal silber bullet, all calls are remote (and slow like sh..t). Or, Swing will be a universal UI running on the all platforms, we will draw all UI elements on our own (but it's slow like shi.t and looks the same as it slow) :)

    I guess it's a common for all technologies from SUN and JCP, the super flexibility (and complexity) that will never ever be in use.
  223. JSF is a general server-side GUI system, and has been used to render a range of presentation mechanisms, not just HTML.
    Remind you anything? EJB will be a universal silber bullet, all calls are remote (and slow like sh..t). Or, Swing will be a universal UI running on the all platforms, we will draw all UI elements on our own (but it's slow like shi.t and looks the same as it slow) :)I guess it's a common for all technologies from SUN and JCP, the super flexibility (and complexity) that will never ever be in use.

    Bad examples.

    EJB, no matter what you and I may think of it, is in very wide use. Swing (according to Evans Data Corporation, and any quick browse of job sites) has recently become the one of the most in-demand technologies for (non-web) client-side development in the USA.

    I think this post backs my 'bias against JSR/JCP' theme.
  224. ....
    I think this post backs my 'bias against JSR/JCP' theme.

    So if i get you correctly,For you most people are just unreasonable over the merits of EJB<3 ?
  225. ....I think this post backs my 'bias against JSR/JCP' theme.
    So if i get you correctly,For you most people are just unreasonable over the merits of EJB<3 ?

    I am not sure what the definitions of 'most people' or 'unreasonable' are in this context, considering the number of successful sites that have been build with EJBs over the years. I guess I think that people saying EJBs are not, in general, successful is unreasonable.
  226. ... I guess I think that people saying EJBs are not, in general, successful is unreasonable.

    Ok i think you gave me your point of view.Note that i'm not saying that there are no good use cases for EJBs. But 'generally succesful' is relative so i wont argue further. But maybe some people's unreasonabilty is in some way justified by the major overhaul applied to the upcoming EJB spec.
  227. But maybe some people's unreasonabilty is in some way justified by the major overhaul applied to the upcoming EJB spec.

    I agree. But I don't think that this justifies the kind of general anti-JCP feeling I often see; as in a previous post here where JSF, EJB and Swing were all lumped together as if they were all part of one evil vendor-driven plot to make things worse for developers. OK, so I exaggerate a little....
  228. But I don't think that this justifies the kind of general anti-JCP feeling I often see;

    I agree. I sometimes feel that apart from the technical merits some of the vendor(s) involved in the JCP process also contribute to this by the way they handle themselves in public.

    Personally i usually find it easier to take in a tithing sermon by a layman rather than by a pastor (who gets paid from the tithe), :) but that's just me :)
  229. But I don't think that this justifies the kind of general anti-JCP feeling I often see;
    I agree. I sometimes feel that apart from the technical merits some of the vendor(s) involved in the JCP process also contribute to this by the way they handle themselves in public.

    Personally i usually find it easier to take in a tithing sermon by a layman rather than by a pastor (who gets paid from the tithe), :) but that's just me :)

    I live in a cardboard box by the river, but I still make time to participate in the JCP because it gives me warm fuzzies (it's winter here and quite cold).
  230. But I don't think that this justifies the kind of general anti-JCP feeling I often see;
    I agree. I sometimes feel that apart from the technical merits some of the vendor(s) involved in the JCP process also contribute to this by the way they handle themselves in public.Personally i usually find it easier to take in a tithing sermon by a layman rather than by a pastor (who gets paid from the tithe), :) but that's just me :)
    Having grown up as the son of a Pastor, I was going to post a reply (well different than this), but decided it was way off topic (I know, like that has stopped me before). But I pretty much know about box by the river that Jason's of.

    One note though, funny you posting this in light of Cameron's link to the definition of "ad hominem". :) Or am I pointing out your point?
  231. Remind you anything? EJB will be a universal silber bullet, all calls are remote (and slow like sh..t).

    Hi Renat,

    Was discussed on the TSS about 1-2 years ago that BEA CMP EJB2.1 can be faster than Hibernate (less amount of DB calls) ...

    Maybe you should spend some time with technology, and not just spreading a FUD ...

    I understand that it is cool these days, but still on TSS we should keep some level of technical expertise ...

    BTW EJB 2.1 supports the local invocation for last 3-5 years
  232. Tapestry?[ Go to top ]

    Did anyone in the JSF community explain why Tapestry was adopted and improved? Why reinvent the wheel?

    Does anyone know the state of Tapestry when work on JSF began?

    The JSF JSR was approved on 15 May, 2001. Tapestry was first registered as a sourceforge project on 2000-04-17 and Tapestry 2.0 wasn't released until 2002-03-30.

    Has anyone ever used Tapestry 1.0? It was not pretty. Is anyone really suprised the expert group didn't decide to adopt this little known one man project being hosted on sourceforge that was inventive but sucked? Give the JSF expert group a break. Everyone at the time of JSF's creation thought having the creator of Struts on board was experience enough.

    Mike
  233. Tapestry?[ Go to top ]

    Did anyone in the JSF community explain why Tapestry was adopted and improved? Why reinvent the wheel?
    Does anyone know the state of Tapestry when work on JSF began?The JSF JSR was approved on 15 May, 2001. Tapestry was first registered as a sourceforge project on 2000-04-17 and Tapestry 2.0 wasn't released until 2002-03-30.Has anyone ever used Tapestry 1.0? It was not pretty. Is anyone really suprised the expert group didn't decide to adopt this little known one man project being hosted on sourceforge that was inventive but sucked? Give the JSF expert group a break. Everyone at the time of JSF's creation thought having the creator of Struts on board was experience enough. Mike
    That is not entirely true. Tapestry is an attemtp to create an open-source version of WebObjects from Apple. Which was out there way before even Struts, as far as I know.

    One man or not, Tapestry was available when JSF group started and it would have been much nicer to at least include Howard in the committee, rather than have some theoreticians come up with something out of thin air.

    I beleive (and am not alone in this) that specs which are not coming from an existing implementation (experience) SUCK.

    It proved to be true for EJB, JSF, Portlets and many other specs. Everybody is excited and likes EJB3. Why? Because its persistence piece is largely replications hugely successful and proven Hibernate.

    See the point?
  234. Tapestry?[ Go to top ]

    One man or not, Tapestry was available when JSF group started and it would have been much nicer to at least include Howard in the committee, rather than have some theoreticians come up with something out of thin air.I beleive (and am not alone in this) that specs which are not coming from an existing implementation (experience) SUCK.

    First, Craig McClanahan, Struts creator, was on the comittee.
    Second, JSF are coming from existing implementation. A lot of things are similar as in Struts (validation, conversion, front controller, application controller, i18n), as in WebWorks (JavaBeans bindings, except until recently you had to implement an interface in WebWork if I remember correctly), a component model like in Tapestry and Swing. Finally but not the least, the managed-bean concept comes from Spring. So I don't get your point. Stop being vague and give some precise examples.
    It proved to be true for EJB, JSF, Portlets and many other specs. Everybody is excited and likes EJB3. Why? Because its persistence piece is largely replications hugely successful and proven Hibernate.See the point?
    JSF has already failed? I don't think so, it seems to gain some momemtum lately. A lot of innovations is going on. For instance Seam (written by the designer of Hibernate btw...), Shale (written by Craig McClanahan), ...


    I think JCP is a good way to standardize some good things coming out from the OOS community. People always complain there are too many choices in Java. Of course, OOS projects are still very important to experiment, create innovations and invent the next killer concept :) So people wanting tool support and safety will use the standard and people wanting the lastest bleeding edge technology can choose to use OOS frameworks until a new standardization is made. Isn't it the best of both worlds?
  235. Tapestry?[ Go to top ]

    Tapestry is an attemtp to create an open-source version of WebObjects from Apple. Which was out there way before even Struts, as far as I know.
    If Windows guys do not know what happens over the fence in the Big Apple city, why would Linux guys do? I mean they should have, they are a committee after all. But apparently they had other ideas in mind. There is no fun in copying after all. But learning a framework a year could be fun :)
    I beleive (and am not alone in this) that specs which are not coming from an existing implementation (experience) SUCK.
    Committee or not, JSF was concieved by Craig M, who created The Abomination (tm). Of all the people he knew better what The Abomination (tm) could and could not do. So JSF is not a just a product of a joined fart, it *did* take into consideration at least issues with The Abomination (tm). Therefore it just *has* to be better than The Abomination (tm). Whether it is better than Tapestry or not is in the eye of beholder. It is different.

    ---
    Michael Jouravlev
    JSP Controls: Create page components with JSP
  236. Tapestry?[ Go to top ]

    Tapestry is an attemtp to create an open-source version of WebObjects from Apple. Which was out there way before even Struts, as far as I know.
    If Windows guys do not know what happens over the fence in the Big Apple city, why would Linux guys do? I mean they should have, they are a committee after all. But apparently they had other ideas in mind. There is no fun in copying after all. But learning a framework a year could be fun :)
    I beleive (and am not alone in this) that specs which are not coming from an existing implementation (experience) SUCK.
    Committee or not, JSF was concieved by Craig M, who created The Abomination (tm). Of all the people he knew better what The Abomination (tm) could and could not do. So JSF is not a just a product of a joined fart, it *did* take into consideration at least issues with The Abomination (tm). Therefore it just *has* to be better than The Abomination (tm). Whether it is better than Tapestry or not is in the eye of beholder. It is different.---Michael JouravlevJSP Controls: Create page components with JSP

    Were you on any of the EGs to know where the spec started and with whom? Where the spec's ideas are actually founded in and with what people? Craig became spec lead after a period, and was not the original lead. From where I stand, a lot of the ideas in JSF came as a clean slate for Oracle's previous UIX solution.
  237. Tapestry?[ Go to top ]

    Were you on any of the EGs to know where the spec started and with whom? Where the spec's ideas are actually founded in and with what people? Craig became spec lead after a period, and was not the original lead. From where I stand, a lot of the ideas in JSF came as a clean slate for Oracle's previous UIX solution.
    I obviously wasn't. I just was being a little sarcastic ;-) It was not meant to be an attack on JSF or its current spec lead.
  238. It was developed at NeXT.

    http://www.wired.com/wired/archive/4.01/money.html
  239. Most appreciated![ Go to top ]

    I was looking for an excuse, anyway, to not to start learning JSF. May be because its novelty, JSF was such a must-know technology. JSP & Freemarker is all what i need for now.
  240. Most appreciated![ Go to top ]

    I was looking for an excuse, anyway, to not to start learning JSF. May be because its novelty, JSF was such a must-know technology. JSP &amp; Freemarker is all what i need for now.

    Some news on this site today suggests to me that JSF is definitely a must-know technology:

    http://www.theserverside.com/news/thread.tss?thread_id=38669
  241. Most appreciated![ Go to top ]

    I was looking for an excuse, anyway, to not to start learning JSF. May be because its novelty, JSF was such a must-know technology. JSP &amp;amp; Freemarker is all what i need for now.
    Some news on this site today suggests to me that JSF is definitely a must-know technology:http://www.theserverside.com/news/thread.tss?thread_id=38669

    Well, I have no idea how good those are, but there have been plenty of bad components floated out to developers over the years. It's like Eclipse plugins.. sure, there's lots of them, but 95% of them SUCK and lots of them will crash your system :-)

    I'll stick with IDEA, thanks.
  242. Most appreciated![ Go to top ]

    http://www.theserverside.com/news/thread.tss?thread_id=38669>
    Well, I have no idea how good those are, but there have been plenty of bad components floated out to developers over the years. It's like Eclipse plugins.. sure, there's lots of them, but 95% of them SUCK and lots of them will crash your system :-)I'll stick with IDEA, thanks.
    Well, I have to agree about Eclipse plugins!

    But, of course, these are JSF components from a quality source (Oracle), and you can use them in whatever IDE like, what with JSF not requiring special tools and all that :)
  243. Most appreciated![ Go to top ]

    Well, I have to agree about Eclipse plugins!But, of course, these are JSF components from a quality source (Oracle), and you can use them in whatever IDE like, what with JSF not requiring special tools and all that :)

    Well, Oracle is quality in some things, but I can't say that UI design has ever been one of them :-) (see also: SQLPlus, every Oracle Java installer, OTN, actually EVERY Oracle website, etc).
  244. Most appreciated![ Go to top ]

    Well, I have to agree about Eclipse plugins!But, of course, these are JSF components from a quality source (Oracle), and you can use them in whatever IDE like, what with JSF not requiring special tools and all that :)
    Well, Oracle is quality in some things, but I can't say that UI design has ever been one of them :-) (see also: SQLPlus, every Oracle Java installer, OTN, actually EVERY Oracle website, etc).

    Ah... SQLPlus! What fun. I agree that the installer designs are rather ... original.

    Fortunately, their ADF components are skinnable....
  245. Most appreciated![ Go to top ]

    Ah... SQLPlus! What fun. I agree that the installer designs are rather ... original.Fortunately, their ADF components are skinnable....
    My theory is that those tools (DB2's too) where written by interns or the like.
  246. POST vs GET[ Go to top ]

    IMO, JSF provides perfectly workable support for bookmarkable GET requests.

    If you want a link that is a GET request, use:

      <h:outputLink value="order.jsf">
        <h:outputText value="Take me to my order"/>
        <f:param name="orderId" value="#{order.id}"/>
      </h:outputLink>


    You can then get the paramater value injected to your backing bean using:

      <managed-property>
        <property-name>orderId</property-name>
        <value>#{param[orderId]}</value>
      </managed-property>

    From my point of view, this is Just Perfect. How could anything be easier?
          http://wiki.apache.org/myfaces/InvokingJsfPagesWithStandardUrls

    OK, so this does not let you process a form submission using GET, but that is something that I rarely ever see people do. Is there really such a burning need to bookmark the results of form submissions?? Is *this* the reason some people won't use JSF??

    Certainly, people need post-then-redirect. You can certainly do post-then-redirect using JSF, just use the <redirect> element in the navigation rule, or if you want something fancier call redirect() then responseComplete().
  247. Clickable lists with bookmarking[ Go to top ]

    Since there is *so* much confusion about this stuff, here is how you do a clickable list in JSF, where clicking a list item takes you to a bookmarkable page:


    In messageList.xhtml:

    <h:dataTable value="#{messages}" var="msg">
       <h:column>
          <h:outputLink value="message.jsf">
             <f:param name="messageId" value="#{msg.id}"/>
             #{msg.title}
          </h:outputLink>
       </h:column>
       ...
    </h:dataTable>

    In faces-config.xml:

    <managed-bean>
      <managed-bean-name>viewMessage</managed-bean-name>
      <managed-bean-class>ViewMessage</managed-bean-class>
      <managed-bean-scope>request</managed-bean-scope>
      <managed-property>
          <property-name>messageId</property>
          <value>#{param['messageId']}</value>
      </managed-property>
    </managed-bean>


    public class ViewMessage {

        private Long messageId;
        public void setMessageId(Long messageId) { this.messageId = messageId; }
        public Long getMessageId() { return messageId; }
        
        public Message getMessage() {
           return getMessageFromTheDatabase(messageId);
        }
        
    }


    In viewMessage.xhtml:

    <div>Title: #{viewMessage.message.title}</div>
    <div>Text: #{viewMessage.message.text}</div>


    I'll resist the urge to post the Seam version of this code, which is even simpler :-)
  248. I suck[ Go to top ]

    Ooops, "viewMessage.xhtml" should read "message.xhtml".
  249. Clickable lists with bookmarking[ Go to top ]

    If it was up to me, 95% of all JSF pages could just be stateless, uber composite controllers, with working blinkers and pretty debug screens.
  250. Clickable lists with bookmarking[ Go to top ]

    I'll resist the urge to post the Seam version of this code, which is even simpler :-)

    Please do it, that might impress some of the EJB critics in here ;-)
  251. Clickable lists with bookmarking[ Go to top ]

    I'll resist the urge to post the Seam version of this code, which is even simpler :-)

    Please don't resist - it would be interesting and useful.
  252. Clickable lists with bookmarking[ Go to top ]

    I'll resist the urge to post the Seam version of this code, which is even simpler :-)
    Please don't resist - it would be interesting and useful.

    OK, well, there are a couple of ways to do it. In practice I would probably more likely use an @Factory method, since I kinda like being able to refer to #{message.text} in my view instead of #{viewMessage.message.text}, but I suppose that is a matter of taste. Instead I'll show the thing that is *most* similar to the Plain JSF Way, so you can see how JSF constructs map to the precisely equivalent constructs in Seam.

    The two .xhtml pages would be unchanged (see above).

    We no longer need a <managed-bean> declaration.

    Our Java class simplifies to:

    @Name("viewMessage")
    public class ViewMessage {

        @RequestParameter
        private Long messageId;
        
        public Message getMessage() {
           return getMessageFromTheDatabase(messageId);
        }
        
    }

    In my previous post I said "what could be simpler". Well. I was wrong. This is ;-)
  253. Thank you for reminding me...[ Go to top ]

    Since there is *so* much confusion about this stuff, here is how you do a clickable list in JSF, where clicking a list item takes you to a bookmarkable page:In messageList.xhtml:
    <h:dataTable value="#{messages}" var="msg">
       <h:column>
          <h:outputLink value="message.jsf">
             <f:param name="messageId" value="#{msg.id}"/>
             #{msg.title}
          </h:outputLink>
       </h:column>
       ...
    </h:dataTable>

    In faces-config.xml:
    <managed-bean>
      <managed-bean-name>viewMessage</managed-bean-name>
      <managed-bean-class>ViewMessage</managed-bean-class>
      <managed-bean-scope>request</managed-bean-scope>
      <managed-property>
          <property-name>messageId</property>
          <value>#{param['messageId']}</value>
      </managed-property>
    </managed-bean>

    public class ViewMessage {
        private Long messageId;
        public void setMessageId(Long messageId) { this.messageId = messageId; }
        public Long getMessageId() { return messageId; }
        public Message getMessage() {
            return getMessageFromTheDatabase(messageId);
        }
    }

    In viewMessage.xhtml:

    <div>Title: #{viewMessage.message.title}</div>
    <div>Text: #{viewMessage.message.text}</div>

    I'll resist the urge to post the Seam version of this code, which is even simpler :-)

    ... reminding me why I dismissed JSF almost instantly. It uses tag libraries and JSP.

    Two fundamentally flawed technologies. JSP and the tag libraries:
    - their arbitrarily brain-dead broken macro access language (OGNL and Velocity are far more powerful than JSP's EL)
    - Tag libraries are annoyingly complicated to program
    - Tag libraries are even more annoyingly complicated to determine what they do, since they aren't really an API and often have cryptic, undocumented semantics.
    - inclusion of Java libraries so any complex operations for data access (such as looping, which the java taglibs are braindead at performing, or accessing data from sessions/collections that the EL implementors were too lazy to enable) have stupidly complex headers
    - don't get me started on taglib URLs. Dumb dumb dumb idea.

    Tag libraries never simplify anything. In order to know what they do, you basically need to figure out what java code they transform into. But since taglibs were supposed to be this magical entity that allowed nonprogrammers to write dynamic web pages, count that as a massive failure.

    So far, on a simple simple request such as (pass data with GET not POST), the JSF people have fallen over each other with "theoretical" statements that JSF could do that (anything is possible with a million lines of code "theoretically" - yes yes Comp Sci majors, I know that's not actually true), or lectured that the author isn't using POST GET right.

    I've done several web frameworks for various platforms. With things like WAP phones, you need to be very very very flexible as to how you pass data. I've had to use GET and POST simultaneously in the same requests. Something this simple and easy shouldn't be "theoretically" possible. It shouldn't ever even be mentioned.

    JSF is a big fat dead end. Tapestry is a far superior, but of course Sun has gone the way of big, fat, and dumb, which is the way they always go when they try to establish "leadership" in the java community. God they **** stuff up. Don't get me started on the logging API. Or the fact they name everything as convoluted as possible. Java Server Faces? Just a stupid name from a project that probably has a dedicated marketing budget.

    As for the JSF people wondering why people don't like it, I have to testify that every single serverside thread has JSF fanboys pointlessly injecting themselves into the discussions stating that JSF can support whatever is being talked about. AJAX (the antithesis of server-heaver client processing, yet JSF is APPARENTLY perfect for it... right...), and web frameworks, Spring, Hibernate, you name it. Maybe Sun put its marketing budget into paying fanboy posters rather than generating good documentation, examples, and communication.
  254. Since there is *so* much confusion about this stuff, here is how you do a clickable list in JSF, where clicking a list item takes you to a bookmarkable page:[Editor's note: snipped for brevity, search for Gavin King's example earlier in the thread]
    I'll resist the urge to post the Seam version of this code, which is even simpler :-)
    ... reminding me why I dismissed JSF almost instantly. It uses tag libraries and JSP.Two fundamentally flawed technologies. JSP and the tag libraries:- their arbitrarily brain-dead broken macro access language (OGNL and Velocity are far more powerful than JSP's EL)- Tag libraries are annoyingly complicated to program- Tag libraries are even more annoyingly complicated to determine what they do, since they aren't really an API and often have cryptic, undocumented semantics. - inclusion of Java libraries so any complex operations for data access (such as looping, which the java taglibs are braindead at performing, or accessing data from sessions/collections that the EL implementors were too lazy to enable) have stupidly complex headers- don't get me started on taglib URLs. Dumb dumb dumb idea.Tag libraries never simplify anything. In order to know what they do, you basically need to figure out what java code they transform into. But since taglibs were supposed to be this magical entity that allowed nonprogrammers to write dynamic web pages, count that as a massive failure.So far, on a simple simple request such as (pass data with GET not POST), the JSF people have fallen over each other with "theoretical" statements that JSF could do that (anything is possible with a million lines of code "theoretically" - yes yes Comp Sci majors, I know that's not actually true), or lectured that the author isn't using POST GET right.I've done several web frameworks for various platforms. With things like WAP phones, you need to be very very very flexible as to how you pass data. I've had to use GET and POST simultaneously in the same requests. Something this simple and easy shouldn't be "theoretically" possible. It shouldn't ever even be mentioned.JSF is a big fat dead end. Tapestry is a far superior, but of course Sun has gone the way of big, fat, and dumb, which is the way they always go when they try to establish "leadership" in the java community. God they **** stuff up. Don't get me started on the logging API. Or the fact they name everything as convoluted as possible. Java Server Faces? Just a stupid name from a project that probably has a dedicated marketing budget.As for the JSF people wondering why people don't like it, I have to testify that every single serverside thread has JSF fanboys pointlessly injecting themselves into the discussions stating that JSF can support whatever is being talked about. AJAX (the antithesis of server-heaver client processing, yet JSF is APPARENTLY perfect for it... right...), and web frameworks, Spring, Hibernate, you name it. Maybe Sun put its marketing budget into paying fanboy posters rather than generating good documentation, examples, and communication.
    You might try it before flaming it. I use JSF without JS and taglib. Go on google and search for facelets (written by Jacob Hookom you posted previously in this thread). Everyone agree combining JSF/JSP right now is dumb but the good news you don't have too. Other then that, give some facts instead of insulting people using JSF, liking it and trying to express why they like it. You don't see us always flaming Tapestry so why some people seem to feel obligated to insult everyone liking JSF? Oh yeah we are probably some evil capitalists developpers hired by Sun wanting to kill every OOS projects...
  255. Facelets?[ Go to top ]

    Alexandre! Can you please share your experience with Facelets. Did you had experience composing a page from custom-made components with no need to create additional tag classes?

    See my fears here:
    http://write-software.blogspot.com/2006/01/day-5-web-framework-i-need.html

    Denis Krukovsky
    http://dkrukovsky.blogspot.com/
    http://write-software.blogspot.com/
  256. Facelets?[ Go to top ]

    Alexandre! Can you please share your experience with Facelets. Did you had experience composing a page from custom-made components with no need to create additional tag classes?See my fears here:http://write-software.blogspot.com/2006/01/day-5-web-framework-i-need.htmlDenis Krukovskyhttp://dkrukovsky.blogspot.com/http://write-software.blogspot.com/

    From your blog :
    What it means is that for this scheme to work, for every custom component I made I have to create a corresponding Tag class and register it within XML configs somewhere.

    You don't have to create a Tag class. You just need to add a xml entry. By the way, you can do it the faces way. : 1)provide a xml file in your jar meta-inf directory wich will be automatically loaded.
    2) Or add it in your application facelet config file if you have one.

    I don't see any problem there. You don't have to write any Java at all and no need to write a stupid Tag JSP class. By the way, you should ask Jacob Hookom who posted previously, he is the creator of Facelets, so he probably knows better than me :)
  257. I'm not particularly invested in Tapestry, I've never actually used it beyond doing examples to see how it works. It's great that JSF is evolving away from JSPs, but then that means you have a totally polluted project with several independently invented ways of addressing/bypassing its shortcomings. That means the project is a failure and it is just more noise pollution, and really loud at that, in the grand cacophony of Java frameworks.

    My anger at JSF is really just that it is the typical Sun project that seems to get everything wrong:
    - weird, bad terminology and poor naming (does anyone know anything about marketing at Sun?). Half of java's initial success is its cool little name and the "applet", two marketing-centric names. "Faces"? "facelets"?
    - vendor-centric architecture, rather than developer centric. Bascially, they built something for vendors to sell products for, but as to whether they actually help developers solve the problem, well, that's a second priority. Also see: J2EE/EJB

    So it's poorly communicated, and doesn't solve the problem. Meanwhile, dotNET is pulling ahead. Great.
  258. Thank you for reminding me...[ Go to top ]

    (does anyone know anything about marketing at Sun?). Half of java's initial success is its cool little name and the "applet", two marketing-centric names. "Faces"? "facelets"?

    Just FYI, I no more work for Sun than you or Jason. Facelets is a real word too.

    -- Jacoblet Hookomlet
  259. Thank you for reminding me...[ Go to top ]

    Bascially, they built something for vendors to sell products for, but as to whether they actually help developers solve the problem, well, that's a second priority.

    I have never understood this point. The definition of vendor is 'one who sells'. If things are built for vendors, they are built to enable the production of things that will be popular with purchasers - the developers. JSF allows different vendors to target the same API for tools and components. This, in itself, solves a problem for developers by opening up a competitive market for tools and components. I can't see how providing something for vendors to sell products for is a problem, especially as
    one of the most prominent implementations of JSF is Apache MyFaces. I don't think anyone could call Apache a 'vendor'.
    Meanwhile, dotNET is pulling ahead.

    Actually, I have not seen evidence of any change in the market shares of .NET and Java for a long time; but this is wandering off topic.
  260. Thank you for reminding me...[ Go to top ]

    I have never understood this point.

    Well, when you or one of the other JSF proponents in this thread was listing the priorities of the creators of JSF above they were, as I pointed out, largely directed to tool vendors and app server vendors, rather than developers. It's pretty easy to see what the motivations of a project are based on its outcome, and developers see when they weren't the primary focus, and it doesn't make them warm and comfy.
    The definition of vendor is 'one who sells'. If things are built for vendors, they are built to enable the production of things that will be popular with purchasers - the developers.

    You assume that the developers are the ones who are being sold to... This is generally not correct, since developers don't control project $$$ or tool selection in most cases.
    JSF allows different vendors to target the same API for tools and components. This, in itself, solves a problem for developers by opening up a competitive market for tools and components. I can't see how providing something for vendors to sell products for is a problem, especially as one of the most prominent implementations of JSF is Apache MyFaces. I don't think anyone could call Apache a 'vendor'.

    That's not the problem. The problem is the feeling that developer's needs were secondary to the vendors needs. Opensource, non-committee designed APIs don't usually have this problem.
  261. Thank you for reminding me...[ Go to top ]

    It's pretty easy to see what the motivations of a project are based on its outcome, and developers see when they weren't the primary focus, and it doesn't make them warm and comfy.

    That is your opinion and interpretation. It isn't mine. Until a major web developer survey about how warm and comfy they are regarding the efforts of the JCP is carried out then statements like this are, I would suggest, meaningless.
    The definition of vendor is 'one who sells'. If things are built for vendors, they are built to enable the production of things that will be popular with purchasers - the developers.
    You assume that the developers are the ones who are being sold to... This is generally not correct, since developers don't control project $$$ or tool selection in most cases.

    Ah! The old 'selling to the evil managers' argument.
    That's not the problem. The problem is the feeling that developer's needs were secondary to the vendors needs. Opensource, non-committee designed APIs don't usually have this problem.

    Sorry, but this sounds just like simple bias to me. But I freely admit that I am distinctly biased towards APIs with multiple vendor support. That gives me a warm and comfy feeling.
  262. One major issue that we ran into during our JSF development was "how do we handle http request which are coming from bookmark". Bookmark is not going to come w/ parameter which breaks everything.

    Our framework checks if the user is logged in. But, what happens when user is already logged, and he/she try to use bookmark.

    Any solution this issue ?
  263. One major issue that we ran into during our JSF development was "how do we handle http request which are coming from bookmark". Bookmark is not going to come w/ parameter which breaks everything.Our framework checks if the user is logged in. But, what happens when user is already logged, and he/she try to use bookmark.Any solution this issue ?

    This problem is far from being unique to JSF. For instance, using Struts I always add troubles to reconstruct my application breadcrumb navigation bar. I had two choices, use a long url saving everything there or assiocate each url with a navigation bar state. But developpers have to understand you can't save the entire web application state in the URL. So basically you have to decide the granularity of your url (what part of your application state do you keep in your url and what not). You just need to catch the url and return the user to the place where he belongs based on your url schema.

    Clients applications work the same way, they just don't use URL but command line. For instance, do you expect to be able to reopen OpenOffice in the latest dialog box you were before quitting using a long command line? I don't think so but you are expecting it to open your last document or to be able to double click a document and have it loaded automatically.
  264. Workarounds for this problem[ Go to top ]

    Great to see that this problem is getting some attention. I first came across it when building a form for an HTML email newsletter. I don't know of any email clients which will actually do a POST - they just seem to launch the browser with the GET url as a command line parameter.

    Normally, JSF won't allow you to invoke actions (e.g. from a form submit) when a page is first viewed because it is the last phase in the lifecycle which is responsible for building the component tree. You shouldn't be able to trigger events without the component tree! AFAICT the problem is pretty entrenched into JSF's lifecycle so I don't have my hopes up for seeing it get fixed.

    As it happens, there is a workaround, but you need to submit the entire component tree along with the GET url (yeuch!). It is posted amongst other possible solutions at http://forum.java.sun.com/thread.jspa?threadID=586940
  265. Workarounds for this problem[ Go to top ]

    Normally, JSF won't allow you to invoke actions (e.g. from a form submit) when a page is first viewed

    Right, but 90% of the time you do not need to invoke an action to service a GET request. It is *perfectly* reasonable to have the view "pull" stuff from a backing bean for GET requests. Actions are for "changing stuff". You should not "change stuff" from a HTTP GET, that is not the semantics of GET!

    The exception is where this GET request is really a POST in disguise, eg. if you are validating an email address or something. In that case, it is easy enough to hook in a phase listener or something to handle that. Or write a servlet that runs and then forwards to the resulting JSF page. There are many, many reasonable solutions to this. Sure they are workarounds. They are workarounds because *you* are using a workaround, ie. hacking POST semantics into a GET!

    Really, it is incredibly trivial to extend JSF to support actions that attach to URLs instead of form submissions. Just look at the PhaseListener API.
  266. Workarounds for this problem[ Go to top ]

    You shouldn't be able to trigger events without the component
    > tree!

    Yes, and in our programming that was one of the biggest problems (not the POST of course). How to deal with the part of the tree in JSF?

    Dmitry
    http://www.servletsuite.com
  267. GET is not a problem![ Go to top ]

    Here are some ways to invoke actions on non-faces requests. For example see http://blog.exadel.com/?p=19
  268. The other day I read a blog where some other idiot stated that George W. Bush was not fit to be President. After checking CNN, however, I found that Mr. Bush was still in office and the government was functioning.

    Why is this site discussing blogs from goofs as though they were a) any indication of a technology's value or b) any indication of a technology's market penetration ?

    ahh ... I'm just ... WTF ?!? Why should anybody care what good ol' Tim thinks about anything ?!? What ? he's some guy who writes programs ? Oooooo ... Creeping Jesus ! I can barely put up with the insane gibberish from the self-proclaimed experts and salesfarts who spend their careers polluting the atmosphere with their ridiculous lies - why would anyone want to add the uninformed spouting of random programmers to that bad noise ?

    Man ... the .NET world is really starting to look good ... at least all the lies and half-truths there are PREDICTABLE and EXPECTED nonsense. aarrggh ...

    Nuts.
  269. Why would anyone use JSF for a bookmarkable site? JSF is more or less specially made for building custom web application, and is a relativily bearable framework for that matter. However it is too specialized to use e.g. for public web development where any other simple framework will do much better.

    My complaint with JSF is not in the features it provide, but rather in that it is very hard to extend. Framework is just pretty much monolith and to write a custom component one has to deal with a lot of complex API (and accursed render-kits), which means that it's infeasible to reuse custom application stuff in components.
  270. Why would anyone use JSF for a bookmarkable site? JSF is more or less specially made for building custom web application, and is a relativily bearable framework for that matter. However it is too specialized to use e.g. for public web development where any other simple framework will do much better.
    Depends, first of all, we have to define what is a ozbkuch web development. If you speak of simple html pages, probably yes, but probably j2ee is the wrong choice at all. But many so called public pages nowadays have similar problems and you need to apply similar techniques like in so called backoffice apps.
    If you prefer another framework it is up to you. It really depends on the application.

    In so called backoffice applications, real web applications with often complex controls, I would not want to do them without a good component based framework, the demands of the users are simply too high nowadays to feed them with basic html controls anymore.
    My complaint with JSF is not in the features it provide, but rather in that it is very hard to extend. Framework is just pretty much monolith and to write a custom component one has to deal with a lot of complex API (and accursed render-kits), which means that it's infeasible to reuse custom application stuff in components.

    Well it is in the eye of the beholder. If you talk about the component API, it definitely is too complicated due to the genericness it has, and due to the fact that also hooks into jsp have to be provided for jsp rendering.
    It is definitely a no go for reusable application parts, but you can apply different techniques to solve such a problem. Facelets for instance would be the perfect choice here. Easy to apply, easy to reuse for general purpose application component parts building.

    As for extending the api is complex. It definitely is not, the api has clear extension points and adding for instance a nav handler, a view handler etc.. is very easy once you have a grasp on the basics of what they are doing.
    But you hardly extend the api for application reuse.
    ;-)
  271. Gavin rules: nice explanation + code sample. The only problem I have is the starting page of an application, module or wizard. In JSF, browser navigates to a view, not to an action like in Struts. Therefore this view is to be displayed whether it is appropriate or not. There was a security-related complain in this discussion, this is the same thing. What if a view is not appropriate?

    In Struts or other action framework a user/browser sends a command to a controller, which decides what to show. In JSF a user requests a particular view. This is a huge difference. I think the latter approach may work better if a view contains subviews for different states, so if a user is not authorized it would show "Not authorized" message.

    Still, command pattern seems simpler and more robust for me: a user sends "show items" command, and controller decides either to show "itemview" or "loginview". Having application deciding what view to show adds security and keeps application consistent: a user simply cannot know which view is appropriate in a particular application state, but application knows.
  272. Gavin rules: nice explanation + code sample. The only problem I have is the starting page of an application, module or wizard. In JSF, browser navigates to a view, not to an action like in Struts. Therefore this view is to be displayed whether it is appropriate or not. There was a security-related complain in this discussion, this is the same thing. What if a view is not appropriate?In Struts or other action framework a user/browser sends a command to a controller, which decides what to show. In JSF a user requests a particular view. This is a huge difference. I think the latter approach may work better if a view contains subviews for different states, so if a user is not authorized it would show "Not authorized" message. Still, command pattern seems simpler and more robust for me: a user sends "show items" command, and controller decides either to show "itemview" or "loginview". Having application deciding what view to show adds security and keeps application consistent: a user simply cannot know which view is appropriate in a particular application state, but application knows.

    I really think if JSF had a proper story for stateless operation (GET) within the lifecycle, other than just [render], then I think the framework would get a lot more traction. Gavin has been able to take the JSF foundation and write a framework around it that caters/solves a lot of the use cases people have presented to JSF.
  273. It is possible to make JSF behave more like Struts by defining your own view handler that intercepts some of the calls and re-routes them if appropriate.

    This is spelled out in detail in the following article:

    http://blog.exadel.com/?p=19
  274. It is possible to make JSF behave more like Struts by defining your own view handler that intercepts some of the calls and re-routes them if appropriate.This is spelled out in detail in the following article:http://blog.exadel.com/?p=19

    The problem with that suggestion is that you could bypass action invocation by simply not passing the action parameter.

    With JSF 1.2, you can declare phaselistener methods right on the root f:view tag. This allows you to enforce behavior/validation/authorization on a per-view basis.
  275. It is possible to make JSF behave more like Struts by defining your own view handler that intercepts some of the calls and re-routes them if appropriate.This is spelled out in detail in the following article:http://blog.exadel.com/?p=19
    This is a nice hack. I call this a hack because if something is not in the framework and was not suppposed to work that way, but was bent forcefully, it is a hack. Interesting comment left there by Gavin: "I think the reason why JSF doesn’t let an action handler determine the view to use on a GET request is that this is an unnatural thing to do given the semantics of GET! POST, PUT, DELETE can “decide” things," -- I agree with that part of the sentence. "but GET should just display something; the same thing every time" -- I totally don't agree with that. Stupid example, page that displays current time. Does it displays same time every time? Nope. Or railway schedule, it can change over time. Or order status, it can be removed after goods are delivered or after certain period of time. Or employee data, it surely changes. GET means "give me info about something", it does not mean "give me info about something and make sure that it is the same as yesterday and it will be the same tomorrow". This is the whole point why you ask about something again and again - to see what has changed!

    Gavin goes on: "AFAICT, the only major reason you would need to 'decide which page to go to', is that your GET request displays different things at different times, for the exact same URL. This is an antipattern. -- this is NOT an antipattern, this is a normal thing for a stateful application, to show how a resource changes over the time, or maybe disappears at all. Stateful resources is the reason browsers have "Refresh" button.
  276. "I think the reason why JSF doesn’t let an action handler determine the view to use on a GET request is that this is an unnatural thing to do given the semantics of GET! POST, PUT, DELETE can “decide” things," -- I agree with that part of the sentence. "but GET should just display something; the same thing every time" -- I totally don't agree with that.

    Please read the HTTP RFC document. If you still don't agree with what Gavin said, you can either stop your web development, or change the protocol.
    Stupid example, page that displays current time. Does it displays same time every time? Nope.

    Yep, it must. But you would have to be going back in time to repeat the request.
    This is the whole point why you ask about something again and again - to see what has changed!

    There's a difference between 'what has changed?'(GET) and 'can you induce this change for me? By the way, here is some data which could help you out.'(POST)
  277. Please read the HTTP RFC document. If you still don't agree with what Gavin said, you can either stop your web development, or change the protocol.

    Right, the funny thing about this thread is that JSF is being criticized for being unRESTful, but the only thing we have really established that JSF can't do (without trivial workarounds) is in fact a thing that is quite contrary to the principles of REST!

    The irony :-)
  278. Please read the HTTP RFC document. If you still don't agree with what Gavin said, you can either stop your web development, or change the protocol.

    Right. And let's remove the static keyword from Java, convince the world to use object databases instead of relational ones and ship browsers that only render XHTML from now on while we're at it.
  279. Please read the HTTP RFC document. If you still don't agree with what Gavin said, you can either stop your web development, or change the protocol.
    Right. And let's remove the static keyword from Java, convince the world to use object databases instead of relational ones and ship browsers that only render XHTML from now on while we're at it.
    Well, two out of three ain't bad.
  280. Please read the HTTP RFC document. If you still don't agree with what Gavin said, you can either stop your web development, or change the protocol.
    Right. And let's remove the static keyword from Java, convince the world to use object databases instead of relational ones and ship browsers that only render XHTML from now on while we're at it.
    Well, two out of three ain't bad.

    I know. I'm not kidding ;)
  281. Stupid example, page that displays current time. Does it displays same time every time? Nope. Or railway schedule, it can change over time. Or order status, it can be removed after goods are delivered or after certain period of time. Or employee data, it surely changes. GET means "give me info about something", it does not mean "give me info about something and make sure that it is the same as yesterday and it will be the same tomorrow". This is the whole point why you ask about something again and again - to see what has changed!

    Yes, it is a very silly example! Because "the current time" or "the railway schedule for the A train", or "salary of Tim Shadel" is the "same thing", in my understanding. Things can change over time, but their identity is constant:

    http://mydomain.com/currentTime.jsf
    http://mydomain.com/railwayShedule.jsf/line=A
    http://mydomain.com/employeeDetails.jsf/name=TimShadel

    Are all VERY doable in JSF.
    "AFAICT, the only major reason you would need to 'decide which page to go to', is that your GET request displays different things at different times, for the exact same URL. This is an antipattern. -- this is NOT an antipattern, this is a normal thing for a stateful application, to show how a resource changes over the time, or maybe disappears at all. Stateful resources is the reason browsers have "Refresh" button.

    It is the same page. It is just different data displayed on the page.

    You've totally misunderstood my post.
  282. "I think the reason why JSF doesn’t let an action handler determine the view to use on a GET request is that this is an unnatural thing to do given the semantics of GET! POST, PUT, DELETE can “decide” things," -- I agree with that part of the sentence. "but GET should just display something; the same thing every time" -- I totally don't agree with that.
    Please read the HTTP RFC document. If you still don't agree with what Gavin said, you can either stop your web development, or change the protocol.
    9.3 GET: "The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI". ... "The semantics of the GET method change to a "conditional GET" if the request message includes an If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, or If-Range header field. A conditional GET method requests that the entity be transferred only under the circumstances described by the conditional header field(s). The conditional GET method is intended to reduce unnecessary network usage by allowing cached entities to be refreshed without requiring multiple requests or transferring data already held by the client."

    I think you confuse response caching and history lists. In the latter case response should be identical to a prior, this is the point that Opera guys make when they are being asked why Opera does not reload a page when a user goes back and a page is marked as "no-cache, no-store". See section 13.13.

    Maybe you need to read HTTP spec yourself?
    Stupid example, page that displays current time. Does it displays same time every time? Nope. Or railway schedule, it can change over time. Or order status, it can be removed after goods are delivered or after certain period of time. Or employee data, it surely changes. GET means "give me info about something", it does not mean "give me info about something and make sure that it is the same as yesterday and it will be the same tomorrow". This is the whole point why you ask about something again and again - to see what has changed!
    Yes, it is a very silly example! Because "the current time" or "the railway schedule for the A train", or "salary of Tim Shadel" is the "same thing", in my understanding. Things can change over time, but their identity is constant:http://mydomain.com/currentTime.jsf http://mydomain.com/railwayShedule.jsf/line=A http://mydomain.com/employeeDetails.jsf/name=TimShadelAre all VERY doable in JSF.
    Now I see what you mean by the "same thing": the identity. Of course, I agree with this definition ;-)
  283. Maybe you need to read HTTP spec yourself?

    Oh I meant STUDY. Not a once through lightly.

    The audacity to say a GET is allowed to cause a change on the server AFTER "reading" the RFC.
  284. 9.1.2 Idempotent Methods

    Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property. Also, the methods OPTIONS and TRACE SHOULD NOT have side effects, and so are inherently idempotent.
  285. 9.1.2 Idempotent Methods

    Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property. Also, the methods OPTIONS and TRACE SHOULD NOT have side effects, and so are inherently idempotent.
  286. Do me a favor, Michael. At least pretend that you're actually reading the text. Which part of 'inherently' are you having trouble with?

    I would encourage you to sit down and read the whole spec through, at least once. I'd also encourage you to stop trying to quote bits of a document out of context to prove your point (obviously, it hasn't worked out well for either of us).

    That paragraph says that some aspects of the HTTP spec have a property known as idempotence (can be repeated without causing cumulative changes to the system). Among the aspects of HTTP that have this property (ie, ARE idempotent), is the GET request.

    Later blocks of the spec go on to state that the idempotent/not-idempotent litmus test differentiates how caching should work (eg, POSTs are to be resubmitted each time the page is evaluated). I believe that this quality is further clarified in some of the addenda, but don't quote me on it.
  287. Do me a favor, Michael. At least pretend that you're actually reading the text. Which part of 'inherently' are you having trouble with?

    Jason, judging by your name Engish is supposed to be your native language. Which part of "Also, the methods OPTIONS and TRACE SHOULD NOT have side effects, and so are inherently idempotent" are you having trouble with? Do you see GET in this sentence? At least pretent that you're actually understand what you've read.
    That paragraph says that some aspects of the HTTP spec have a property known as idempotence (can be repeated without causing cumulative changes to the system). Among the aspects of HTTP that have this property (ie, ARE idempotent), is the GET request.

    Did you miss the "can" and "side-effects" bits? I can break it down for you if you cannot comprehend long sentences:

    * The methods GET, HEAD, PUT and DELETE can have side effects
    * Section 9.2 does not explicitly state that the side effects of the above methods must be idempotent, but section 13.9 states that "the application of GET and HEAD methods to any resources SHOULD NOT have side effects that would lead to erroneous behavior if these responses are taken from a cache". Does this mean that above methods must be idempotent? Not necessarily. What is a side effect after all? Maybe it is a simple hit counter. In this case the requests will not be idempotent because there is a cumulative change to a counter, but if the result were taken from a cache, the behavior would hardly be erroneous. Who cares about one unregistered hit that indeed did not happen? But you can have your own definition of "erroneous" that would require GET to be strictly idempotent.
    * The methods OPTIONS and TRACE SHOULD NOT have side effects
    * Because of previous statement and definition of idempotence stated in 9.2, the methods OPTIONS and TRACE are inherently idempotent. Duh!
  288. Michael, we can quote too!!!! :-(
    9.1 Safe and Idempotent Methods
    9.1.1 Safe Methods
    Implementors should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves or others.

    In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.

    Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.

    The above has been lifted as it is from http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
    without any pre-conceived biases.

    Where did you you get your spec from? Your dreams?

    I would LOVE to sue your firm, for doing what a GET is not supposed to do? Don't predict, you would lose miserably!!
  289. but GET should just display something; the same thing every time" -- I totally don't agree with that.

    I don't agree either. You know, this whole business about the semantics of HTTP actions and REST makes sense in the original resource-centric idea of the web. But now that the browser got so common place in businesses, and a huge deal of 'business'/ intranet applications are build for utilizing web browsers, the idea isn't as relevant. A large percentage of developers nowadays are building web applications because it is an cost-efficient thing to deploy and maintain in businesses, not because they are crazy about the semantics of HTTP. E.g. if they are using links to delete items from lists, they are mis-using GET. I'm pretty sure most programmers couldn't care less about that.
  290. Gavin rules: nice explanation + code sample. The only problem I have is the starting page of an application, module or wizard. In JSF, browser navigates to a view, not to an action like in Struts. Therefore this view is to be displayed whether it is appropriate or not. There was a security-related complain in this discussion, this is the same thing. What if a view is not appropriate?In Struts or other action framework a user/browser sends a command to a controller, which decides what to show.
    Well the struts flow is basically a hack against html which
    turns the workflow of html and basically most server side rendered uis around 180 degrees.
    People who do struts have probably a hard time to adjust to the page action page flow, while probably most other people
    who come from other ui systems and have to learn struts have a hard time to grasp the action page action flow.

    Anyway what you want to achieve definitely is not a show stopper, there are myriads of ways to solve that.
    a) You can use a phase listener
    b) You can use a servlet filter
    c) You can use a nav handler
    d) You can use a page handler

    for such an interception

    In my last application I opted for a security phase listener just exactly to cover that case.
    In JSF a user requests a particular view. This is a huge difference. I think the latter approach may work better if a view contains subviews for different states, so if a user is not authorized it would show "Not authorized" message. Still, command pattern seems simpler and more robust for me: a user sends "show items" command, and controller decides either to show "itemview" or "loginview". Having application deciding what view to show adds security and keeps application consistent: a user simply cannot know which view is appropriate in a particular application state, but application knows.

    With a view handler exactly such a thing is doable, a nav handler could also do that stuff, with a phase listener at least a redirect to a different view can be achieved.
  291. JSF Good[ Go to top ]

    Even if you hate JSF, you have to admit that the "report" was mostly FUD.

    JSF is neither taking the world by storm nor dead on arrival.

    It is growing slowly. I do see a lot more bloggers talking about JSF on Jroller.

    Dice Job Demmand:
    JSP 3,160
    Struts 1,455
    JSF 108
    Rails 24
    Tapestry Java 17
    WebWork 7

    I've used JSF on several projects. I enjoy using it. JSF is a lot more productive to similar projects I did in Struts.

    When you combine JSF, Facelets, Spring, Hibernate.... you can get a very productive web enviroment. I still think it is the best stack for doing Java web development (that I know of).
  292. JSF Good[ Go to top ]

    As seems to me the one of JSF "problems" is the position of advocates always highlight JSF versus JSP, JSF versus the rest of the world etc. The current implementation was done for JSP for example, so why do you count JSP separately and highlight that especially? You cannot win such a way (if you are not getting paid in Redmond of course ;-)
  293. JSF Good[ Go to top ]

    As seems to me the one of JSF "problems" is the position of advocates always highlight JSF versus JSP, JSF versus the rest of the world etc. The current implementation was done for JSP for example, so why do you count JSP separately and highlight that especially? You cannot win such a way (if you are not getting paid in Redmond of course ;-)

    Somehow I lost your point, can you break it down for me?

    JSF is not tied to JSP see Clay and Facelets.

    I just put JSP out there for a reference count to put things in perspective.
  294. I though people would standardize on JSF because it was a J2EE standard and stop using struts etc. I was wrong!!
    The JSF job market has not taken off so I think the power of the J2EE standard is wearing off now.
    Also it was bad for JSF to be released without good tools and lots of gui objects that would hide the low level details. It would have been better to release an eclipse
    based tool that did GUI development rather than JSF as a separate spec.
    I think JSF is also too late now. Most companies are using JSP, or Struts or some other web framework and cannot see the value of changing to JSF. Something more compelling needs to arrive before companies will move on. Something that simplifies all the J2EE technologies. Spring and Pojos are the in the right direction.
  295. Something that simplifies all the J2EE
    technologies. Spring and Pojos are the in the right
    direction.

    JSF just goes the Java lane of creating more and more internal complexity. The idea to use tools as eclipse for handling and hiding this complexity does not solve the problem for good, but hides the symptoms. It kind of moves us away from java to some kind of abstract programming language called "eclipse". But we loose a lot, because there is actually growing some weird mixture between a java-code which nobody really can handle and the eclipse tools to work that code.

    I think we have to widen our view. This "something that
    simplifies the J2EE" could very well be Ruby on Rails, at
    least for a vast range of applications.
  296. Something that simplifies all the J2EE technologies. Spring and Pojos are the in the right direction.
    JSF just goes the Java lane of creating more and more internal complexity. The idea to use tools as eclipse for handling and hiding this complexity does not solve the problem for good, but hides the symptoms.

    If you like Spring and Pojos, you should like JSF. It works with Pojos which hold model state, and uses a limited form of dependency injection (which can be easily extended using JSF-Spring).

    Using tools with JSF neither hides nor reveals complexity. JSF Tools can simply code standard HTML + JSP tag use for you, and manage the XML files. The XML is no more or less complex than that for Spring, and the HTML is no more or less complex than that coded by hand.

    The complexity of JSF may be there for developers who wish to write certain types of components, and for those who wish to extend the framework, not for the web page developer.
    It kind of moves us away from java to some kind of abstract programming language called "eclipse". But we loose a lot, because there is actually growing some weird mixture between a java-code which nobody really can handle and the eclipse tools to work that code.

    No. There is no 'eclipse' or any other additional code that ends up in your application, XML, or web pages.
    I think we have to widen our view. This "something that simplifies the J2EE" could very well be Ruby on Rails, at least for a vast range of applications.

    Or, if you investigate the technology and try it out, you may find JSF a simplification. I did. Not as simple as RoR for some uses, but certainly simpler that the way I used to do things.
  297. Maybe my point was not made quite clear.

    What we create is a set of files .java, .class, .xml, .jar etc. which together forms an application.
    Off course you can write the source files (mostly .xml and .java) with a text editor, but people start getting problems handling the implied complexity. So some people feel a necessity to use eclipse (or something like that) just to retain their ability to handle the inertial complexity of java and J2EE. So the real source code is the usage of eclipse, which is not retained, but instead some files are retained, which have been generated by eclipse. There is no reasonable way to retain the input to eclipse as source, this would be mouse movements etc., which is not reasonable. But the source code that we retain is less and less the root source code.
    Off course, the .java-files and .xml-files etc. are not eclipse specific, but they can be used with anything else as well. To some extent, because we have tree structures etc which might not be easy to transform. But I would still assume, that the source files that we retain, the most original that we can retain, are not eclipse specific.
  298. Maybe my point was not made quite clear.What we create is a set of files .java, .class, .xml, .jar etc. which together forms an application.Off course you can write the source files (mostly .xml and .java) with a text editor, but people start getting problems handling the implied complexity. So some people feel a necessity to use eclipse (or something like that) just to retain their ability to handle the inertial complexity of java and J2EE. So the real source code is the usage of eclipse, which is not retained, but instead some files are retained, which have been generated by eclipse. There is no reasonable way to retain the input to eclipse as source, this would be mouse movements etc., which is not reasonable. But the source code that we retain is less and less the root source code.Off course, the .java-files and .xml-files etc. are not eclipse specific, but they can be used with anything else as well. To some extent, because we have tree structures etc which might not be easy to transform. But I would still assume, that the source files that we retain, the most original that we can retain, are not eclipse specific.

    I have no idea what you are talking about here, but you are certainly not talking about JSF. Have you ever actually used JSF?
  299. Maybe my point was not made quite clear.What we create is a set of files .java, .class, .xml, .jar etc. which together forms an application.Off course you can write the source files (mostly .xml and .java) with a text editor, but people start getting problems handling the implied complexity. So some people feel a necessity to use eclipse (or something like that) just to retain their ability to handle the inertial complexity of java and J2EE. So the real source code is the usage of eclipse, which is not retained, but instead some files are retained, which have been generated by eclipse. There is no reasonable way to retain the input to eclipse as source, this would be mouse movements etc., which is not reasonable. But the source code that we retain is less and less the root source code.Off course, the .java-files and .xml-files etc. are not eclipse specific, but they can be used with anything else as well. To some extent, because we have tree structures etc which might not be easy to transform. But I would still assume, that the source files that we retain, the most original that we can retain, are not eclipse specific.

    What are you talking about? You sure you don't confuse JSF and ASP.net?
  300. Or, if you investigate the technology and try it out, you may find JSF a simplification. I did. Not as simple as RoR for some uses, but certainly simpler that the way I used to do things.

    And what was the way you used to do things?
  301. Or, if you investigate the technology and try it out, you may find JSF a simplification. I did. Not as simple as RoR for some uses, but certainly simpler that the way I used to do things.
    And what was the way you used to do things?

    Struts, as it was several years ago. I guess this could explain a lot :)
  302. JSF just goes the Java lane of creating more and more internal complexity. The idea to use tools as eclipse for handling and hiding this complexity does not solve the problem for good, but hides the symptoms. It kind of moves us away from java to some kind of abstract programming language called "eclipse". But we loose a lot, because there is actually growing some weird mixture between a java-code which nobody really can handle and the eclipse tools to work that code.I think we have to widen our view. This "something that simplifies the J2EE" could very well be Ruby on Rails, at least for a vast range of applications.

    Okay, now you are just making stuff up for the sake of posting. Sad.
  303. People who forget about simplicity and begin building theoretical "rockets" are doomed for failure.

    JSF would NEVER made it, if big vendors did not support it so much. It will help for a while, but in the long run - it HAS to fail, or Java will fail with it and everybody will begin using RoR or whatever crap :) will be out there at that time. Sad.

    Simplicity is the key!

    Rickard Oberg (I think) once said that the value of a framework is not in what it allows but what it does not allow to do.

    I think RubyOnRails proved that point very well. And I think, contrary to this article's author (even though he has many valid points) the main problem of JSF is not what it does not allow but how much it allows and how bloated it has become because of it.
  304. JSF would NEVER made it, if big vendors did not support it so much. It will help for a while, but in the long run - it HAS to fail, or Java will fail with it

    Don't you think that this might be a little bit of an overstatement. The entire future of Java depends on the use or otherwise of a single web framework??
    the main problem of JSF is not what it does not allow but how much it allows and how bloated it has become because of it.

    JSF is simple to use. It really is. A few tags on a page, a backing bean and some navigation XML. That is all you need. So much of the work is done for you by the components - conversion, presentation, validation. The richness of the JSF API for extenders and component developers has no bearing whatsoever on what the average developer has to do to get web pages up. As a very average developer myself, I see no bloat at all.
  305. JSF would NEVER made it, if big vendors did not support it so much. It will help for a while, but in the long run - it HAS to fail, or Java will fail with it
    Don't you think that this might be a little bit of an overstatement. The entire future of Java depends on the use or otherwise of a single web framework??
    And I think that shows the big problem with many people's [limited] thinking. There are quite a few people who have developed Java for years, and have not developed a UI. Some have developed Java UIs and have not not done it with Web technologies. Web UIs are a subset of what is being done with Java. That is why Rails or anything like it won't replace Java. Sure Rails is neat and cool and maybe a fast way to create an Web App. But what about those of us who don't do web apps, but rather do apps the might have a web UI?
  306. JSF would NEVER made it, if big vendors did not support it so much. It will help for a while, but in the long run - it HAS to fail, or Java will fail with it
    Don't you think that this might be a little bit of an overstatement. The entire future of Java depends on the use or otherwise of a single web framework??
    Sorry, you are right. I should have been more specific.

    What I meant is: if the big vendors continue to push JSF, the, due to its bloatedness (IMHO) serverside/web part of Java will be greatly harmed and there is a chance it may be entirely dropped by developers in favor of much more agile web technologies, like the ones RoR is perceived to be, nowdays.

    Steve, first - I appreciate your humbleness but I doubt you are really an average developer :) Second, if I am not mistaken, you have been using JSF for quite a long time. So you must be feeling very comfortable in it and hence may not be noticing how much easier life could have been if JSF was not bloated. One example: I really do not like that Java frameworks, generally, are so heavy on XML. A lot of things do not need configuration at all, defaults would do just fine, and for the rest - XML may not necessarily be the best way (e.g. for validation).

    At least, this is my oppinion. I may be very wrong, of course.
  307. JSF would NEVER made it, if big vendors did not support it so much. It will help for a while, but in the long run - it HAS to fail, or Java will fail with it
    Don't you think that this might be a little bit of an overstatement. The entire future of Java depends on the use or otherwise of a single web framework??
    Sorry, you are right. I should have been more specific.What I meant is: if the big vendors continue to push JSF, the, due to its bloatedness (IMHO) serverside/web part of Java will be greatly harmed and there is a chance it may be entirely dropped by developers in favor of much more agile web technologies, like the ones RoR is perceived to be, nowdays.
    It is not just 'vendors' who are pushing it. One of the main implementation is MyFaces - an Apache project. You could hardly getter better 'open source community' credentials. I also don't get the 'agile' argument. It seems no more or less agile than any other web framework. It is certainly no less agile or bloated than struts, which is still very popular and looks like it will have an interesting future. Do you think continued use of Struts would harm Java?
    Steve, first - I appreciate your humbleness but I doubt you are really an average developer :)

    Oh I am - trust me.
    Second, if I am not mistaken, you have been using JSF for quite a long time. So you must be feeling very comfortable in it and hence may not be noticing how much easier life could have been if JSF was not bloated. One example: I really do not like that Java frameworks, generally, are so heavy on XML. A lot of things do not need configuration at all, defaults would do just fine, and for the rest - XML may not necessarily be the best way (e.g. for validation).At least, this is my oppinion. I may be very wrong, of course.

    I like JSF perhaps because years back I used struts. JSF seems a LOT lighter by comparison. However, I really don't see what is bloated about it - the information you have to give to get things working is minimal. By no standards is it particularly heavy on XML; at least not in my experience. What XML there is, is designed carefully to give JSF an additional advantage that seems have been neglected here - integration with IDES.
  308. By no standards is it particularly heavy on XML; at least not in my experience. What XML there is, is designed carefully to give JSF an additional advantage that seems have been neglected here - integration with IDES.

    Yeah and you can still reduce it using Struts Shale tiger extensions wich is very cool :)
  309. I also don't get the 'agile' argument. It seems no more or less agile than any other web framework.

    Should have read 'no more or less agile than any other Java web framework.
  310. [JSF] seems no more or less agile than any other web framework. It is certainly no less agile or bloated than struts
    JSF must be more agile for development simply because it has tool support. Create a page, choose component, drop onto a page, change couple of properties, wire up events and here you are, in the same nirvana as ASP.NET guys have been for a while and where Delphi/VB guys has been forever. Struts development is extremely slow if one does not have action or JSP bits to combine together and does not know all Struts quirks.

    On the other hand, Struts allows to be as close to HTTP as possible, while providing some input processing/validating/error handling support. The choice depends from whether you like small bricks (Struts) or large room-sized units (JSF). The benefit of the small brick approach is that you can have your toilet in solid gold and put it right in the middle of the living room.

    ---
    Michael Jouravlev
    JSP Controls: Create page components with JSP
  311. problem is lack of information[ Go to top ]

    i recently finished a mid-size project using JSF. i found a lot of strange things along the way, but i stuck with it. the biggest problem was not the oddities of the framework, but the lack of info about these oddities. i had a heck of a time finding how to get around them. in many cases, i still don't fully understand whether the problem i experienced is a bug, expected behavior, or a problem with my code.

    here's an example: from an action method, if i add a message using JSF's message facility (addMessage()) the message is only reported through the h:message tag if i'm using session scope in the bean where i called addMessage(). if i use request scope, the message is lost. this seems like a bug to me. such fundamental behavior should not change based on the scope setting. however, i found a few posts trying to explain that this is expected behavior and has to do with the JSF lifecycle. well, okay ... but i never found an explanation on how to use the message facility if i'm using request scope. i never found anything saying i couldn't use the facility w/ request scope.
  312. lol, is it just me or almost every new api from sun is stupid? for example logging api and also jsf. i been using jsf and now i think that servlets are not so bad.
  313. compared a few[ Go to top ]

    Currently i am working for a world leader in telecommunications and for a joint project with another big player i also cant name, a team of 10 people (including me) evaluated webframeworks for our new product (currently it relies on Struts1). Before we started that, we knew that it will most likely be JSF because its so much easier to pass productmanagement when saying "we use JSF, a Sun standard". We evaluated the following Frameworks by doing HANDS-ON projects for each of them. Our budget for that was most likely bigger than real project budgets (not just evaluation) in smaller companies: MyFaces, JSF RI, Oracle ADF, IceFaces, Tapestry, Wicket. Furthermore we investigated in Struts2 and Spring-MVC without hands-on. The summary for JSF was quite dissapointing. WE are still not sure what to use but at the moment there are only 2 players left, MyFaces and Wicket. We thought it would be an easy win for JSF but in reality we found out that most of the JSF implementations with its component libs are in a bitter state. Compared to the "believed" market share of JSF, the libs are just crap. Technically we found wicket far superior from its ideas (same as tapestry but we have gripes with the market share and developer community) but it would be an uphill battle for us with product management. If Wicket would be some kind of standard or de-facto standard, i believe it would be a win for Wicket. But politics is always an issue in big companies, but none of us 10 people (most with different backgrounds in web development) is really convinced of JSF. But perhaps it will win anyway, but this wouldnt mean anything wrt the quality. Marc Logemann http://www.logemann.org
  314. WE are still not sure what to use but at the moment there are only 2 players left, MyFaces and Wicket. We thought it would be an easy win for JSF but in reality we found out that most of the JSF implementations with its component libs are in a bitter state. Compared to the "believed" market share of JSF, the libs are just crap. Technically we found wicket far superior from its ideas (same as tapestry but we have gripes with the market share and developer community) but it would be an uphill battle for us with product management.

    If Wicket would be some kind of standard or de-facto standard, i believe it would be a win for Wicket. But politics is always an issue in big companies, but none of us 10 people (most with different backgrounds in web development) is really convinced of JSF. But perhaps it will win anyway, but this wouldnt mean anything wrt the quality.

    Marc Logemann
    http://www.logemann.org
    Wicket is now available for integration with Seam 2. It is not officially supported, however, by Redhat EAP/CSP as it is not (yet) part of the JBoss tech stack. We've been using JSF/Richfaces/Seam/EJB3 with JBoss AS 4.2 here for over a year now and have had very good success (after the initial steep learning curve). As far as bookmarkability, you can achieve this with Seam's and tags in your facelets (these components generate HTTP GET requests). If the JCP/JSR expert groups worked together in a more collaborative process for related technologies rather than siloed (e.g. JSF and EJB 3 expert groups could have worked together for better component integration, thus removing the managed beans requirement for JSF which Seam/Web Beans have achieved), we'd have less problems in the field with the implementations of the specs...
  315. I am currently working in a JSF project. When compared to Struts or Action based framework I don't find any additional features nor it simplifies the development. It is purely marketing strategy from Sun like EJB. My insight on JSF is: “Sun, Oracle, IBM and a few other vendors thought about making money on the user interface development framework like Struts. To benefit all of them, they came up with a component based framework where all of them can sell components to interact with their proprietary products.” http://venkatsadasivam.wordpress.com/2008/04/28/a-critic-view-on-jsf-framework/ http://venkatsadasivam.wordpress.com/2008/04/05/dont-let-hype-push-you-select-wrong-technologies/