The current state of JSF

Home

News: The current state of JSF

  1. The current state of JSF (74 messages)

    Matt Raible has posted his thoughts on the current status of JSF and also provides some interesting comparisons with the other frameworks that he has been using as part of his Spring Live and AppFuse work.

    Ultimately, he decides that JSF isn't meeting the demands of developers nor is it actually making web development any easier. The post has also raised some interesting comments from the readers of Matt's blog. So is JSF DOA? Or can tool vendors still pump some life into the JSF market place?

    Click here to read more

    Threaded Messages (74)

  2. The current state of JSF[ Go to top ]

    So is JSF DOA?
    I have heard this term before too. What is DOA?
  3. DOA = Dead On Arrival[ Go to top ]

    What is DOA?
    DOA = Dead On Arrival
  4. .NET ?[ Go to top ]

    I've been a Java programmer for about 5-6 years now (ever since I left school). The learning curve to understand everything Windows was too high for me. Never had the time nor the motivation.
    Maybe now is the time for me to make the switch, Considering
    a) C# has a low barrier to entry for me
    b) There are a lot of 'enterprise' apps that need to server 500-1000 users. The 64-bit Itanium processor based windows machines should be able to handle that.
    c) JSF, and Swing (eventhough I've worked with it for 2-3 years) pretty much sucks compared to what you can do with windows.
    Sniff... I don't want to go over to the dark side....
    flames????
  5. re: .NET ?[ Go to top ]

    I was a professional Java programmer for about 4 years. For the last 1.5 years I've been doing ASP.NET with C#, so I think I have a decent perspective.

    C# the language is not that bad. It has its warts, but in general is ok. (Class libraries need some work, there are some bad semantics in things like value types and properties.)

    On the other hand the ASP.NET model is just plain aweful. The Page Controller model is totally unsuitable for anything but the most simple application scenarios. While it's true that you don't HAVE to use the Page controller model, doing anything else requires you to jump through major hoops. They based their architecture on an overly-simplified application scenario, which means that in many ways it lacks the flexibility to do better things.

    JSF has some of the things that ASP.NET gives you in terms of element level validation, drag-n-drop GUI building and the like. But it has the distinct advantage of being able to co-exist with high quality web frameworks (Spring, WebWorks, Struts, etc) that allow for strong separation of presentation from code.

    .NET is probably a really good language for developing Windows desktop applications. I find it wholey unsatisfactory for building high-quality (responsive, configurable, flexible) web applications.

    Anyway, that's my opinion.
  6. re: .NET ?[ Go to top ]

    .NET is probably a really good language for developing Windows desktop applications. I find it wholey unsatisfactory for building high-quality (responsive, configurable, flexible) web applications.Anyway, that's my opinion.
    I agree! I had a brief (9 month) contract developing an ASP.NET application and found it frustrating to do anything other than building simple forms. IMO, ASP.NET was designed to get desktop developers into web app development in an environment they're comfortable with, i.e. gui tools and event-based logic.
  7. .NET is probably a really good language for developing Windows desktop applications. I find it wholey unsatisfactory for building high-quality (responsive, configurable, flexible) web applications.Anyway, that's my opinion.
    For a (not that exteme) example of a responsive, configurable and flexible .NET application download DotNetNuke at http://www.dotnetnuke.com and with ASP.NET 2.0 stuff like that will get even easier to develop.
  8. it's alive[ Go to top ]

    Hi Matt,

    I don't agree with your "run away" statement so I'd like to go through some of your points after describing my experiences with, chronologically, JSF RI 1.0, JSF MyFaces, JSF RI 1.1 and - 1.1_01.

    I think it's important to make a distinction between the merits of JSF the specification and the implementations. For instance there's currently a JSF implementation in WSAD 5.1.2 by IBM and there's an upcoming JSF implementation in Oracle UIX 3.0.

    I recognize your frustration with MyFaces. We had simple stuff like navigating with a button that would work on some pages and not on others and we could not find out for the life of us what the crucial differences were. We did not get any response on the MyFaces mailing list and saw quite a lot of other unanswered questions. For a project virtually without documentation that is devastating. Maybe summer holidays explain the lack of respons on the mailing list...
    MyFaces has my sympathy, I think a solid open source implementation of JSF will be great but I wished I had not heeded the lyrical posts in the JSF forum. I saw the motivation of people in my team who worked with MyFaces dwindle very rapidly. And these were quite experienced J2EE web developers. In my experience MyFaces is not ready for a project with a tight deadline to achieve.

    Sun has been quite slow with JSF RI 1.0 in fixing bugs and communicating about them. Since JSF RI 1.1 though, bugs can be found in Sun's bug parade and a crucial bug in JSF RI 1.1 could be found fixed in a weekly build of JSF RI 1.1_01.
    So this is a very positive change. I hope Sun will continue this since it makes a tremendous difference in the way JSF (RI) will be viewed.
    Saving state on the client results in enormously long URLs and/or hidden fields
    Well, you can't have it both: either your keep your state on the server or you'll have to transfer it between the browser and the server.
    JSF support is fairly non-existent.
    As I mentioned my experiences with MyFaces mailing list weren't positive either but the JSF forum is quite useful: you get responses from people like Ed Winer, Kito Mann, Horst Caymann, Hans Bergsten (at least when they were writing there books) and Craig McClanahan. And there are the books of course. At the moment there are 3 books that I know of that refer to the final version of JSF. That's quite good.
    The MyFaces website seems to be down whenever I want to look something up
    True, some wiki problem I think. But not something that reflects on JSF.
    But I was disappointed to find that i18n is not considered [...] 6 lines of code to set a success message
    I studied a Util class from the sources of the JSF RI and used a similar set of convenience methods to create i18n messages. Now it takes 1 line to set such a message.
    So I would not consider that a major defect...
    Waiting for JSP's to compile the first time has surprisingly become painful after using Tapestry
    Well, that's true of course, although this compilation will result in better performance. The age-old discussion over the merits of compiled/static languages vs interpreted/dynamic languages. I like compiled/static java. I don't cheer while JSP's compile but I DO like the fact that the JSP compiler of jDeveloper, the IDE we must use, tells me immediately about syntactical errors. So that's quite speedy feedback on the other side. But tastes differ and dynamic languages are in fashion.
    Integration with Spring [...] MyFaces spits out an error
    Again not a point on JSF itself.
    Validation messages are ugly.
    We had to change them anyway since our application is in dutch. The tekst can be formatted in the same way as with a MessageFormatter. Very familiar, suits my needs. The look of the validation messages can be changed with CSS. I don't see your problem.
    The <h:messages> tag is practically worthless.
    It is not to us. See my response to the previous remark. But I've seen a lot of posts on customizing <h:messages/>. I did not study these so I can't comment on the ease of doing this. But on the whole I think JSF is quite easily extended with all the extension points like PhaseListeners, Validators, Converters, etc.
    The <h:dataTable> component is nothing like the displaytag. MyFaces claims to have a pageable/sortable component, but it requires custom logic/methods in your managed-bean.
    Another developer has been working with h:dataTable so I can't comment.

    The last point is again a problem with MyFaces

    For a weblog this critique is fine of course. But for the ServerSide I think it quite shallow and lacking in substance.

    My reaction is meant as another voice among the very fashionable Sun/J2EE bashing. I do hope JSF will be a success. I think it's a great improvement over the previous, de facto, standard and I like standards since I work for so many clients.
    But buggy framework implementations are always a turnoff, not to mention costly in development.

    groeten uit nederland,
    Joost de Vries
  9. The current state of JSF[ Go to top ]

    I see a problem with any technology that requires a tool, especially a GUI tool, to make it usable. How many times do we have to learn that developers are more productive when they can get at the source code and do things by hand? The answer is not more complex solutions with fancy GUI tools to make them usable, it's the power of simplicity and the beauty of tools built to be both simple to use and powerful. As has been said many times, abstractions leak, and eventually you find yourself down in the code / configuration built by the big GUI tool for you, trying to understand something that wasn't designed for people to look at.
  10. The current state of JSF[ Go to top ]

    You don't need a tool but I'm sure in time it will help alot. Take a look at asp.net, If java want's to compete with that you need something like jsf.
    sun's studio creator is decent already and it will probably improve. Get a book on it and start playing arround.
  11. The current state of JSF[ Go to top ]

    Take a look at asp.net, If java want's to compete with that you need something like jsf.
    What I see happening is that non-gurus are literally driven off by the complexity and weirdness of JSF (and JSP custom tags and JSP expression language). The Java community is off on ivory tower framework tangents and losing sight of the simple elegance principles behind Java. Rather than competing with ASP.NET the web applications infrastructure is making Java LESS competitive and giving Microsoft a free ride with their existing developer customers who cannot begin to fathom what the heck is going on in Java web app land.

    Paul Copeland, JOT Object Technologies - http://www.jotobjects.com
  12. The current state of JSF[ Go to top ]

    I woulden't call myself a guru but still find jsf really easy to work with compared to things like struts. I have a total of 2 years of programming experience and only worked with jsf about a month... so you could argue that im not experienced enough to spot the flaws, but neither can someone who only spend a few days on it.
  13. The current state of JSF[ Go to top ]

    What I see happening is that non-gurus are literally driven off by the complexity and weirdness of JSF
    I disagree. I think most newbies like JSF (and EJB) while the guru's just shrug and keep doing Struts (or JDNC)
    .V
  14. No[ Go to top ]

    You don't need a tool but I'm sure in time it will help alot. Take a look at asp.net, If java want's to compete with that you need something like jsf.sun's studio creator is decent already and it will probably improve. Get a book on it and start playing arround.
    No, you cannot beat Microsoft at its own game. That just ain't going to happen! Msft caters to a certain part of the market with asp.net, sure jsf targets the same audience framework-wise, but remember that Visual Studio.NET is what "they" have, do you honestly see a competing tool on the java market anytime soon? Both eclipse and idea take the CodeWay to creating solutions.
  15. No[ Go to top ]

    No, you cannot beat Microsoft at its own game. That just ain't going to happen! Msft caters to a certain part of the market with asp.net, sure jsf targets the same audience framework-wise, but remember that Visual Studio.NET is what "they" have, do you honestly see a competing tool on the java market anytime soon? Both eclipse and idea take the CodeWay to creating solutions.
    There is Ide's on its way...if they can match the gui development in asp.net
    I dont know and i don't think its the most important issue.
     
    What is important is that not everybody wants to do it the codeway and the option should be avalible to go the gui way.
    With jsf you will have both options.

    Here are som of them.
    http://www.jamesholmes.com/JavaServerFaces/#software-gui
  16. CodeWay[ Go to top ]

    do you honestly see a competing tool on the java market anytime soon? Both eclipse and idea take the CodeWay to creating solutions.
    The Eclipse Visual Editor <<a href=""http://www.eclipse.org/vep/"" target=""_blank">http://www.eclipse.org/vep/</a>>" works="" pretty="" well="" for="" my="" rich="" clients="" (swing).="" the="" "codeway"="" came="" first,="" guiway="" comes="" next="" :]="" let's="" have="" a="" fresh="" look="" on="" what="" jsf="" can="" do="" our="" thin="" clients.<br="" rel="nofollow">
    <
  17. CodeWay[ Go to top ]

    sorry, that was my first post here :)
    do you honestly see a competing tool on the java market anytime soon? Both eclipse and idea take the CodeWay to creating solutions.
    The Eclipse Visual Editor http://www.eclipse.org/vep/ works pretty well for my rich clients (Swing). The "CodeWay" came first, the GuiWay comes next :] Let's have a fresh look on what JSF can do for our thin clients.

    http://www.Stormlight.de
  18. The current state of JSF[ Go to top ]

    I see a problem with any technology that requires a tool, especially a GUI tool, to make it usable. How many times do we have to learn that developers are more productive when they can get at the source code and do things by hand? The answer is not more complex solutions with fancy GUI tools to make them usable, it's the power of simplicity and the beauty of tools built to be both simple to use and powerful. As has been said many times, abstractions leak, and eventually you find yourself down in the code / configuration built by the big GUI tool for you, trying to understand something that wasn't designed for people to look at.
    Then why exactly did Microsoft, and VB, get a reputation for being dead easy, by virtue of being all drag-and-drop, and that reputation translate into a solid business? I believe they're not even talking about developers like you when they design GUI-based tools.
  19. The current state of JSF[ Go to top ]

    I see a problem with any technology that requires a tool, especially a GUI tool, to make it usable. How many times do we have to learn that developers are more productive when they can get at the source code and do things by hand? The answer is not more complex solutions with fancy GUI tools to make them usable, it's the power of simplicity and the beauty of tools built to be both simple to use and powerful. As has been said many times, abstractions leak, and eventually you find yourself down in the code / configuration built by the big GUI tool for you, trying to understand something that wasn't designed for people to look at.
    Then why exactly did Microsoft, and VB, get a reputation for being dead easy, by virtue of being all drag-and-drop, and that reputation translate into a solid business? I believe they're not even talking about developers like you when they design GUI-based tools.
    Right, I build enterprise applications. That's what the first "E" in J2EE stands for. If you're building the equivalent of a VB one-off app for the web, then use PHP or something. If you're building an enterprise application and you want reuse, componentization, etc. then choose a framework that's built for that. I don't see where JSF fits into either case. Being a standard doesn't make something good, and it's time people finally learned that.
  20. The current state of JSF[ Go to top ]

    Being a standard doesn't make something good, and it's time people finally learned that.
    Being a standard doesn't make something bad. Just because entity beans were a failure doesn't mean every JCP spec is.
    If you're building an enterprise application and you want reuse, componentization, etc. then choose a framework that's built for that. I don't see where JSF fits into either case.
    JSF fits perfectly in both cases.
  21. The current state of JSF[ Go to top ]

    I think JSF is not so suitable without the GUI tools. For example in Sun&#8217;s Studio is looks no so bad

    Marina
    http://www.servletsuite.com
  22. The current state of JSF[ Go to top ]

    I think JSF is not so suitable without the GUI tools.
    I disagree with this opinion. This opinion is a result of incredible marketing push that said "we are going to create a revolutional VB-like tool that will save java community from the java code". The side effect of this push is a meaning that the jsf technology cannot be understanded and used without GUI tool.
    In my opinion the jsf is a very easy-to-learn technology. It is several times easier than, for example, Struts. JSF Expert team made a very great job. Even for the truly first version, jsf has a very elegant extendable architecture. However, when the theory met practice, some out-of-scope issues became very important for the first-bird developers which work in the situation when the best-practice solutions knowledgebase is not available yet. In this situation, developers try to look at the new technology thru the already existent experience (that is very natural). This causes the problem, because the jsf does not strongly step after the existent technology like Struts. For example, they try to use jstl when the standard jsf custom tags do particular job, they try to overuse the standard tags instead of writing the suitable ones, they try to still use pure html layout instead of visual components approach.
    I think, it is because of information missing. From our side, we try to cover this gap with providing the necessary information for people who want to learn JSF (http://www.JSFTutorials.net). There are some other very useful resources over the internet. I must to name JSFCentral.com, Java Server Faces Resources catalog provided by James Holmes, author of Faces Console, and, of course, the JavaServer Faces discussion forum. I hope, together we are able to distribute the knowledge that will help developers to use the powerful of JSF. Also, there are a number of book already available.
    Speaking, about the books. Reading them (except, probably one:-) you can realize: JSF is not about the tools, jsf is about the java.
    I believe, JSF is not DOA, it has a future. The expert group working on the next version of the JSF will accommodate the practical experience into the new specification (and, as best I know, they are already on their way).

    Regards,
    Sergey Smirnov
    Principle architect of Exadel JSF Studio
  23. The current state of JSF[ Go to top ]

    The expert group working on the next version of the JSF will accommodate the practical experience into the new specification (and, as best I know, they are already on their way)
    Yes, that's what they said about EJB, wait till next version. OK, we will see if a comitte can build sofware of just have a meeting.
    .V
  24. The current state of JSF[ Go to top ]

    Yes, that's what they said about EJB, wait till next version. OK, we will see if a comitte can build sofware of just have a meeting..V
    Live is characterized by the progress. Only death is stable.

    It is passed about a half of year when the very first jsf specification appears and the first implementation is done. In retrospective, did the Struts 1.0 was so powerful and well-known when it was the same age?
  25. The current state of JSF[ Go to top ]

    I believe, JSF is not DOA, it has a future. The expert group working on the next version of the JSF will accommodate the practical experience into the new specification (and, as best I know, they are already on their way).Regards,Sergey SmirnovPrinciple architect of Exadel JSF Studio
    Well, there was plenty of "practical experience" in building both web applications and web application frameworks out there, but they failed to make use of it for the first version, so why should we believe it will be any different for the second?
  26. The current state of JSF[ Go to top ]

    Well, there was plenty of "practical experience" in building both web applications and web application frameworks out there, but they failed to make use of it for the first version, so why should we believe it will be any different for the second?
    Interesting question ... and I suspect you won't like my take on the answer :-). I believe one of the keys to early adoption of JSF is that tools *do* exist to support it.

    Consider the history of Struts (which I am at least somewhat familiar with :-). In its early days, four years ago, it was technically innovative, and gained adoption from people who were coding "by hand". Yet it remains very popular today -- despite the fact that it has not evolved technically as fast as some of the other frameworks (hint: to many developers of enterprise applications, stability is a Good Thing, not a Bad Thing), it remains a defacto standard. Why? Because high quality support for Struts is built into nearly every Java oriented development tool you can find.

    I am personally comfortable writing raw Struts code using Emacs (and writing raw JSF code is pretty much in the same general area of complexity -- quite feasible but not necessarily fun). But, in terms of the overall community of developers, I'm pretty unusual -- there are lots more people who are either unable or unwilling to code by hand; but will be happy to use a technology that is assisted by tools. Either in little ways (GUI editors for configuration files), reduced workload ways (annotations that lead to code generation), or complete development experience ways (GUI design of pages and navigation between them). Given the demographics, then, it's hardly surprising that a big key to the ongoing popularity of Struts is the fact that a developer using it has a rich ecosystem of support.

    Several respondents in this thread have sneered at the idea of a technology that *requires* tools in order to be useful (JSF isn't that, but that is not the point), but they are missing something important. If your technology is *not* supported by tools, how popular (measured in terms of adoption) can it ever be -- given the demographics of the market size willing to write raw code on top of *any* framework? Even if you believe your technology is technically superior, the target market isn't going to be as big.

    After JSP came out, it took about three *years* for there to be reasonably useful tools to support it. Indeed, one could argue that even tools today haven't done all they could (in part because writing tools for pure JSP is still pretty difficult). In the three *months* after JSF went final, we saw announcements, and early deliveries, of tools of all sizes that support JSF, and a clear market direction that this will increase. To me, that's a good early indicator that JSF -- even the current initial version -- is going to get adopted early and often.

    Craig McClanahan
  27. The current state of JSF[ Go to top ]

    In the three *months* after JSF went final, we saw announcements, and early deliveries, of tools of all sizes that support JSF, and a clear market direction that this will increase. To me, that's a good early indicator that JSF -- even the current initial version -- is going to get adopted early and often.Craig McClanahan
    There's a lot of tool support for Entity Beans as well, and that's all I have to say on that.

    As for the guy asking if I use Hibernate instead of JDBC... Yes, I use Hibernate. And I've had to trace into Hibernate's code to figure out what was going on a few times and to find bugs in Hibernate a couple of times.

    No, I don't have to trace into the Collections classes too often, but those are significantly simpler than JSF or Hibernate, wouldn't you agree?
  28. The current state of JSF[ Go to top ]

    There's a lot of tool support for Entity Beans as well, and that's all I have to say on that.
    There has also been more adoption of entity beans than the anti-EJB crowd would care to believe :-).

    Craig
  29. The current state of JSF[ Go to top ]

    There's a lot of tool support for Entity Beans as well, and that's all I have to say on that.
    There has also been more adoption of entity beans than the anti-EJB crowd would care to believe :-).Craig
    thats bcuz entity beans came out before hibernate and what u call adoption is they are really stuck with it.
  30. The current state of JSF[ Go to top ]

    There's a lot of tool support for Entity Beans as well, and that's all I have to say on that.
    I can't see where ejb fits into this discussion. I've heard over and over again that ejb have som major problems. It's difficult to work with, difficult to test and so on...
    Jsf imo isnt difficult to work with. I dont really see the problems and if they are there they must be small and can probably be solved... where are the major problems in jsf?
  31. The current state of JSF[ Go to top ]

    I dont really see the problems and if they are there they must be small and can probably be solved... where are the major problems in jsf?
    web designer still remains unhappy...tough to change look and feel of a jsf component :(
  32. The current state of JSF[ Go to top ]

    I dont really see the problems and if they are there they must be small and can probably be solved... where are the major problems in jsf?
    web designer still remains unhappy...tough to change look and feel of a jsf component :(
    The web designer can apply CSS; what's wrong with that? (Maybe I'm missing your point)
  33. The current state of JSF[ Go to top ]

    The web designer can apply CSS; what's wrong with that? (Maybe I'm missing your point)
    U r speaking abt styling.(maybe i shudnt have said look and feel)...lets say, he wanted to rearrange the sub-components that make up the component, or any other html changes (stuff that doesnt go into css).
  34. Yeah[ Go to top ]

    I see a problem with any technology that requires a tool, especially a GUI tool, to make it usable. How many times do we have to learn that developers are more productive when they can get at the source code and do things by hand? The answer is not more complex solutions with fancy GUI tools to make them usable, it's the power of simplicity and the beauty of tools built to be both simple to use and powerful. As has been said many times, abstractions leak, and eventually you find yourself down in the code / configuration built by the big GUI tool for you, trying to understand something that wasn't designed for people to look at.
    Amen to that!
  35. JSF Misonception[ Go to top ]

    It is a common misconception that JSF is not usable without specialized tools so before reciting what you read give JSF a try and come up with your own informed opinion.
  36. Yeah[ Go to top ]

    I see a problem with any technology that requires a tool, especially a GUI tool, to make it usable. How many times do we have to learn that developers are more productive when they can get at the source code and do things by hand? The answer is not more complex solutions with fancy GUI tools to make them usable, it's the power of simplicity and the beauty of tools built to be both simple to use and powerful. As has been said many times, abstractions leak, and eventually you find yourself down in the code / configuration built by the big GUI tool for you, trying to understand something that wasn't designed for people to look at.
    Amen to that!
    Yes, there is no meaning to invent technology and a tool to fight with this technology.
  37. Let give JSF a chance .....[ Go to top ]

    I see a problem with any technology that requires a tool, especially a GUI tool, to make it usable. How many times do we have to learn that developers are more productive when they can get at the source code and do things by hand? The answer is not more complex solutions with fancy GUI tools to make them usable, it's the power of simplicity and the beauty of tools built to be both simple to use and powerful. As has been said many times, abstractions leak, and eventually you find yourself down in the code / configuration built by the big GUI tool for you, trying to understand something that wasn't designed for people to look at.
    How many times do we have to learn that developers are more productive when they can get at the source code and do things by hand?
    Do you have to get into Josh's Collection framework source code to take advantage it? So you do believe in authoring the entire HTML page by hand, do you? Come on! Good programer write QUALITY CODE, and not QUANTITY CODE. Smart programer write LESSER CODE, or might not have to write any code at all. For example Hibernate, do you still prefer writing your own JDBC code or let Hibernate taking care of all the repetive works for you?
    abstractions leak
    It leaks because you have a false abstraction in your model. Or may be what you try to abstract out should be an Aspect and so AOP is needed to help you solve the problem.

    Let face it! No particular framework are supperior and flawless since it induction. Struts is no exception. I've use Struts/Tiles from its very begining and still making a living off it now. The more I do with Struts the more I believe standard is needed, and so tool can be make to help deverloper to be more productive. And that's why JSF exist. JSF has its potential, otherwise Craig wouldn't lead the spec team. Lets give it a chance and explore its potentials.

    I have not look at Tapestry, and I almost finish Geary's Core JSF book. If you want to dicuss in detail on why I think JSF has it potential and that both JSF/Struts/Tiles can compliments each others you can reach me at danny dot trieu at nmetric dot com or we can start a different Thread.

    Thanks,

    --danny
  38. The current state of JSF[ Go to top ]

    I was going through a similar exercise as Matt just days before he posted his thoughts. I was able to get a very simple JSF application running.

    But, while writing this simple app, I'm thinking: (1) JSF is counter-intuitive to me. (2) I like the event model, but isn't this something like Tapestry? And (3) How does this make things easier?

    And I recall being told that JSF is to Tapestry what JDO is to Hibernate.
  39. The current state of JSF[ Go to top ]

    (1) JSF is counter-intuitive to me. (2) I like the event model, but isn't this something like Tapestry? And (3) How does this make things easier?And I recall being told that JSF is to Tapestry what JDO is to Hibernate.
    Tapestry is counter-intuitive to me too. And I think it's to Matt Raible too.
  40. The current state of JSF[ Go to top ]

    (1) JSF is counter-intuitive to me. (2) I like the event model, but isn't this something like Tapestry? And (3) How does this make things easier?And I recall being told that JSF is to Tapestry what JDO is to Hibernate.
    Tapestry is counter-intuitive to me too. And I think it's to Matt Raible too.
    Check out WebWork :-)
  41. The current state of JSF[ Go to top ]

    Just a thought: I am playing now with eXo platform and eXo guys claim that use of JSF allowed them to decrease codebase by 60% and they do not seem to use any GUIs…
    I like eXo architecture, capabilities and potential but it does not seem to be performant……

    About Tapestry: it is not very intuitive for me as well as JSF. I found ECHO framework to be VERY intuitive and convenient for coding, but it has some problems too :(

    Dream: develop portlets with ECHO, deploy them on eXo and have performance of Tapestry
  42. The current state of JSF[ Go to top ]

    Our experience with Tapestry here in Mexico is that it's the best framework we have tested, by far.

    I don't know why Sun lost it's vision with JSF, maybe because they don't want to loose JSP technology.

    Get in touch with Tapestry and you'll never look back.
  43. No JSP Necessary[ Go to top ]

    You do not need JSP AT ALL to work with JSF. Granted it seems to be Sun's preferred templating method, but nontheless, it is in no way necessary to use JSF.

    There is an article on the web somewhere (I think it's on OnJava.com maybe http://www.onjava.com/pub/a/onjava/2004/06/09/jsf.html) by Hans Bergsten that discusses this very topic, with examples.
  44. No JSP Necessary[ Go to top ]

    Sure you don't. So, let's see... I want to start developing a JSF app now, without using JSP. Hmmm. Where do I start? Ooops, need to make an view implementation for another templating method first. JSF and JSP will be a tight pair until there is at least one working alternative implementation. I considered starting up such an implementation, but decided that it is just too much work, especialy as it should be kept in sync with both the (still developing) specs and component implementations.
  45. The current state of JSF[ Go to top ]

    I think JSF has very good and solid achitecture if you take into account the portability and extensibility. We use jsf as the foundation for our portal and thank to it , We can integrate and support other technology (struts, velocity, cocoon, xhtmlmp - see our portal on mobile browser http://www.exoplatform.com/xwiki/bin/view/Main/mobileportalconfiguration) in very short time with minimal work. I am pretty sure that we can extend and support other technology such rich client site scripting language XUL , XAML when they are mature. The only problem I see with JSF is to use jsp to assemble the UIComponent , but maybe I am wrong since I am not newbie and I never break OO design.

    Konstantin Ignatyev,

    Do you run any load test one exoplatform, I would like to know how do you run the test and your configuration. You need reconfigure some aspect of exo to get the best performance such the cache size. I belive that using myfaces instead of sun RI will make a lot of different as well.
  46. The current state of JSF[ Go to top ]

    Konstantin Ignatyev,Do you run any load test one exoplatform, I would like to know how do you run the test and your configuration. You need reconfigure some aspect of exo to get the best performance such the cache size. I belive that using myfaces instead of sun RI will make a lot of different as well.
    No, I did not run load tests and my judgment is subjective and based on demo of exo running on my computer – it is far from being snappy. Same is applied to eXo web site- it feels slower than Struts/Tapestry based sites not to mention pure html sites.

    MyFaces: I work on GNU-Linux machine and I cannot even compile exoplatform on it yet: Maven (sucks) does not seem to resolve all dependencies and I had to compile projects individually and now I am in the process of figuring out the right sequence.

    eXo feature request: it would be nice if file/resource explorer had a command to create a page out of selected (html) file.
  47. Konstantin,

    We have about 8000 pages view per day and the response time is about 45ms which is not bad for a dynamic portal. Of course it is more than html static files but should not be different from Struts/Tapestry based sites.

    We put your requested feature on our TODO list :)

    The eXo Platform is actually one of the biggest aplication that uses JSF and we have been developing with JSF for more than a year and a half now. We were all using Struts and Webwork before moving to JSF and are very happy with our choice.

    There are several ways to use JSF (as we explain in our last article) and we think that building the JSF UIComponent tree from the JSPs is clearly not the best approach.

    I think that most people that complain about JSF have actually not really use it and are affraid to test it. As any new paradigm the learning phase is quite long and people do not want to face a new model change after being told for many years that MVC type 2 and JSPs were the nirvana.

    From our experience the JSF paradigm allows you to be more productive by writing less code and reusing it. That is not an opinion, that is a fact.

    Benjamin
  48. eXo[ Go to top ]

    Konstantin,We have about 8000 pages view per day and the response time is about 45ms which is not bad for a dynamic portal. Of course it is more than html static files but should not be different from Struts/Tapestry based sites.
    Benjamin, it is hard to argue with statistic :) ( there is lie, big lie and statistic ) – but I still feel that page rendering is much slower than that, probably because you measure one thing – an html response, but in order to display the entire page browser have to make tons of additional calls to get css, images, javscripts. Those things might significantly affect overall performance…. Just make clicks on items in the left side menu (just html portlet pages) and you will probably notice that response is not quite adequate ( not as fast as you would expect from such a ‘simply’ operation )

    PS: I am still planning to use eXo in one of our projects and considering buying a license, so please consider my critique as an attempt to improve eXo.
  49. eXo[ Go to top ]

    Do you use IE browser and experience the same slowness. I use mozilla firefox and look like the css is resent for every request while they are supposed to be cached on the browser.

    Tuan Nguyen
    www.exoplatform.com
  50. There is a framework that has a visual editor for every java IDE, really easy to use, totally object oriented, mvc architecture, handles pure html files as templates, does not need a lot static xml configuration files, has component refreshing (partial updates), powerful validation framework (similar to .NET), page state management (similar to viewstate), has an abstract UI layer that hides all web specific problems, skinable components....
    WebOnSwing (http://webonswing.sf.net) - Multiple Environment Application Framework is an open source project distributed under LGPL license.
  51. eXo[ Go to top ]

    Do you use IE browser and experience the same slowness. I use mozilla firefox and look like the css is resent for every request while they are supposed to be cached on the browser.Tuan Nguyenwww.exoplatform.com
    Hmm, it feels faster in IE, but I never use IE for web browsing unless I am forced to do so.
    My speculations: I have high confidence in Mozilla and there are many sites that work faster in Mozilla than in IE, so, could it be that eXo returns something in HTML header that makes Mozilla believe that it should not cache and needs to retrieve stuff again.
    IMO Mozilla is more spec compliant and IE just buggy and could ignore such flags.
    I vaguely remember examples of using such feature to prevent caching of dynamically server side generated images.
    I could be wrong...
  52. eXo[ Go to top ]

    Hi!

    Both IE and Mozilla change the way they render HTML/XHTML depending on doctype declaration, so they behave in standard compliant mode or quirk mode, the last one misbehaving like older versions. So if you change the DOCTYPE declaration from HTML 4.0 transitional (the default) to XHTML strict or transitional, the way both browsers render the page is different. Hope this information helps.

    Cheers
  53. IE version can also be vital[ Go to top ]

    Windows IE 5.5 SP2? and earlier has a nasty habit of reloading styles and scripts in response to a POST. From SP3 onwards they appear to be cached as per the headers.
  54. eXo[ Go to top ]

    No offense at all (even if you don't buy a license :) )
  55. Growing Pains...[ Go to top ]

    Basically, most of the problems identified are simply a question of not having spent enough time with JSF.

    e.g. "Every button or link clicked results in a form post. That's just wrong - why can't I have true links like the web is supposed to? So much for bookmarks."

    Well, of course, you can put a link in. You can also mark a target with the redirect tag, which gives you bookmarking.

    I've been quite happy with the Sun forums, several people have been very responsive (e.g. Val). A lot of people on the forums are newbies, so there is a bit of a blind-helping-the-blind.

    A *LOT* of the other issues are particular to MyFaces, so blaming JSF for implementation details (e.g. the MyFaces website is down) seems a bit of a reach.

    Don't get me wrong, I'm sure there are problems, etc. But, blaming JSF for a lot of these problems seems incorrect.

    Here's my big issue: all of these various frameworks simply aren't supported (or supportable) by the various tool vendors. This isn't just an issue of GUI-vs-non-GUI - I would love to have much better support for JSF in the non-GUI capabilities of Eclipse, NetBeans, Creator, JDeveloper, JBuilder, etc. For example, auto-completion of the various expression language[s], or the ability for the refactoring engines to touch the presentation layer. Unless we standardize on a single framework, we will never get the tools.

    The worst part is that out of sheer desperation we all learn the foibles of these different frameworks, but we are now left with Babel. We *need* JSF, and we need to build on JSF, to move forward.

    Cheers,

    -Will
  56. A Reply to Matt's Rant[ Go to top ]

    David Geary, author of Core JSF, replied on his blog to this rant.
    http://jroller.com/page/dgeary/20040809

    You also should take into consideration that Matt only spent three days with JSF.
  57. A Reply to Matt's Rant[ Go to top ]

    David Geary, author of Core JSF, replied on his blog to this rant.http://jroller.com/page/dgeary/20040809You also should take into consideration that Matt only spent three days with JSF.
    You should keep in mind that he was able to get this working spending 3 days or less with other frameworks.
  58. A Reply to Matt's Rant[ Go to top ]

    You should keep in mind that he was able to get this working spending 3 days or less with other frameworks.
    Getting something working in three days doesn't reflect on the power of a framework. If that was the case Java based frameworks would fail miserably in comparison to PHP or Python based frameworks where you can have CRUD operations implemented in hours not days.
  59. A Reply to Matt's Rant[ Go to top ]

    If that was the case Java based frameworks would fail miserably in comparison to PHP or Python based frameworks where you can have CRUD operations implemented in hours not days.
    Struts + Tiles + Hibernate + Xdoclet + Ant + Intellij-IDEA = end-to-end CRUD+L functionality in a matter of minutes.

    Problem: low level of reusability, for example I cannot create person CRUD+L component and reuse it...
  60. A Reply to Matt's Rant[ Go to top ]

    If that was the case Java based frameworks would fail miserably in comparison to PHP or Python based frameworks where you can have CRUD operations implemented in hours not days.
    Struts + Tiles + Hibernate + Xdoclet + Ant + Intellij-IDEA = end-to-end CRUD+L functionality in a matter of minutes.
    Ouch! That hurts. We do some development with the formula above stated and our mileage varied a lot:

    Choose your Struts web app template, otherwise, you should copy the JARs, include in taglib declaration in JSPs, etc in order to setup the Struts app, define/generate ActionForms and actions, set ANT_HOME, JAVA_HOME, don't forget the merge directory for XDoclet because you're using customized templates of course, and tell Eclipse/IDEA about your project layout. Ah! I almost forget a customized struts Action, so we can have some of functionality ala WebWork. Hmmmm, I believe I'd already had something done in PHP. Of course once you have the right setup, things happen very quickly, but then, it shouldn't be possible also with JSF? Are we measuring initial setup time or gains in productivity in the mid term?

    Cheers
  61. A Reply to Matt's Rant[ Go to top ]

    Of course once you have the right setup, things happen very quickly, but then, it shouldn't be possible also with JSF? Are we measuring initial setup time or gains in productivity in the mid term?Cheers
    I did not count setup time and have implied that the project in question is not first project that a developer does with mentioned technologies.
    And setup time is quick. Basically it is a copy of some previous similar project with emptied source, test_source and web directories. Setting up IDEA project is about 1 minute (provided that global libraries were configured in previous projects).

    I also implied that struts <nested> tag is heavily used.
  62. A Reply to Matt's Rant[ Go to top ]

    I did not count setup time and have implied that the project in question is not first project that a developer does with mentioned technologies.
    As a mater of fact, thats the same strategy I follow for each new project. That's just that I agree with the person that wrote "Getting something working in three days doesn't reflect on the power of a framework" I believe it depends if it's your first project or not.
    And setup time is quick. Basically it is a copy of some previous similar project with emptied source, test_source and web directories. Setting up IDEA project is about 1 minute (provided that global libraries were configured in previous projects).I also implied that struts <nested> tag is heavily used.
    Yeap! I've dreamed with a personal Ant script that automagically sets up a Struts/Tapestry/WebWork project with dependencies.

    Cheers
  63. JSF[ Go to top ]

    We have several pure JSP enabled applications, 2 Struts-Enabled application, and we are currently building a large in-house JSF application. We're moving from Struts to JSF because of its elegent event model, and we found it is far easier to learn than frameworks like Struts -- this is important because many of our developers are from M$ world.

    BTW, we are currently evaluating Sun's Studio Creator for JSF, it looks nice & straighforward : )
  64. HTML and browsers are great for "browsing" and navigating content, but part of the problem is that developers try to push these frameworks into realms that go well beyond browsing content.

    Essentially these frameworks try to extend the concept of dynamic content generate to concepts such as MVC and rich application state management. It is possbile to do (and people do it) but there is an inhertently impedance missmatch for all involved from developers to users. The disconnected and limited world of web browsers and web servers was never made for this. When will people acknowledge this and move on - it is no longer 1996.

    Frameworks like JSF Struts and Tapestry should limit themselves to dynamic content generation and form submission type functionality. A seperate non browser framework needs to be developed for applications that go beyond. How many HTML centric Web GUI frameworks will we have to live through before we wake up from this bad dream.

    -Sam
  65. Enthusiastically agree with the subj.
    A seperate non browser framework needs to be developed for applications that go beyond.
    I know severeal:
    1st – good old XWindow, I enjoy running whatever I want/need across net;
    2nd- Swing applets via Java Web Start, they could do much better than portlets if ….
    3rd- Swing applications via Java Web Start.
    ( 4th- a desktop application that uses CORBA / or weaker replacements like RMI or SOAP/ to communicate with server. )

    XUL – seems like wrong approach to me, see XUL threads and my posts there for reasons
  66. I must say when I fist started to look at JSF about a year and 1/2 ago I was pretty excited but that excitement turned to disappointment pretty quick. In my opinion JSF was supposed to ease development of an MVC2 architecture as well as provide reusable easily build able rich UI components. In my opinion this is not the case at all and the underlying architecture is no better then what is currently out there in open source projects. In fact the underlying model and view components frameworks may differ per application depending on what type of application you are developing. I was looking for struts to really ease my development of UI components and provide rich interfaces.

    With that said I think the solution is to use frameworks, which have been built on top of the JSF spec such as UIX as one option. I'm not a fan of UIX but it is a step in the correct direction of easing development. As far as getting rich reusable UI components I have found that separating out the view component in a MVC2 architecture from any of the given open source frameworks such as struts or cocoon is the way to go. Macromedia is headed in the correct direction with flex and if there was an open source version of Flex I think we would all be very happy seeing it can lay on top of any other framework with little work. Just my quick 2 cents I did not want to delve this too much seeing it would take up so many pages and this is my first post to the server side.
  67. And so say all of us :-)

    I saw an earlier reply talking about moving over to the dark side (Windows/.NET), not sure if they were referrring to GUIs or web stuff. I can only see a future for simple web applications that as you say provide simple form entry. I've been trying to persuade my bosses that writing their internal business applications as web applications sucks, we have no business reason to not use complex clients. Saves having to manage state and have to learn 3-4 different languages environments and provides a far more powerful user experience.

    I was writing windows applications nearly 15yrs ago and can do so today with little change to the overall architecture (.NET aside). I don't have to learn a different architecture every day of the week.

    The only reason I can see for web apps is they are easier to deploy in an enterprise, big deal.

    With the increased usage of Eclipse/SWT I hope the businesses see the light soon. We use these (in small doses at the moment) with Java Web Start to provide remote client deploys (all secure etc), works like a champ.

    They will always be a place for a lightweight web application to deliver fancy content with a simple purchase/order style interface for use across the internet, but we need to head back to easier development, less dependence on the web session/stateless architecture. We can still take advantage of all the features of Java, J2EE, etc without to having to resort to resource hungry Session/EJB models.
  68. Re: The current state of JSF[ Go to top ]

    My team just went live with a JSF project we've been developing. Although there were some bumps along the way (not unexpected, since we're talking about a relatively young framework), I'm pleased with the way things turned out, and I'll be using JSF, again.
  69. Preview of JSF in JBuilder 11[ Go to top ]

    http://info.borland.com/media/shockwave/jbuildersneak/jbsneak.html.

    Component model is a must to make Web UI development easier. Check out the URL of the JBuilder demo. JSF 1.0 is a start and can mature into a nice component framework.
  70. JSF opinion[ Go to top ]

    Will JSF become the most common web framework?

    Will the java community become more fragmented regarding the best framework to use?

    I think many java developers are unhappy with attempts at struts and want a faster less hassle way for web app development.

    The future depends on implementation quality and how much **free** stuff is available. If good plugins are available for Eclipse enabling JSF development as intended, JSF will bridge the chasm and have momentum.

    Right now, I like Tapestry quite a bit. However, there is always room for a couple of good solutions to choose from.
  71. The current state of JSF[ Go to top ]

    All those who feel that JSF rocks might probably have not worked with Tapestry. I would be surprised if anybody who has seen Tapestry can look anybody in the eye and say that JSF is a great framework. JSF is a workaround to fit an component/event model into the J2EE stack. Though JSF is supposed to work with view technologies other than JSP, the vast majority of people are going to use it with JSPs; implying heavy use of custom tags and ultimately resulting in presenation code (HTML) in java tag library classes. Compare this to Tapestry where a component is represented by an HTML template. Where would ur web designer like to make changes, in an HTML template or in a java class. JSF is bound to have the same fate as of EJBs. The only thing in favour of JSF is that it is a standard and tool vendors will pour in with support for JSF and also many companies would feel comfortable going ahead with a standard, but a few years from now they will all learn a lesson like others have learnt with EJB.
  72. The problem with JSF is[ Go to top ]

    that you can't hand over the presentation aspects of your application to your HTML people. Other template-based frameworks such as Velocity, Tapestry, et al emphasize a minimal footprint on the HTML. The dynamic sections of the template are kept as non-intrusive as possible, so that non-Java people can amend the look and feel without breaking the application.
     JSF seems to fundamentally violate the whole point of separating presentation from logic since the presentation is not editable by anyone but a programmer using a GUI tool.
  73. Separation of model and view[ Go to top ]

    If we want model/view separation, then structure our code base so that the business objects compile without reference to the GUI code.

    If you want the gui guy to not have to look at Java code, then a round-trip WYSIWYG editor for that framework should be used. This all implies a component oriented framework (Tapestry/Echo/...even JSF), but preferably one that emits *simple* java code that stays in sync with the WYSIYG editor. The important point is that when the need arises for code inside the gui (and it will), workarounds won't start creeping in all over the place. And you won't have a proliferation of template languages and config files like we have now.

    I have never really understood why there is the assumption that using JSP really gives you any better model/view separation; you really get this from how you package code into separately compiled units. So, it may be *ant* that you use to get this separation. The large number of workarounds created by an overly simplistic template model can quickly make your templates as wacky and hard to understand as the equivalent Java code would have been. "A struts based application using pages wired together with a struts config file and deployed with a web.xml file in which each page contains a tiny amount of Java code inside of some JSP containing some html and some CSS while emitting JavaScript" is *not* any simpler or easier to learn than the limited amount of Java you would deal with in using a sane framework to generate the statically defined parts of a GUI, along with the code in that GUI to call the business objects. If your designer might have to look at Java when WYSIWYG is not cutting it, then at least he's not learning 8 or 9 little sublanguages and seeing a proliferation of xml files to tie it all together.

    Anyways...JSF looks a lot more complicated than it needs to be, but it does seem to be a step closer toward the light in that it recognizes the importance of a real event/component model.
  74. I agree totally, I dont like JSP because you have to put some kind of logic inside the template and for doing that you have to learn about special tags, such as tag iterators, logic tags, components tags, etc. This is not a true seperation between logic and presentation! For example if you want to use two different templates as view of some model that needs to iterate a collection, you have to put almost the same code inside both templates!!

    I think that WebOnSwing Application Framework (http://webonswing.sf.net) solves almost every problem that is discussed here, I want to enumerate some framework features that are hard to find in other frameworks:

    * A lot of GUI visual editor for all IDE, because you may use any Swing editor to create pages!!
    * All the work is done with java classes and pure html files, dont need extra xml files to configure everything.
    * Template engine that use pure HTML files as templates, with no special tags, no logic, totallly polimorfic templates, use of skins...
    * Visual validation components really easy to use
    * You may use xul or any xml based gui to create Swing windows to deploy to web
    * A lot of documentation about Swing components, and it comes with JDK!
    * Your applications are developed as any other desktop application because WebOnSwing use an abstract UI layer, no need to know html or javascript.
    * Persistence Engine handles a kind of viewstate as .NET or JSF to simulate statefull behavior in pages.
    * Is an open source project licensed under LGPL
  75. The current STATE_SAVING_METHOD of JSF[ Go to top ]

    I've been searching for discussions like this to get an answer to one of my own problems with the spec: the STATE_SAVING_METHOD=client parameter.

    Because of this, all of your 'JSF requests' must be generated from a form POST. I think JSF would be a lot friendlier if one could send request parameters to JSF in a GET query string without using a form post. But this is preliminated, at least in the RI, because of the STATE_SAVING_METHOD.

    If the FacesServlet could receive JSF request parameters from a GET query string, one's rendered hyperlinks could generate URLs instead of relying on JavaScript's onclick attribute to configure and submit a POST form.

    Someone PLEASE correct me if I'm wrong, but isn't it in our nature to distrust clients? We don't know if they have javascript capabilities -- which is a major reason to use JSF's validation framework (a contradictory irony IMO). Why on earth would we want to store JSF application state in a browser cache?

    I do understand the advantages of displacing the burden of state-saving from the server to the client. However, if the way it gets implemented prevents http/html clients from sending forms with a querystring, how reliable can it be?

    Does anyone agree that this is a limitation of the spec and/or RI that should be re-evaluated, or at least thoroughly justified through an in-depth explanation? I haven't found one in the spec.