ComeSolveGo

May 3rd 2008 05:08 pm

GAME OVER - Java Server Faces

38 Responses to “GAME OVER - Java Server Faces”

1. Schalk Neethling on 03 May 2008 at 5:52 pm #

   Dude, I cannot agree with you more! And it did not take much more then point 1 to make me say JSF, You’re FIRED!

2. vpetreski on 03 May 2008 at 6:01 pm #

   I agree

3. RogerV on 03 May 2008 at 7:28 pm #

   Doing MVC on the server-side using any of the various web frameworks is archaic. That stuff is on the way out.

   Get with web RIA ala Flex/AIR. There the equation is:

   web RIA client-tier + SOA middle-tier (as in SpringSource stack)

   The stuff you write for the server-side are relatively simple service beans.

   MVC is done entirely on the client-side (as God intended).

   Flex is a joy to program in - especially relative to monstrosities like JSF.

   With AIR, the webkit HTML engine is built-in so there is a platform portable way to do HTML content within an overall Flex app. Even when running in a browser there is a Flex iFrame control that can be used to combine HTML content with Flex RIA forms apps.

   Any kind of app being built using HTML/JavaScript running in the browser, can be built using Flex - and built much better. And Flex developers are actually happy to come to work each day - whereas everyone else doing server-side frameworks curse their fate. Can’t blame them.

4. Casper Bang on 03 May 2008 at 8:49 pm #

   I fully agree. What IS it about Java that seems to be a magnet to über complicated frameworks?

5. yilmaz on 03 May 2008 at 9:49 pm #

   I ve been working with JSF more than 2 years and I dont agree with your points.
   for example
   1- rf is a frontent component distribution for jsf and its problems doesnt directly related with jsf.
   2- if you need a custompageing you can implement your own it is too easy to implement.
   3- i wrote some component. i developed my own securitycontext implementation. i dont think it is too hard to do that.
   4- never put dao code in to your getters. and also postconstruct is an ejb annotation and doesnt related with jsf either.
   5- back button is always problem not only jsf . asp.net has this problem either.
   6- if you need bookmarkable urls you have to design your application in that way.
   7- i didnt get the idea. what is wrong with that?
   8- ?
   9- (os)jboss tools has excellent support, (comm.) ibm , jdeveloper, inttellij vs..

6. Peter Svensson on 03 May 2008 at 10:13 pm #

   The problem is the server-side web framework anti-pattern. Please check http://www.thinserverarchitecture.com

7. Paolo on 03 May 2008 at 11:35 pm #

   It’s time to engage Apache Wicket http://wicket.apache.org

   Cheers

8. Tom on 03 May 2008 at 11:58 pm #

   nice post

   jQuery is the solution. I know it may sound like apples and oranges, but I’ve been able to make and use some kick-ass components using it.

   JBoss SEAM is the only thing that makes JSF palatable, but why all the complexity?

9. Tom on 04 May 2008 at 12:01 am #

   Grails with jQuery is pretty damn good solution, that is

10. JSF Hater on 04 May 2008 at 12:10 am #

    Hear! Hear! I could not agree with you more!

11. henk on 04 May 2008 at 1:14 am #

    I don’t agree with you at all. Some of your points are even downright ridiculous.

    Take for example your point 2 - “Little control over custom components [...] If you want to change this, you have to rewrite the component.”

    This is actually the exact same situation as with object oriented development. Someone provide a class that you can use as-is and which may provide some options for configuration. If these limited options don’t suit you, you can either extend the class and override some of its functionality or you can indeed write your own class. Take something in standard Java like the HashMap. There are some configuration options available like an initial size, but not a maximum size. If I wanted to have that, I would need to do some extra stuff.

    Now by your logic, we should dispose of the OO concept and go back to procedural coding? Just because the HashMap does not come with some configuration option you grave for, the entire OO concept is wrong?

    Maybe point 3 says enough: “Development of custom component? No way, extremely complicated.”

    It’s not ‘extremely complicated’. Maybe it is for you, and maybe you should look into another profession where things aren’t that complicated? Developing a simple custom component is as easy as inheriting from UIComponent and spitting out some HTML. Yes, there is some mundane work involved when you wish to use the component on a JSP page; you need to create a taghandler and an entry in a tld file. There are however two things to remark here: First, this is NOT extremely complicated. It’s just mundane work. But far from being complicated. Secondly, JSP is -a- view technology, not -the- one and only. JSF in its core has absolutely no JSP dependencies. Defects in JSP -are not- automatically a defect in JSF.

    About 4; you probably just don’t understand the life-cycle. If you have fetched some data from whatever in your request scoped bean, it’s simple there for the duration of your request. If your code is stupid enough to refetch it from the original source when it’s already available inside your bean, then it’s just your own code that’s being stupid.

    This is actually a similar situation with using a cache, say OSCache or Jboss cache. If your code fails to check the cache for availability of an item, but always tried to get it directly from the data source, would you blame OSCache that it’s concept of caching doesn’t work? Please wake up dude. It’s YOUR code that needs to check whether something is there in the cache or not. If those checks happen more than once, abstract it to a separate method that does this checking and let all of your other code only use this method. Don’t blame library code for things you are doing wrong!

    And 6 is really hilarious. Take a look at Virgin’s online store at: http://www.zavvi.co.uk/ A JSF site, with guess what… GET requests everywhere. Technically it’s quite simple to do this; in your managed bean declaration, just bind your bean properties to param.somerequestparam and that’s it. Instant GET support for your pages.

    Point 8 sounds rather funny to me: “Fortunately, facelets have good support for this with templating and components.”

    Don’t you realize that Facelets -IS- JSF? Facelets is not a patch or a fix, but something that the JSF spec explicitly made possible in the core design of JSF.

12. Steven De Groote on 04 May 2008 at 2:04 am #

    @henk, I couldn’t agree more.

    There is more though. As for point 7, I don’t see the problem with calling a function when submitting a form. Isn’t that what java event handlers do all the time?
    You can easily create that method in any bean you want, heck you can just create a new bean for that. Even more, if you just want to have a button redirect you from one page to another, why not use a navigation rule. And maybe even a redirect tag to perform a get instead of “always does the POST”.

13. vpetreski on 04 May 2008 at 2:44 am #

    yilmaz, check this out: http://weblogs.java.net/blog/jhook/archive/2007/05/jsf_12_ri_backi.html

14. Andrey on 04 May 2008 at 7:22 am #

    I am agree that JSF sucks but I don’t agree with your points. Please learn JSF before saying that.

15. sakuraba on 04 May 2008 at 9:55 am #

    2) GWT Composites - the easiest way to build custom ajax components in a OO-way.
    3) see #2
    4) make the minimum amount of calls using GWT-RPC. Lighweight and lightning fast Ajax.
    5) GWT-History-mechanism see: http://gwt.google.com/samples/KitchenSink/KitchenSink.html (navigate the tabs and click the back-button)
    6) see 5) and look at the URLs, you can customize the URLs in any way that you want.
    7) only the real server calls that are necessary are performed, see 4). Asynchronously and lightning fast.
    Reuse GWT Composites just like you would reuse any other POJO, add style-dependent CSS names to achieve a special design for each specific reuse.
    9) Because your UI code are just plain Java classes, you can use all the high-level features of your favourite IDE, plus there are amazing extensions provided by commercial vendors like this here: http://www.instantiations.com/gwtdesigner/

    I have only mentioned a few parts of why I switched from JSF to GWT. You can use GWT with any server technology, no need for heavyweight appservers to run, run and debug your code from the hosted browser (Strg+S + Refresh = see changes).

    Look at the speed/beauty of this showcase: http://www.diwan.com/w/showcase/Showcase.html and change the locale to see its powerful i18n capabilites.

    In a few years, everybody will write RESTful backends with RIA frontends. GWT, Flex, etc will be the technologies to do so. JSF is dead.

16. devdanke on 04 May 2008 at 10:01 am #

    In my opinion JSF is another failed/failing “standard” Sun forced upon the Java community. JSF is similar to the horribly complex, slow, and hard to maintain EJB 1, 2, & 2.1 frameworks.

    Sun should stop creating it’s own misconceived frameworks. Instead, they should help support the best and most popular frameworks created by the Java community. An example of this is EJB 3/JPA.

    Sun finally realized that EJB persistence was so bad it was driving developers away from JEE. So they replaced EJB persistence with EJB 3/JPA, which is based on the popular Hibernate ORM technology. Sun is continuing to this good approach by fixing JEE with ideas from the SpringFramework.

    I’d like to see Sun use this approach with the web presentation layer. There are some great existing web frameworks, that are much better than JSF. These include component frameworks like Wicket and GWT and MVC frameworks like Struts2, Stripes, and Grails.

    But many of these frameworks don’t have enough resources to create user friendly documenation, fix bugs, and refine their design. Sun has the resources to help. With Sun’s backing, the best web GUI frameworks could be raised to a truly professional level.

17. JP Smith on 04 May 2008 at 10:58 am #

    @The author
    I agree with all of your points except number 3 (custom component development can not be called complicated even with a strecth of the imagination) and number 8 (I don’t really understand what you are trying to say).

    @yilmaz
    1,2 - I don’t want to recreate everything I need - that’s why there’s component libraries. Unfortunately all the current JSF component libraries seem to have a few fundamental flaws.
    4 - True, but where else should he put DAO calls? A session-scoped bean? What if the user visits the same page simultaneously from two browser windows?
    5 - Well, saying X also has this problem doesn’t really help us JSF users, now does it?
    6 - Yes, ridiculous of me to expect my web framework to help me with that.
    7 - Unnecessary processing.

    @henk
    “This is actually the exact same situation as with object oriented development. Someone provide a class that you can use as-is and which may provide some options for configuration. If these limited options don’t suit you, you can either extend the class and override some of its functionality or you can indeed write your own class. Take something in standard Java like the HashMap. There are some configuration options available like an initial size, but not a maximum size. If I wanted to have that, I would need to do some extra stuff.”
    - Your kidding me, right? Comparing JSF components with objects? Apples and Oranges anyone? A more accurate comparison would be to other GUI controls, say perhaps the .Net controls which offer extensive customizability. Certainly the goals of a Java object and a JSF component are way different.

    “About 4; you probably just don’t understand the life-cycle. If you have fetched some data from whatever in your request scoped bean, it’s simple there for the duration of your request. If your code is stupid enough to refetch it from the original source when it’s already available inside your bean, then it’s just your own code that’s being stupid.”
    - No, I think the author understands it just fine, do you? Why is it necessary for JSF to make multiple getter calls inside one request? You say that once you have fetched data and stored it in your request scoped bean, it’s there for the duration of the request. Fair enough, but when and where do you propose we fetch the data? What if we need it as soon as the request is initialized? What if it is a DAO access through a session EJB? Do we put the call in @PostConstruct and just allow the DAO call after every single postback (even AJAX ones)?

    If I could perhaps add to the author’s points:
    10. The complete and utter absurdity that is creating custom components consisting of other components. Here’s a challenge for you all, create a custom component with this tag that creates a number of h:inputText equal to the number specified in the tag. For added fun, don’t create the inputText components in the Renderer (obviously it shouldn’t be there). Finally, have the child components inherit the layout of your custom component’s parent (if for example you use a h:tableGrid).

    Enjoy.

18. JP Smith on 04 May 2008 at 11:01 am #

    The tag in question at 10 should be “custom:myComponent number=’3′”.

19. ehhh on 04 May 2008 at 11:11 am #

    Youre right devdanke, but thats no sun style. look at Calendar class, everybody hate it, it can be fix very fast even by making Calendar2 class as util class for Calendar. However sun will not do this, because they love every little shitty api they made.

    Even if you dont agree with article, you must admit that a lot of people voted for it, because of pure hate for jsf. i know that there are companies that are using jsf just because they believe it is/will be standard, but for me that only proves that they aretoo lazy to check out other frameworks. I dislike jsf, because i feel like i have no control over framework. if jsf wants to spit out shitty html it will and you cant fix it.

20. henk on 04 May 2008 at 12:06 pm #

    @JP Smith
    “- Your kidding me, right? Comparing JSF components with objects?”

    I’m certainly not kidding you. If you think about the issue a bit longer then you really must conclude a lot of the same concepts are involved. The author’s rant is directly aimed at the idea that you get abstract functionality in a box, which you can either extend or configure. That’s exactly the idea of Objects. Components on their turn are also directly inspired on the way in which one thinks in object oriented programming. It’s not a stretch of the imagination, and it certainly aren’t Apples and Oranges by any means.

    Let’s go back to the HashMap example. Suppose the author did say Objects were bad because the HashMap can’t be configured to his taste. If someone jumped in, stating you can’t dispose of the Object Oriented concept because of one single implementation that doesn’t suit your need, would you then also say “Your kidding me, right? Comparing HashMaps with objects?”

    The component idea is a really good idea and it will be the prime method by which JSF and everything that builds on it can grow.

    “but when and where do you propose we fetch the data? Do we put the call in @PostConstruct and just allow the DAO call after every single postback (even AJAX ones)”

    For starters, I think your concerns are quite valid there, but to be honest this a problem inherent with building statefull applications for the web. I’ve encountered this exact same problem with most every other web framework or web platform. I had this problem with my earliest CGI code, I had the problem with pure JSP/servlets and with PHP and I still have the problem with most modern frameworks.

    That said, JSF does offer me a bunch of solutions that I haven’t been able to use easily for the other platforms. To directly answer your question, I’m fetching the data right after the component tree has been restored. This allows me to retain the data between postbacks using a simple variation on the myfaces SaveState approach (see http://wiki.apache.org/myfaces/SaveState). Using the SaveState tag is fairly straightforward, but I’ve coded some convenience class that simply creates a new instance (UISaveState saveState = new UISaveState();) and inserts that into the component tree directly (root.getChildren().add(saveState);).

    As long as you keep “state on server”, this approach works really well, at least it has for me. Besides my simple home-cooked solution, JSF offers more elaborate support for this so-called conversation scope in add-ons like Seam or Orchestra. The next version of Java EE will also explicitly address this problem in WebBeans.

    Next to that, one other method I’ve been using is a Jboss cache based approach, where I use the sequence number from my postbacks to store and retrieve data from the cache one it has been initially fetched. This is kinda like the view state approach, but offers you more control regarding the amount of things you’re caching. This is a little bit more complicated though, so I won’t elaborate on it here (this post is already getting pretty big )

21. henk on 04 May 2008 at 12:55 pm #

    @ehhh
    “I dislike jsf, because i feel like i have no control over framework.”

    You obviously have no or very little experience with JSF. JSF must be one of the most extensible frameworks ever build. From the viewhandler, to the EL resolver, the state manager and even the lifecycle itself; it’s all replaceable, decoratable or extensible. Except from Eclipse, I’ve never seen a platform that allowed so much control over its inner workings.

    “if jsf wants to spit out shitty html it will and you cant fix it.”

    You just don’t get it. JSF doesn’t spit out any HTML. JSF is a framework and a specification for hosting components. It’s those components that spit out HTML and it’s their right to do that in a shitty way or not. The fact that some components generate bad HTML -is not- a defect in JSF itself. Compare this with the concept of the JVM; the JVM hosts classes. Just because Joe Average wrote some bad class and you choose to use his bad class, is the entire JVM flawed?

    Of course not! Other people can write high quality classes and run them on the same JVM.

    To compare this even more directly; the first version of Java (JDK 1.0) had a pretty weak set of classes that came with it. Especially the collections were not really that well. But did this signal a problem with Java the language or Java the VM? Right from the start people were able to write high quality classes for it, and in time Sun extended its own library to include lots of quality classes.

22. vpetreski on 04 May 2008 at 1:13 pm #

    Henk, you are missing one very important point - we don’t wont rocket science, we just want to do our work as simple as possible (but not simpler) and to enjoy while working. JSF doesn’t fulfil those two simple requests…

23. James on 04 May 2008 at 2:04 pm #

    Could not agree with your more…
    I tried JSF- IMO JSF on steroids (adding seam, or spring webflow and facelets) is putting lipstick on a pig. I have never seen productivity with JSF (unless it is a trivial number guess application). It is good for the “complexity industry” but there is never any upside(value) to learning the complexity.
    Solution: Wicket, tapestry or flex

24. JP Smith on 04 May 2008 at 2:25 pm #

    @henk
    Okay, I hear what your saying, but I think we’re approaching the problem from different directions. I agree that a component is an object in the sense that if it doesn’t provide functionality X you can add X yourself and it shouldn’t be expected of the component to cather for functionality X1, X2, … Xn. What I meant was that there is certain ‘core’ functionality that one expects from a GUI component and which shouldn’t be left up to the JSF user to extend. I regard anything that will form part of the end HTML tag as part of this ‘core’ functionality (example width, height) and then also some parameters which make sense in the context of the component (a scroller with a number of results to display for example). Now granted the author’s example in this regard was poor, but I have seen other instances of components not providing the basic configurability in component libraries such as RichFaces, Woodstock, MyFaces.

    As for the ‘conversation scope’ problem, I had to develop my own custom solution as well. Whereas you make use of Tomahawk’s saveState I do basically the same only with Trinidad’s pageFlowScope. What gets to me, however, and what I would guess is also one of the reasons so many people are complaining about JSF, is why wasn’t something like this included from the start? In certain respects JSF seem poorly though out. Let me rephrase, the engine behind JSF is brilliant (what, with the developer being able to basically chop and change any part as he sees fit), but the provided functionality seems lackluster. Why do we have to wait until JSF2.0 for a real conversation scope (excluding Seam and Orchestra which comes with too much bagagge for my personal taste)? The same can be asked of the back button problem and RESTful URLs.

25. Tom on 04 May 2008 at 4:48 pm #

    JSF is a component based framework.

    Would someone that knows JSF and knows (jQuery or Prototype) please explain some components that can be made easily in JSF but not so easily using jQuery?

26. Dan Allen on 04 May 2008 at 5:27 pm #

    While some of these points have merit, most of them are outdated FUD. Clearly you have not tapped into the power of Seam. Okay, so I am telling you to add another framework, but on the other hand, yes, we move forward. JSF wasn’t perfect by any means. But projects like Seam are taking it in a new direction that arguably makes the combination the best framework choice available.

    For instance, you should almost NEVER use the HTTP session scope to store beans. The page scope (from JSF, exposed by Seam) or the conversation scope (Seam) are far more suitable options. Both solve several of the problems you cited. In fact, the back button problem is mostly due to use of the HTTP session. (#4, #5)

    Additionally, Seam provides a very elegant way of doing non-POST action requests in JSF using its page-oriented features. A seam-gen created application uses very little form posts, in fact. Combined with URLRewriteFilter, you can even achieve those friendly RESTful URLs. (#6, #7)

    I also want to comment on your desire to have complete control the output. If that is what you want, then sure, JSF is not for you. JSF is designed to allow the creation/selection of XHTML, CSS, and JavaScript need for a page to be delegated to the component library in return for greater productivity. If you have a problem with the output generated by RichFaces, then your bone is with RichFaces, not JSF. Even then, you are saying that RichFaces has bugs. Okay, that doesn’t mean you have to go off the deep end ranting about it. Offer to fix them or choose another component library. (#1, #2)

    With Facelets combined with the Ajax4jsf CDK, I don’t understand why you have so much trouble creating custom and composite components. These two technologies definitely reduce most of the pain of this task. I think that RichFaces and ICEFaces both prove the great component libraries can be build. (#3, #8)

    If you want great IDE support, you should really be looking at JBossTools. No, it is not just a JBoss thing. Max Anderson has done a phenomenal job taking the old Exadel product to new heights. (#10)

    I’m not necessary standing up for JSF here because I really don’t have time for a fight over what is really a personal preference. All I am saying is that JSF is a start and frameworks like Seam and the next generation specs are improving on many of the problems you cited.

27. Luc Dew on 04 May 2008 at 5:56 pm #

    This post and the comments are really interesting especially and i feel involved since i currently have to develop a small JSF application for a client ( 20 managed beans, 40 views, 5 components so far). We have been using JSF 1.2 RI, RichFaces along with Spring 2.5 ( but our managed beans are not Spring @Component, albeit some properties are injected by Spring El resolver ) on JBoss 4.2.

    The strength of a component based framework must reside in the quality and sophistication of its components and I have to admit that i have been disappointed especially for a framework that has support by the industry. Even RichFaces users today ask for stability instead of bleeding edge components (see Seam forum). As said previously, developping components is not that complicated but it’s still a pain. Facelets ease the process with compositions you can create your own components like html fragments (but they are not distributable and self documented as real components but at least you can quickly develop “throw away” components that rely on third party js components)

    Struts2, Spring MVC, Wicket, Stripes etc are more or less in my point of view the same frameworks that tie the view to the server and offer some kind of abstraction and basic workflow to handle HTTP requests, and write responses. Today for my day job I prefer to stick with the standards (JSF) even if they are far from perfect.

    If had to develop a web app from scratch i might opt for a loosely coupled solution between our service layer and mvc gui like flex, gwt, ext-js or dojo.
    But i have still issues with these RIA technologies :
    - how can you provide a profile based application ? Using server side templating it is pretty easy to disable features based on user’s profile and safer (the profile and its privilege are not sent to the client).
    - Complex Templating and i18n. For instance with i18n message stored in db, would you let the client request the server for every message ?
    => When the gui or some parts have to be dynamically generated (like for CMS) i guess the RIA approach is not advised.

28. henk on 04 May 2008 at 8:10 pm #

    @JP Smith
    “the engine behind JSF is brilliant [...] but the provided functionality seems lackluster. Why do we have to wait until JSF2.0 for a real conversation scope [...]?

    I agree with your points, these are much more valid critiques than those of the author.

    But what can I say. A conversation scope should have been part of JSF right from the start, but as we all know it wasn’t. It is however certainly not the case that a bad designed solution was provided instead. It’s just not there. I remember reading that someone from the JSF design team, probably Ed Burns, remarked that the expert group simply doesn’t have unlimited resources. With the given set of resources they had, they choose to get the basic infrastructure of JSF right first. With that into place, the focus can now be shifted to adding more high-level features and filling in a lot of gaps.

    Like I mentioned before. Java itself started small too and was gradually extended over the years. Even Microsoft, who has way more resources to allocate to ASP.NET than the JSF expert group can ever hope to allocate to JSF, did not include anything there is to include into ASP.NET 1.0. Things like master pages for example where only included in a latter release. Sure, they -could- have been in 1.0, but they simply weren’t.

    A very good thing about JSF is that most of its current problems are already being addressed as we speak. It would be a totally different situation if the development community had lots of problems with JSF, and its (imaginary) sole vendor was pretending there were no such problems at all. But that’s not the case at all. Ed Burns for instance seems to be very well aware of what’s going on and I’m sure he’s devoting a lot of time and energy into listening to the community and improving matters. Since JSF is a spec, any party can implement it and when it would be -really- necessary, can implement additional features outside of the spec. If Sun would somehow resist to improve JSF any further, anyone can just continue working on it.

    Of course, the most important aspect of JSF when seen as a platform, is the wealth of extension points it offers. This allows third parties to build on JSF and address current weak spots without having to wait on a version upgrade from the party that creates the core implementation. We’ve already seen how well this strategy played out for Seam, Facelets, Orchestra and even Spring. With a closed monolithic framework these kinds of extensions would have been very hard, if not impossible to add.

29. Anonymouse on 05 May 2008 at 8:56 am #

    Completely agree! Wicket is definitely the framework of the future, check out this comparison with JSF:

    http://ptrthomas.wordpress.com/2007/05/14/a-wicket-user-tries-jsf/

30. piet on 05 May 2008 at 11:09 am #

    This rant of the author against JSF does not comply with my real world experience at all. In older projects we weren’t using JSF, only ’simple’ and ‘lightweight’ JSP pages, backed by some classes and servlets. We soon learned that ’simple’ had a very high price tag when the project grew in size and the whole thing became a complete spaghetti mess.

    For our newer projects we switched to JSF and it has been an overwhelming success for us. JSF implements the MVC pattern in a very logical and elegant way. It more or less forces the programmers to put view code where it belongs (in the view) and put model code where it belongs (in the model). The controller is already provided by JSF and its lifecycle does things in exactly the order in which programmers should have been doing things with JSP, but never did. Namely; first convert and validate all values and only thereafter try to invoke the application logic.

    The only programmers who were complaining in our team about JSF were the sloppy ones; the ones who claimed they -needed- to put business logic in the view, but in fact just didn’t had the skills and the discipline to divide their software in maintainable pieces.

    It is therefore that I don’t really agree with the point the author makes. I recognize a few of them as problems with JSF 1.1, but they have long been fixed. A few others are inherent problems with using the WWW as an application platform. Every web framework or web programmer has to jump through hoops to workaround the limitations in HTTP, which was actually never intended as a protocol for an application server platform.

31. Soma on 05 May 2008 at 12:39 pm #

    Hehe, made that decision about a year ago and switched to wicket

32. Peter Thomas on 06 May 2008 at 8:39 am #

    @Luc Drew

    >> Today for my day job I prefer to stick with the standards (JSF)
    >> even if they are far from perfect.

    Reminds me of what people used to say when they started ‘adopting’ Entity Beans 2.0

33. piet on 06 May 2008 at 11:07 am #

    >Reminds me of what people used to say when they started ‘adopting’ Entity Beans 2.0

    You may be right that it sounds the same, but c’mon it’s not fair to keep comparing everything with EJB2. JSF is an entire different thing and much better designed.

34. Paul Houle on 06 May 2008 at 2:55 pm #

    The world could really use something like JSF… That works, that uses the same patterns that modern web frameworks and that working web applications do, but codifies them into higher-level objects. Microsoft’s Web Controls for ASP.NET have the same problems: all of these systems seem to be built by committees of people who’ve never actually built web applications.

35. Ryan on 06 May 2008 at 10:09 pm #

    JSF wasn’t usability tested prior to release as a spec and reference implementation. If it were tested then Sun would have built basic functionality into the components that is needed. Page load events, client side validation, custom messages per validator. They set out to build something that would compete with ASP.Net but fell short in many ways.

36. henk on 07 May 2008 at 12:52 am #

    >If it were tested then Sun would have built basic functionality into the components that is needed.

    You forget Sun just didn’t have the resources to also create a rich set of components to go with the first release. They choose to define the core of the platform first, so others and eventually they themselves can deliver this set of components.

    Also don’t forget that JSF in Java still isn’t that old. The version numbering is a bit awkward, but the first release of JSF in Java EE was actually not before May 11, 2006. Everything released before that should really be seen as a preview release, just as Swing once was before it got it’s official introduction in JDK 1.2. Practically JSF is at 1.0. Again, how many classes were there in JDK 1.0 compared to how many there are now?

    >Page load events

    Although there isn’t an explicit method called onPageLoad, there are at least 3 ways to react on page loads in JSF. You can bind your backing bean to your page’s form (h:form binding=”#{mybean.bind}”). You can also use the @postcontruct annotation if your backing bean is in request scope (where basically it always should be), and of course your backing bean, or a separate class if needed, can simply implement the phase listener interface after which you can bind that to your view (f:phaseListener binding=”#{mybean}”).

    Please check your facts before making claims.

    > client side validation

    It would indeed be nice if there was some support for that. Last thing I heard this was indeed being considered for JSF 2.0. It’s a fairly common request.

    > custom messages per validator

    Every kind of of validator already has its own message key in the resource bundle. You can override that (by simply providing your own bundle in addition to the one from JSF). If you mean that you wish to provide a custom message per instance of identical validator types, then I’m really curious what the use case would be for that. With labels you can let the standard message refer to the specific place where validation went wrong. Uniformity is the key here, and having an identical message for the same situation is probably a Good Thing. Or do you really prefer stuff like this:

    “An incorrect value for field email was provided”
    “I didn’t understand what you put into field name”
    “An error occurred when processing your input for last name”

    ?

    Anyway, if you’d -really- want this, then it’s fairly easy to do with JSF. Create a custom validator, let it have an attribute for a custom message, and attach that to the components that need validation. No big deal. And please don’t use the argument that you think creating a custom validator is so difficult. If you really find such a trivial thing difficult to do, then I seriously wonder how you cope with implementing the business logic or algorithms of your application.

    Perhaps a lot of people who are complaining about JSF are the sort of guys that do nothing more than write applications that only pull data out of a database using a select * and display that via a loop over the resultset? Really guys, for every one who has written any amount of serious code this simply can’t be difficult.

37. Peter Thomas on 10 May 2008 at 4:15 pm #

    @henk above

    If you are trying to defend JSF I would say you are doing a pretty pathetic job. First you agree that JSF was released by Sun without much testing because “Sun just didn’t have the resources”. Wow.

    Next you say that we should pretend that JSF was released as version 1.0 only in May 11, 2006 when in reality the date is March 11, 2004. So you agree that JSF was a half-baked POS when it was in version 1.0 and now - even 4 whole years later (that’s a lot of internet years mind you) you are advising us to hold on, the best is yet to come. Nice touch, comparing the evolution of JSF to Swing. Heh.

    And then you say yeah, things can be improved and it would be nice to have support for that but hey, not to worry - everything will be fine in JSF version 2.0. Hurray!

    About your last point I find that really ironic because JSF in my experience is perfectly suited for “applications that only pull data out of a database using a select * and display that via a loop over the resultset”. Guys who are writing such simple UIs are least likely to complain about JSF

38. vpetreski on 10 May 2008 at 5:17 pm #

    Exactly