My Experiences With JSF

Discussions

News: My Experiences With JSF

  1. My Experiences With JSF (48 messages)

    I am currently converting a large Struts application to JSF. My first instinct was to simply replace the Struts tags with the equivalent JSF tags and JSTL. Turns out things aren’t so simple. JSF & JSP don’t really play all that well together as detailed in the following OnJava article: Improving JSF by Dumping JSP. (Editor's Note: Hans' article was written for JSF 1.0, and some issues may have been addressed by now. However, the point stands.) This article discusses how, if you mix normal HTML and JSP tags, you can run into unexpected problems. To avoid this, you must fully understand the rendering lifecyle of JSPs and JSF. Having to be aware of the rendering cycles is a negative. If you want to avoid this, you must buy into converting your old JSPs tag for tag to the equivalent JSF tags. That doesn’t seem easier to me. But wait, the tools are here to save us... butt they didn’t save us from the nightmare of EJB 2.1, they won’t save us now. The framework called Facelets was created to solve this issue by by completely replacing the JSP layer we all know and hate. It drops the need to fully convert your app over to JSF tags, you simply use HTML plus JSF tags where needed. This is great - I found it frustrating to use the JSF markup to output the HTML I wanted to display in the first place. No more! Also, no more crappy code generation on the backend. Todays’ date isn’t 1998, lets move on. Facelets make JSF tolerable but still I think it should be more simple. Why does JSF introduce its own dependency injection when EJB3 already has one? Because JSF came out before EJB3! Enter Seam, the latest from Gavin King(author of hibernate) which vastly simplifies the JSF configuration using annotations and tightly integrates JSF with EJB3 and JBPM. The Web Beans JSR aims to standardize Seam. My prediction is that Web Beans technology will be the BFG that allows them to punch holes in IBMs’ armour and finally makes web application implementation simpler. Rajesh Patel rpatel at harpoontech dot com Harpoon Technologies Message was edited by: joeo at enigmastation dot com, with the caveat that changes were only made for clarity and all views expressed are those of Mr. Patel

    Threaded Messages (48)

  2. Re: My Experiences With JSF[ Go to top ]

    My prediction is that Web Beans technology will be the BFG that allows them to punch holes in IBMs’ armour and finally makes web application implementation simpler
    What IBM has to do with complexity of JSF WEB applications ?
  3. Re: My Experiences With JSF[ Go to top ]

    My prediction is that Web Beans technology will be the BFG that allows them to punch holes in IBMs’ armour and finally makes web application implementation simpler


    What IBM has to do with complexity of JSF WEB applications ?
    +1 If the product is standardized, it'll become part of IBM's offering just as much as everyone else's. Also, there isn't anything in this article that hasn't already been said a bajillion times before. Maybe we should write a Java app that goes out to old blog entries based on subjective opinion and specious arguments, mashes them together, and output the result to create something news aggregation/community-posting sites will pick up as "newsworthy."
  4. As for jsfs dependency injection[ Go to top ]

    It is different than ejb3s because it was their first, both mechanisms are not merged yet, but it is easy to replace the jsf dependency injection with ejb3s, by using a different variable resolver, and Seam as mentioned does that already. One advantage of not using EJB3 per default as bean provider is that jsf can run outside of an ejb3 scope, but the main reason simply is historical, thats it, EJB3 is very new, while JSF already has been there for a while.
  5. Facelets and Seam?[ Go to top ]

    Rajesh... Can Facelets be used with Seam?
  6. Re: Facelets and Seam?[ Go to top ]

    Rajesh... Can Facelets be used with Seam?
    Yes. In fact, it's the encouraged view technology to use.
  7. Re: Facelets and Seam?[ Go to top ]

    Have you looked at Seam at all ? Gavin is using Facelets to build the demo.
  8. Re: My Experiences With JSF[ Go to top ]

    I am currently converting a large Struts application to JSF. My first instinct was to simply replace the Struts tags with the equivalent JSF tags and JSTL.
    Why would that be your first instinct ? Struts and JSF have very different programming models and if all you want to do is swap tags, what possible difference would you expect ?
  9. Who ever said a transition from Struts to JSF would be easy? Its doable, but not without making some significant changes which you have obviously experienced. There are several strategies for dealing with a Struts application, the most difficult a conversion. It requires a translation from existing presentation layer, which is undoubtedly JSP, into a UI of your choice. Again this is commonly JSP. Tags are different, but in order to take advantage of the frameworks its necessary to adopt them. This is not to mention the control and model layers. Facelets introduces another way of building reusable UI widgets and presentation layer. Commonly renders in XHML, but can also use XUL, or whatever you want to build custom. If you are trying to make dealing with JSF tags easier, this may not be the way to go. I have tried to introduce Facelets into my projects after the fact. As you may not have experienced yet, there are other hurdles more significant then the ones you are describing. Namely accomplishing some real world tasks that just are considered in the basic suite of widgets. Making these work in another markup just make it even more annoying. Recommendation, learn and understand the JSF taqs first, and either get used to tracking down third party tags that make dev easier or better yet learn how to write your own. Facelets is something I want to get in, but it just doesn't have that much to offer the small to medium size application developer. And it doesn't seem to sync completely with the JSF model.
  10. Re: My Experiences With JSF[ Go to top ]

    if you mix normal HTML and JSP tags, you can run into unexpected problems. To avoid this, you must fully understand the rendering lifecyle of JSPs and JSF.
    Interesting, is there any idea/attempt from Sun & Co to rewrite JSP compiler? Actually right now it is a preprocessor and of course he is not aware about the rendering. As seems to me if JSF so important for the vendors it would be better to provide a normal JSP compiler rather than all the time duplicate HTML with JSF tags. Am I wrong? Dmitry http://www.servletsuite.com
  11. Re: My Experiences With JSF[ Go to top ]

    if you mix normal HTML and JSP tags, you can run into unexpected problems. To avoid this, you must fully understand the rendering lifecyle of JSPs and JSF.


    Interesting, is there any idea/attempt from Sun & Co to rewrite JSP compiler? Actually right now it is a preprocessor and of course he is not aware about the rendering. As seems to me if JSF so important for the vendors it would be better to provide a normal JSP compiler rather than all the time duplicate HTML with JSF tags. Am I wrong?
    There's two orthogonal issues here. One is that JSP 'tags' are only render aware where JSF 'tags' are full MVC aware and have a very different lifecycle. The intended result is that you only need to coordinate things once, via tag markup, to gain rendering, validation, updating, conversion, actions, etc. This avoids splitting up the rendering from the other supporting concerns when there's a 1:1 relationship from an MVC standpoint. Secondly, there's the issue of content interweaving. Again JSP has a single goal of rendering output and the compiled JSP is one long series of out.print(..). In JSF world our goal isn't to render the output with JSP, but to use it as a set of instructions for building a UIComponent model-- buffering the static bits from out.print(..) as components alongside the JSF ones. With JSP 2.1, much of this has been corrected, but we're still 'hacking' JSP to build a component model instead of rendering. The Facelets compiler works quite a bit differently than JSP such that the 'compiled' pages are static and only serve to build a component model instead of rendering (the component model just renders itself after building). Since we're only concerned with building, it's much cheaper than with JSP.
  12. Re: My Experiences With JSF[ Go to top ]

    The Facelets compiler works quite a bit differently than JSP such that the 'compiled' pages are static and only serve to build a component model instead of rendering (the component model just renders itself after building). Since we're only concerned with building, it's much cheaper than with JSP.
    mr. facelets, i'm honored. i have a question for you. i was intensely interested in adopted the facelets servlet, but had issues with certain non standard tasks i was doing in my current jsf application. namely, rendering embedded html that i was having to use a scriptlet for. maybe i'm missing something basic here, but where can i learn how to make non-standard tasks easier. i am currently developing some simple tags and renderers to accomplish many of these, but i have those few instances where i have to resort to the writing to the response.
  13. Re: My Experiences With JSF[ Go to top ]

    The Facelets compiler works quite a bit differently than JSP such that the 'compiled' pages are static and only serve to build a component model instead of rendering (the component model just renders itself after building). Since we're only concerned with building, it's much cheaper than with JSP.


    mr. facelets, i'm honored.

    i have a question for you. i was intensely interested in adopted the facelets servlet, but had issues with certain non standard tasks i was doing in my current jsf application. namely, rendering embedded html that i was having to use a scriptlet for. maybe i'm missing something basic here, but where can i learn how to make non-standard tasks easier. i am currently developing some simple tags and renderers to accomplish many of these, but i have those few instances where i have to resort to the writing to the response.
    You can use static functions that work with EL such that you can produce: <h:outputText value="#{my:format(scopedBean.something)}" escape="false"/>
  14. Re: My Experiences With JSF[ Go to top ]



    You can use static functions that work with EL such that you can produce:

    that IS simple. it solves the basic issue i was having with UIOutput. I wasn't able to extend it because it strips out < and makes it "<" on render, and i didn't want to waste my time rewriting UIOutput. thanks..
  15. Re: My Experiences With JSF[ Go to top ]

    ampersand lt, that is.
  16. Re: My Experiences With JSF[ Go to top ]

    Again JSP has a single goal of rendering output and the compiled JSP is one long series of out.print(..).
    Any JSF component is doing the same at the end of the day
    In JSF world our goal isn't to render the output with JSP, but to use it as a set of instructions for building a UIComponent model-- buffering the static bits from out.print(..) as components alongside the JSF ones.
    Again why non-JSF part could not be included into your 'buffering' automatically by JSP compiler? Dmitry http://www.servletsuite.com
  17. Re: My Experiences With JSF[ Go to top ]

    Again JSP has a single goal of rendering output and the compiled JSP is one long series of out.print(..).


    Any JSF component is doing the same at the end of the day

    In JSF world our goal isn't to render the output with JSP, but to use it as a set of instructions for building a UIComponent model-- buffering the static bits from out.print(..) as components alongside the JSF ones.


    Again why non-JSF part could not be included into your 'buffering' automatically by JSP compiler?

    Dmitry
    http://www.servletsuite.com
    You're missing the root of the issue-- JSP has all of this functionality that has existed and works within a specific set of constraints around execution/rendering. The JSP itself is compiled into one big execute method. The problems with JSF integration come up in that you may have a bunch of tag logic in JSP that gets evaluated at build time, where you expect it to render/eval with the rest of the component model (deferred). JSP Tags can't share the same lifecycle as components, nor ever will. So there's always going to be a 'race' condition with JSF/JSP just because of all the functionality that JSP allows in the first place, opening opportunities for expectations to become disjoint.
  18. Re: My Experiences With JSF[ Go to top ]

    You're missing the root of the issue-- JSP has all of this functionality that has existed and works within a specific set of constraints around execution/rendering.
    Could you please be a more specific here? What kind of constraints? On the rendering stage JSP component (tag) and JSF component (tag) are similar. Our JSF components are printing JavaScript code (for Ajax) the same manner as JSP. It is obvious. So JSF tag will have the same constraints.
    The JSP itself is compiled into one big execute method.
    Yes, exactly. That is what I am asking about. Why do not change that, move static (from JSF point of view) code out from service() method and keep in mind JSF tree. As seems to me it is a job for JSP (or JSF if you want) compiler.
    The problems with JSF integration come up in that you may have a bunch of tag logic in JSP that gets evaluated at build time, where you expect it to render/eval with the rest of the component model (deferred).
    The existing JSP preprocessor evaluates tags (generates code for the evaluation) at build time, right. But once again, why component model can not take care about the static JSP code? E.g. JSF model will use render kit (default or redefined) anyway. Add the legacy JSP code to the kit for example. Dmitry http://www.servletsuite.com
  19. NO IDEA[ Go to top ]

    converting Struts to JSF simply replacing the Struts tags with JSF tags ? Sorry Rajesh... but you have no idea about what or for what JSF is.
  20. Re: NO IDEA[ Go to top ]

    You counter point illustrates the underlying problem…you posit that Mr. Patel doesn’t understand JSF. I assume that Mr. Patel is an experienced and capable developer, and should have no problem using a well designed framework. Maybe this further exposes the shortcomings of JSF? I have been working with JSF for a year, and I still have “No Idea” what is going on (actually, I have some idea). Frankly, I don’t care. JSF does not make me want to care. I think JSF is a hastily conceived, academic exercise that has a long way to go before it becomes an elegant, useful tool for Java developers to get their work done. I can’t wait for my current project to end so I can use something more interesting and enjoyable, like Struts, or even Ruby. Heck, next to JSF I might consider using .Net (but I don’t think I’d go that far).
  21. Understanding JSF[ Go to top ]

    I think the comment about Mr. Patel not understanding JSF stems from this statement by him:
    My first instinct was to simply replace the Struts tags with the equivalent JSF tags and JSTL.
    That does not seem like a good development practice... ;-)
  22. Re: Understanding JSF[ Go to top ]

    I think the comment about Mr. Patel not understanding JSF stems from this statement by him:
    My first instinct was to simply replace the Struts tags with the equivalent JSF tags and JSTL.


    That does not seem like a good development practice... ;-)
    To clarify, I am replacing my actions with backing beans. The layout of my pages is more or less the same, however do to the various incompatibilities between the JSF and JSP response cycles I feel that I must do a 100% conversion of to the corresponding JSF tags(HTML included). Now looking at what facelets has to offer, I believe that is the better approach.
  23. Re: NO IDEA[ Go to top ]

    You counter point illustrates the underlying problem…you posit that Mr. Patel doesn’t understand JSF. I assume that Mr. Patel is an experienced and capable developer, and should have no problem using a well designed framework. Maybe this further exposes the shortcomings of JSF?
    No, I think it simply indicates that JSF requires a significantly different way of working. Switching from action-based to event-and-component-based development is a big step, and no matter how well-designed the framework, this can be a challenge.
    I think JSF is a hastily conceived, academic exercise that has a long way to go before it becomes an elegant, useful tool for Java developers to get their work done. I can’t wait for my current project to end so I can use something more interesting and enjoyable, like Struts, or even Ruby. Heck, next to JSF I might consider using .Net (but I don’t think I’d go that far).
    In combination with facelets, I have found JSF to be incredibly productive. I really can't imagine how anyone could consider struts more interesting and enjoyable. There is so much exciting activity going on with JSF right now (check out the recent ICEFaces article as an example), that I don't see how anyone could find it dull. The amount of activity around JSF and the number of extensions to it surely indicates that it is very well designed - JSRs should be like this - they should form the foundation for new and innovative products.
  24. Re: NO IDEA[ Go to top ]

    Heck, next to JSF I might consider using .Net (but I don’t think I’d go that far).
    Why not?
  25. Dropped both Struts and JSF[ Go to top ]

    Originally we were using Struts and switched to JSF. Found it harder but more feature-rich. Now we have dropped JSF for OpenLaszlo and there is no way I ever want to go back to that other stuff...
  26. Re: Dropped both Struts and JSF[ Go to top ]

    why? what does openlaszlo have that makes it the kill app?
  27. Why OpenLaszlo[ Go to top ]

    why? what does openlaszlo have that makes it the kill app?
    I don't know if it is the "kill app" or not, but for us we like that we can drop JSPs entirely. That in and of itself would not be enough but combined with the speed with which you can develop UIs (MUCH faster than Struts or JSF in our experience and frankly, they look MUCH better as well), coupled with no screen refresh issues since it is Flash, it makes it simply a pleasure to develop with, IMHO.
  28. You should check out Stripes[ Go to top ]

    In my experience, Stripes MVC is an appealing candidate for a Struts project upgrade/port. The Stripes tags are very similar to Struts tags in their structure--many can be updated using universal replace. Porting message resources just involve changing the file name. If you're already using JSTL in your Struts app then you're way ahead, Stripes will also handle that as well. It supports Sitemesh, its own native templating, and I have been able to port Tiles into the Stripes framework. The other great thing about Stripes is it's very quick learning curve from Struts, but with much greater flexibility, ease of use, and lots less configuration. Did I mention no action forms! When I include the xml configuration, I see a near 50% reduction in lines of code in my action layer by going to Stripes.
  29. I am currently converting a large Struts application to JSF. My first instinct was to simply replace the Struts tags with the equivalent JSF tags and JSTL.
    If you use JSTL core tags than you are missing something. The problem with JSTL is that you are mixing some controller responsabilities (modifying the UI in response to UI events) wtih view responsabilities (view processing logic). Hence you end up handling controller concerns in the view and therefore with long unreadable JSP pages. With Struts and JSP you had no other choice since there were no notion of UI components, but with JSF you should manipulate your UI in reaction to events using Java like you do with Swing. This is one advantage of a stateful component model. Now for the real view processing logic, you can use the facelet ui library and the rendered attribute for the basic stuff or create a new renderer for more complex case (for instance alterning table row colors). The only problem is that right now renderers have to be written in Java and that is in my opinion one of the main weaknesses of JSF (really the component model could use some simplification). Hopefully, it's going to get fixed in 2.0. In the meantime it isn't hard to incorporate something like Velocity to get the job done. As for productivity, I find JSF/facelets extremely productive compare to Struts. Of course, you don't have as much control over the generated HTML but that always the price you have to pay for a higher abstraction. Same thing can be said about ORM tools versus a pure SQL approach after all but I think the majority of developers agree they are indeed very useful and productive tools. I am more than happy to dump actions frameworks and Struts annoying problems.
  30. It used to be scriptlet is evil, JSTL is good. Now JSTL is evil, JSF is good. Next year it might be JSF is evil, GWT or XYZ is good ...
  31. It used to be scriptlet is evil, JSTL is good. Now JSTL is evil, JSF is good. Next year it might be JSF is evil, GWT or XYZ is good ...
    This is called progress. Now if you can't write nothing else than pathetic flame attempts in a technical discussion about JSF as always, quit it. Maybe you should work on your next article. Hope it'll be as good as : http://www.theserverside.com/news/thread.tss?thread_id=38170
  32. JSF is only making the symptom described in the article worse - the dinosaur container. It's really funny people like you call Windows (operating system) a container, and J2EE (Java EE) a platform.
  33. JSF is only making the symptom described in the article worse - the dinosaur container. It's really funny people like you call Windows (operating system) a container, and J2EE (Java EE) a platform.
    Here's a basic fact you still haven't get, container=fixed interceptor (proxy) object that handle cross cutting concerns. In order to be able to do its work, the interceptor needs your application to implement certain interfaces (or use annotations) and be deployed in a container. Of course, nothing stop you from calling these services from your application with a standalone implementation but the container model is way more powerful. Really who want to have transaction lifecycle calls scattered all across his code? Now there is this thing called AOP that allows you to inject dynamically those interceptor objects in your application instead of having your application developed in a very rigid way and deployed in a JEE container. This is what Spring and lightweight containers are all about. Well now I'm done answering to you and I'm going to stick to this thread subject : JSF. Sorry for the noise!
  34. If the JEE container were not a dinosaur, light weight containers such as Spring would not have come into play. One of the problems with JSF is that it a mandatary part of the JEE dinosaur container.
  35. Re: My Experiences With JSF[ Go to top ]

    If the JEE container were not a dinosaur, light weight containers such as Spring would not have come into play.

    One of the problems with JSF is that it a mandatary part of the JEE dinosaur container.
    JSF is a part of the JEE spec but you don't need a JEE container to use JSF. In your ignorance about the topic, I think you've confused yourself. JSF can happily reside in a Spring application or any simple web application with only a Servlet engine. No fully compliant JEE container neccessary. Lightweight containers exist because of the realization and experience that not every problem solved with the same solution. And, I'd hardly call the Spring stack lightweight these days.
  36. Re: My Experiences With JSF[ Go to top ]

    JSF is a part of the JEE spec but you don't need a JEE container to use JSF.
    That does not change the fact that JSF is a mandatary part of a JEE compliant server (I call it the dinosaur container). The spec has to be designed in a way to accommodate these dinosaurs. If you have a WebSphere JEE5 server installed in your company, how easy is it to use a third party JSF implementation on top of the WebSphere server? I reckon you have the tendency to judge before understand.
  37. Re: My Experiences With JSF[ Go to top ]

    If the JEE container were not a dinosaur, light weight containers such as Spring would not have come into play.

    One of the problems with JSF is that it a mandatary part of the JEE dinosaur container.
    Spring is not a container, it is a supportive framework and as is, it is excellent at what it does, but the main problem with spring is, as soon as the program gets bigger the difference between spring and a full blown j2ee implementation of a program diminishes regarding startup times, complexity etc... The main problem many containers have, is that they are a burden on developers because often you have to have enforced startups of the container during debugging sessions, in combination with huge startup times this is a huge burden. But newer j2ee containers have surprisingly fast startup times (I was really amazed about the latest glassfish incarnations for instance) and the startup times of bigger spring apps in combination with hibernate basically can become a huge burden as well, often that big that you would love to move away from a war structure to a structure with separated bo object subprojects which can encapsule parts of your application. Dont get me wrong, I love spring at what it is, and I have used it numerous times, but it has its limits.
  38. It used to be scriptlet is evil, JSTL is good. Now JSTL is evil, JSF is good. Next year it might be JSF is evil, GWT or XYZ is good ...


    This is called progress. Now if you can't write nothing else than pathetic flame attempts in a technical discussion about JSF as always, quit it. Maybe you should work on your next article. Hope it'll be as good as :
    http://www.theserverside.com/news/thread.tss?thread_id=38170
    Ok *that* made this entire thread worth reading, very funny.
  39. Re: My Experiences With JSF[ Go to top ]

    It used to be scriptlet is evil, JSTL is good. Now JSTL is evil, JSF is good. Next year it might be JSF is evil, GWT or XYZ is good ...


    This is called progress. Now if you can't write nothing else than pathetic flame attempts in a technical discussion about JSF as always, quit it. Maybe you should work on your next article. Hope it'll be as good as :
    http://www.theserverside.com/news/thread.tss?thread_id=38170


    Ok *that* made this entire thread worth reading, very funny.
    You definitely look like one of Alexandre Poitras's colleagues who call Windows (operating system) a container, J2EE (Java EE) a platform.
  40. Re: My Experiences With JSF[ Go to top ]

    It used to be scriptlet is evil, JSTL is good. Now JSTL is evil, JSF is good. Next year it might be JSF is evil, GWT or XYZ is good ...


    This is called progress. Now if you can't write nothing else than pathetic flame attempts in a technical discussion about JSF as always, quit it. Maybe you should work on your next article. Hope it'll be as good as :
    http://www.theserverside.com/news/thread.tss?thread_id=38170


    Ok *that* made this entire thread worth reading, very funny.
    No body in that thread has mentioned that there are other ways to get into the J2EE container in addition to HTTP or RMI, i.e. a JMS message (since J2EE 1.3) or a J2EE Connector 1.5 message (since J2EE 1.4). So you have five ways to get into a J2EE container: 1) HTTP request, typically from a Web browser (to a servlet, a JSF page) 2) Web service (a special kind of HTTP request) 3) RMI (EJB or in the case of Weblogic, non EJB RMI) 4) JMS message (to a message driven EJB i.e. MDB) 5) J2EE connector 1.5 message (to a MDB) After all, a J2EE server is the server in the context of client/server. EJB2.1 timer is one exception to this statement. After all, .NET is an application platform, and J2EE is a SERVER application platform. period.
  41. Re: My Experiences With JSF[ Go to top ]

    It used to be scriptlet is evil, JSTL is good. Now JSTL is evil, JSF is good. Next year it might be JSF is evil, GWT or XYZ is good ...
    Scriplet is evil as it easily lets you code your business logic in your presentation layer... and that is really EVIL JSTL helps to reduce that evil... separation of business logic and presentation is GOOD
  42. Re: My Experiences With JSF[ Go to top ]

    I agree with your comments about Facelets. It is hard to go back to JSP after using Facelets. I wrote two articles about my experience with Facelets. Facelets fits JSF like a gloveIn this article, JSF enthusiast Rick Hightower introduces you to what he likes best about Facelets: easy HTML-style templating and reusable composition components ... http://www.ibm.com/developerworks/java/library/j-facelets/ Advanced Facelets programming: ... http://www.ibm.com/developerworks/java/library/j-facelets2.html
  43. I agree with your comments about Facelets. It is hard to go back to JSP after using Facelets.

    I wrote two articles about my experience with Facelets.

    Facelets fits JSF like a gloveIn this article, JSF enthusiast Rick Hightower introduces you to what he likes best about Facelets: easy HTML-style templating and reusable composition components ...

    http://www.ibm.com/developerworks/java/library/j-facelets/




    Advanced Facelets programming: ...

    http://www.ibm.com/developerworks/java/library/j-facelets2.html
    Rick, first great article. Nice to see good documentation coming out on JSF. I just have one question about your advanced Facelets programming article : Would it not be easier to just create the view using Java in this case (using the binding attribute) since it is highly dynamic instead of using facelet tags to determine the field type? For my part, this is how I would have done it. What do you think?
  44. I agree with your comments about Facelets. It is hard to go back to JSP after using Facelets.

    I wrote two articles about my experience with Facelets.

    Facelets fits JSF like a gloveIn this article, JSF enthusiast Rick Hightower introduces you to what he likes best about Facelets: easy HTML-style templating and reusable composition components ...

    http://www.ibm.com/developerworks/java/library/j-facelets/




    Advanced Facelets programming: ...

    http://www.ibm.com/developerworks/java/library/j-facelets2.html


    Rick, first great article. Nice to see good documentation coming out on JSF.

    I just have one question about your advanced Facelets programming article : Would it not be easier to just create the view using Java in this case (using the binding attribute) since it is highly dynamic instead of using facelet tags to determine the field type? For my part, this is how I would have done it. What do you think?
    I am not sure what you mean. Perhaps it is because I have been working with Tapestry 4 all week, and can't make the mental switch to JSF without grinding gears in my brain. (Yes, I work wtih Tapestry with some clients and JSF with others... I am a technology whore). I am sure there are improvements to be made with Facelets usage in that article and I would love any feedback you give. I find when I ignore advice, it is usually to my own peril so perhaps you could email more details about what you mean. Rick Hightower (linked in),blog JSF, Spring, and Hibernate training and consulting You can find my email address in comment sections of my blog. (listed above)
  45. Re: My Experiences With JSF[ Go to top ]

    .. I am a technology whore..
    I've always used the term "techno gigolo". "I'm just a techno gigolo and everywhere I go, people know the part I'm playing ..." :)
  46. Re: My Experiences With JSF[ Go to top ]

    I agree with your comments about Facelets. It is hard to go back to JSP after using Facelets.

    I wrote two articles about my experience with Facelets
    This first article was the one I used like a map to try out facelets. It was a great tutorial, but I had difficulty closing the gaps from poc to prod. Time did not permit further experimentation. Seeing the second article and getting some good feedback here, I think I will be able to introduce this rendering engine. As a side benefit, by rendering xhtml, it makes it easier for me to transform my pages to pdf. I have been using aspects of the XWiki project(check it out if you haven't already, its code is beautiful) for doing this, and now the process will be more natural. For the individual that has been working with JSF for a year, and is not getting it(paraphrased), check out a good book that takes you through the process with an example(I used "Javaserver Faces In Action", by Manning). That really gave me all I needed to build on. Eventhough this was a side project, mostly for fun, it became a viable, alternate framework for our enterprise. I was able to provide the same widgets we are paying hundreds of thousands of dollars for. As an added bonus, it doesn't crash, unlike the proprietary Struts extension we purchased. Thanks.
  47. Re: My Experiences With JSF[ Go to top ]

    Hey, thanks for the plug :-). This thread seems a bit strange to me. I've seen quite a few "JSF sucks" threads, but the original posting didn't have much meat to it... I'd like to know more about the specific issues the original author had other than JSP/JSF integration (since that has been solved in JSF 1.2/JSP 2.1, _and_ by using libraries like Facelets or Struts Shale Clay). I'd also like to reiterate JSF's main benefit: a standard framework for user interface components. There's a growing third-party market, and often, you get AJAX for free: http://www.jsfcentral.com/products/components/. ~~~ Kito D. Mann Author, JavaServer Faces in Action http://www.virtua.com - JSF/J2EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
  48. My prediction is that Web Beans technology will be the BFG that allows them to punch holes in IBMs’ armour and finally makes web application implementation simpler
    What IBM has to do with complexity of JSF WEB applications ?
    I'm not a big fan of IBM, but Apache with Facelets Myfaces, intend to be a compatible Sun RI 1.1 implementation, but it isn't. Unfortunnaly the open source libraries are making some companies to avoid great tech improvements like JSF. I think JSF is not enough mature inside servers vendors implementers, this can create a bad situation in the market. Rgds HJR
  49. My prediction is that Web Beans technology will be the BFG that allows them to punch holes in IBMs’ armour and finally makes web application implementation simpler


    What IBM has to do with complexity of JSF WEB applications ?


    I'm not a big fan of IBM, but Apache with Facelets Myfaces, intend to be a compatible Sun RI 1.1 implementation, but it isn't. Unfortunnaly the open source libraries are making some companies to avoid great tech improvements like JSF.

    I think JSF is not enough mature inside servers vendors implementers, this can create a bad situation in the market.

    Rgds

    HJR
    What are you talking about??? MyFaces has been certified to be JSF 1.1 compliant since september 2005 : http://www.theserverside.com/discussions/thread.tss?thread_id=36626 I run my project successfully on both JSF RI 1.1 and MyFaces. There are small differences but your project should work with both implementations.