Facelets 0.8 released, competing with Tapestry in the JSF world

Discussions

News: Facelets 0.8 released, competing with Tapestry in the JSF world

  1. Facelets is a light-weight, templating framework backed by JavaServer Faces as the industry standard. Anyone who has created a JSP page will be able to do the same with Facelets and familiar XML-tag use. The difference is under the hood where all the burden of the JSP vendor API is removed to greatly enhance JSF as a platform and provide easy plug-and-go development without requiring JSP tag development to integrate with JSF.

    Facelets includes many features which include:

    • Works with JSF 1.1 and JSF 1.2, including Sun's RI and Apache MyFaces.
    • Zero Tag development time for UIComponents
    • Fast Templating/Decorators for Components and Pages
    • The ability to specify <code>UIComponent</code> trees in separate files (<code>UICompositions</code>)
    • Line/Tag/Attribute precise Error Reporting
    • Specify Tags in Separate Files, even packaged with Jars
    • Full EL support, including Functions
    • Developer-mode for Easy Error resolution
    • Build-time EL Validation
    • XML configuration files aren't necessary
    • Reserves the '<code>jsfc</code>' attribute which acts the same as Tapestry's jwcid (Example: <code><input id="bar" type="text" jsfc="h:inputText" value="#{foo.bar}"/></code>)
    • Plugable Decorators to really make designer's job easy (Example: transform <code><input type="text"/></code> to <code><h:inputText/></code> at compile time)
    • Works with any <code>RenderKit</code>
    • Facelets could be used outside of a Web Container with JSF
    Home Page: http://facelets.dev.java.net

    Documentation: http://facelets.dev.java.net/nonav/docs/dev/docbook.html

    Development Error Pages: http://facelets.dev.java.net/nonav/docs/dev/error.html

    Everyone wants to be more HTML-designer friendly, and in my opinion, Tapestry seems to be the only choice developers are pursuing. On the other hand, JSF is the standard a lot of people would like to have happen. But, JSF needs a more "pluggable" ViewHandler framework that is both designer and developer friendly. Facelets is a clean slate for correcting concerns with JSF. Templating, re-use, and ease of development are top priorities that will help bring developers on board with JSF as a suitable platform for large scale projects.

    Facelets is still adding new features-- what features would you want Facelets to include?

    Threaded Messages (33)

  2. Congrats..[ Go to top ]

    I hope this version will be usable.
    I've checked releases time to time from the very begining
    and there always was something that went wrong.
    Many bugs was solved, even my issue #1 ;) (But still there are some echos from those problem)
    There are another sad tendency in increasing complexity.
    But I'm very optimistic... keep going.
    Good Luck,
    E.Lucash
  3. Facelets[ Go to top ]

    Is currently one of the best solutions to the we want an easy componetization problem.
    One of the main problems JSF has currently (besides the dreaded Datamodel, which is really awfully designed) is the hard way to create a component, although there are shortcuts, but they are not that well documented.

    Basically what JSF tries to achieve is, that you have a clear MVC separation on the component level, a good approach, the binding is done via the config file entries, also a viable approach.

    The main problem is that you also have to provide the hooks into the taglibs, which means another set of config file entries in a different config file.

    The approach has to be done that way, because JSF wants to achieve rendering platform independence, a render kit against VT220 would be possible, another one against XUL, and probably another one against Swing. I do not know if anyone has driven that technology that far, but it is possible (there is a WAP implementation for MyFaces) hence the porting of applications to different rendering methods is eased that way.

    But what comes with the flexibility is an increased complexity on the component programming level with a lack of extensive documentation on how to do things (Kitos Book is the best bet currently if you want to go into component programming, especially the online section, but there is definitely a need for an entire book describing all the aspects of that stuff, it is really complex)

    Component programming in JSF is not a walk in the park, but at least you can shortcut some stuff, you cann move the rendering if you target only one platform into the controller logic, but you cannot really bypass the hooks into the taglibs or the separate controller to my knowledge, even if you want to because you only target HTML.

    Additionally to that there is no realy official client side way to do client only componentization.

    MyFaces has the x:aliasBean, which is a very easy way to get pure client components, but those omit the controller aspects (you cannot pass a different controller)

    Then there is tiles, which is good but overly complicated and adds another set of config files to the mix.

    And then there is facelets, the most interesting approach currently for solving the problem of getting an easy componentization way.
  4. Abandoning tools?[ Go to top ]

    Does a move to this view technology mean that use of drag-and-drop tools (or other wizards) will be broken? As I understand it, all the d-n-d tools out there are predicated on the standard JSP view technology.

    So, without tools, just how much XML and Java coding is necessary? This has been the big push in Tapestry 4.0 (now in beta, and so a valid comparison against an 0.8 Facelets release). In every aspect of Tapestry has been the drive to eliminate XML, or at least simplify it, and to reduce the amount of Java code.

    Tapestry 4.0 also has terrific integration with HiveMind and Spring and re-orients the model around a very sophisticated form of injection (by sophisticated, I mean that often what's injected is code, not just objects).

    So, if you abandon the tools support of JSP/JSF, do you still compare to Tapestry productivity? And don't forget all the rest of Tapestry: localization support, state management, dynamic JavaScript generation, and general runtime efficiency.

    Still, it's nice that people have been paying attention to Tapestry 3.0, but the bar has been raised much higher with Tapestry 4.0!
  5. Abandoning tools?[ Go to top ]

    What tools??? There is no JSF drag ann drop tools that work with every non-standard components.

    However, Facelets allows you to choose from ANY HTML authoring tools (drag and drop or not) to design your pages (just like Tapestry). So you have a lot more choice of tools.

    Regarding Tapestry 4.0... beside lightweight cointainer intergration, Facelets is more like 4.0 than 3.0. You need not to create Java classes for you pages and you do not need to create a seperate XML file to describe your component tree. You just have to create you XHTML (or anything XML) page to create the component tree.

    I'm not saying that JSF/Facelet is way better than Tapestry. I'm just saying that it's a nice alternative and that it makes the use of JSF a lot more easier. I just hope that Facelets will get in JSF 2.0 spec as it should have been done for JSF 1.0 instead of have JSP integration.
  6. Abandoning tools?[ Go to top ]

    When you claim there are no good tools. What about Exadel Studio Pro?
    I more or less looked at all the WYSIWYG tools available, but this clearly stands out in comparison in my opinion.
  7. Mythical tools[ Go to top ]

    For real development there are no real JSF tools except those that manipule faces.xml to easy create managed beans and such.
    Other wysiwyg tools like sun jscreator, nitrox on eclipse and other does not provide any comfort to construct complex, high quality view. Magic is in components. Yes, jsf components (out of the box) are very basic, but I can create ones (equally to Tapesty)
    "Sophisticated injections" and intercepters can be perfectly changed to full-fleged AOP solutions like AspectJ or AspectWerkz.
    Spring integration in jsf? No problem.
    HiveMind? IMHO Hivemind is personal powertoy.
    JavaScripts? Components are designed badly so they need those scripts. Quality components works with scripts in other way.

    So Tapestry for all, JSF only for those who can in leverage it with quality component and others "plugins"

    Conclusion.... Different Auditory

    P.S. Have Tapesty normal xml template parser, not only regex parser for badly structured html like markup?
    Regards
  8. Abandoning tools?[ Go to top ]

    Hey Howard!

    Facelets is only one part of the JSF stack that can be used with any other advances in component development and controller behavior. So while Tapestry 4.0 covers a much wider scope than Facelets as a hole, Facelets doesn't lock you into a complete implementation of the whole application stack-- just the view rendering. So when I talk about Tapestry-like features, they are only maintained in the view layer.

    Pertaining to XML and annotations: With XML and vendor tools, Facelets will be supporting Oracle's new 276 JSR for component metadata-- which would completely remove the concept of 'tag libraries' or 'tag definitions'. You can actually take a JSF page in JSPX and compile it as a Facelet.

    With annotations, JSF itself, provides all the opportunity in the world to accomodate annotations for controllers and state management (as I'm pursuing). Again, the upside is that developers have many options to swap in or use whatever frameworks they want through the JSF stack.

    There are a lot of vendors/os projects that have expressed interest or committed to adding support for Facelets. There's also opportunity to embed Facelets within other view technologies since the API is very similar to Velocity with a factory-inclusion capabilities.

    -- Jacob
  9. Congrats![ Go to top ]

    Congrats on the release, Jacob! I think Facelets is a great step forward for JSF, and a good example of what's possible with the technology. It's good for people to see JSF in a world without JSP.

    Also, stay tuned, as we'll be featuring a series of articles about Facelets on JSF Central.

    Kito D. Mann
    Author, JavaServer Faces in Action
    http://www.JSFCentral.com - JSF FAQ, news, and info

    Are you using JSF in a project? Send your story to trenches at jsfcentral dot com, and you could get your story published and win a free copy of JavaServer Faces in Action!
  10. Congrats..[ Go to top ]

    IMO, Facelets is a true testament to the richness and extendibility of the JSF framework and proves a tool for innovation. Brilliant work, Jacob.
  11. Great stuff Jacob - can't wait to try it out. This is what JSF really needs IMO - having JSP pages w/o any HTML in them is ugly.

    JSF Tag Soup vs. Tapestry HTML.
  12. Great stuff Jacob - can't wait to try it out. This is what JSF really needs IMO - having JSP pages w/o any HTML in them is ugly.JSF Tag Soup vs. Tapestry HTML.

    Thanks Matt, how's the VW? ;-)

    I do think there's opportunity to find balance and flexability between HTML and 'tags', Facelets isn't completely where Tapestry is, but by all means could very easily. You can already do stuff like:

    <span jsfc="c:if" test="#{person.roles['admin']}">
      // output
    </span>

    But it can be up to the developer/designer if they would rather use the normal <c:if> within Facelets.

    Cheers!
  13. Well done - a big step forward.
  14. Good job.

    Just curious, what are the steps that a developer needs to undertake to create a new component?
  15. Good job.Just curious, what are the steps that a developer needs to undertake to create a new component?

    I know I'm walking into a trap ;-)

    Component development is exactly the same as with all JSF components. The benefit of Facelets is that it doesn't require you to: write a JSP tag that must be maintained alongside your component, write a TLD file that has mirrors every property you want.

    http://facelets.dev.java.net/nonav/docs/dev/docbook.html#taglib-create-component
  16. I know I'm walking into a trap ;-)
    Not really, I just saw "Zero Tag development time for UIComponents" and wondered what that meant. :)
    Component development is exactly the same as with all JSF components. The benefit of Facelets is that it doesn't require you to: write a JSP tag that must be maintained alongside your component, write a TLD file that has mirrors every property you want.
    I guess that greatly narrows the margin of error. It does not eliminate it completely I think, as JSF requires a number of other steps as well. Nevertheless, it does seem like this is a very good step in the right direction.

    I guess Tapestry has spoiled me to have to write only the logic in a Java file and the presentation in an HTML file and be done with it.
  17. I guess Tapestry has spoiled me to have to write only the logic in a Java file and the presentation in an HTML file and be done with it.

    That's true, the downside of JSF is that rendering is intended to be done within the one Java class-- much like the new StaX writer for XML. On the otherhand, I'm okay with things working that way because it encourages separation of semantic structure from presentation (HTML).

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

    Facelets does attempt to create 'pseudo' components that are built on compositions:

    http://facelets.dev.java.net/nonav/docs/dev/docbook.html#template-component
  18. Good job.Just curious, what are the steps that a developer needs to undertake to create a new component?

    I should note that outside of Facelets, I am working on foundation Components that have annotation support for state management and rendering-- K.I.S.S Components ;-)
  19. Can someone that really knows both world tell us where we are now.
    I gave up with JSF a long time ago saying "they will do something better that that".
    Things have changed here?
  20. You cannot compare to .NET today because .NET is moving to Avalon, and will change everything that MS developers use today, IMO another big mistake from MS, we have tecnologies like avalon today in the J2EE world as Thinlets, XUL, Lazlo, etc, with Avalon MS will do the same, but for one single OS, something new to you ??? ($$$$$$$$)
  21. You cannot compare to .NET today because .NET is moving to Avalon, and will change everything that MS developers use today, IMO another big mistake from MS, we have tecnologies like avalon today in the J2EE world as Thinlets, XUL, Lazlo, etc, with Avalon MS will do the same, but for one single OS, something new to you ??? ($$$$$$$$)

    Interesting point. Because JSF is most commonly used with JSP, it creates a 'web-based' dependency for application development. Facelets uses XML and as the last bullet states, you could use JSF with Facelets outside of a web container-- in a desktop application for example. Granted you would need to provide a new ViewHandler for such a different deployment, but the Facelet engine could be used within it to generate component views for XUL, Lazlo, Thinlets, Web Services, etc.
  22. You cannot compare to .NET today because .NET is moving to Avalon, and will change everything that MS developers use today, IMO another big mistake from MS, we have tecnologies like avalon today in the J2EE world as Thinlets, XUL, Lazlo, etc, with Avalon MS will do the same, but for one single OS, something new to you ??? ($$$$$$$$)
    Interesting point. Because JSF is most commonly used with JSP, it creates a 'web-based' dependency for application development. Facelets uses XML and as the last bullet states, you could use JSF with Facelets outside of a web container-- in a desktop application for example. Granted you would need to provide a new ViewHandler for such a different deployment, but the Facelet engine could be used within it to generate component views for XUL, Lazlo, Thinlets, Web Services, etc.

    Oops, I should point out that Facelets in a web container could deliver all of those component views as it stands now.
  23. You cannot compare to .NET today because .NET is moving to Avalon, and will change everything that MS developers use today, IMO another big mistake from MS, we have tecnologies like avalon today in the J2EE world as Thinlets, XUL, Lazlo, etc, with Avalon MS will do the same, but for one single OS, something new to you ??? ($$$$$$$$)
    Interesting point. Because JSF is most commonly used with JSP, it creates a 'web-based' dependency for application development. Facelets uses XML and as the last bullet states, you could use JSF with Facelets outside of a web container-- in a desktop application for example. Granted you would need to provide a new ViewHandler for such a different deployment, but the Facelet engine could be used within it to generate component views for XUL, Lazlo, Thinlets, Web Services, etc.
    Oops, I should point out that Facelets in a web container could deliver all of those component views as it stands now.

    I agree with you, but I really want to see a working JSF RenderKit or Facelet View Handler that pick an XML and render to both HTML and Swing, IBM has released a few days ago a JSF renderkit that generate Lazlo applications, but the renderkit does not give an option like HTML for the same source XML. My point is, you are right that JSF with Tiles create a "web-based" dependency and Facelets can possibly generate another type of client interface, but can you give me an example?? I had not saw any type of framework ou technology that do this, only proposes and teorical technologies like Avalon now with MS too.
  24. My point is, you are right that JSF with Tiles create a "web-based" dependency and Facelets can possibly generate another type of client interface, but can you give me an example?? I had not saw any type of framework ou technology that do this, only proposes and teorical technologies like Avalon now with MS too.

    Roger Kitain, from Sun, has been focusing on the features you are describing. At JavaOne, he had one application that went from HTML to SVG, to XUL and back again. The SVG was very Flash-like-- cool stuff! I missed a different presentation given by Oracle that used JSF to power a console (SSH) application.

    The rendering part of JSF (can be)/is separate from the view definition (Facelets), so you could create a view of pure components that have Renderers available for your different interfaces.
  25. I will like to see that presentation, appears very cool, but, there is a web container needed to run ? I will love to see an technology like this running in a lightweight container out of a J2EE container, something like Spring.
    A few months ago I evaluate the lazlo for client interface, but the XML needed by lazlo is proprietary and the creation of a new render kit to render lazlo as HTML was imperative and time consuming.
  26. but, there is a web container needed to run ? I will love to see an technology like this running in a lightweight container out of a J2EE container, something like Spring.

    Look at avalible documentantion and test cases and you'll see that it is easy
  27. JSPs are basically like the old Microsoft ASPs which came from CGI. You are writing a program that outputs HTML.

    ASP.NET uses a different model. The HTML with tags embedded actually produces an object graph. So something like

      <asp:DropDownList ... RunAt="server">

    does not directly output anything, it creates a node, very similar to the way that the windows client does. There is a Form object, which has a list of subcomponents etc.

    This means that one can write have events related to components that can affect other component's values. The actual HTML is only generated during rendering at the end.

    And creating a new tag such as MyDropDownList is just a matter of extending an appropriate class. Very easy compared to anything to do with Taglibs or Tapestry.

    The also have avoided the urge to create yet another programming language like JSTL expressions. The tags just create the object graph, everthing else is neatly in VB C#.

    And yes, you can separate the business logic from the presentation.

    I would suggest that the Java world could learn from .Net in this regard. It seems that the Evil Empire has done a fairly good job here (Yes, there are also horrors such as viewstate etc... I am talking about the basic object graph building. Clean and elegant.)

    Anthony
  28. (I should add that JSF does build an object model of sorts, but in parallel to the rendering, not a separate pass. See

    http://www.onjava.com/pub/a/onjava/2004/06/09/jsf.html

    There is no JSP/JSF confusion in ASP.NET. Just the object graph.
    )
  29. (I should add that JSF does build an object model of sorts, but in parallel to the rendering, not a separate pass. Seehttp://www.onjava.com/pub/a/onjava/2004/06/09/jsf.htmlThere is no JSP/JSF confusion in ASP.NET. Just the object graph.)

    Which is why Facelets works the way it does. It builds a mutable component model which is able to later, render itself.
  30. Documentation for Facelets[ Go to top ]

    I'd suggest you spend a little time with documentation instead of coding. Your blog entry is not enough(!). Documentation that clearly states what you are trying to do will help sell your project.
  31. Documentation for Facelets[ Go to top ]

    I'd suggest you spend a little time with documentation instead of coding. Your blog entry is not enough(!). Documentation that clearly states what you are trying to do will help sell your project.

    http://facelets.dev.java.net/nonav/docs/dev/docbook.html

    ?
  32. What is it better than Tiles ?[ Go to top ]

    Hi,

    I´m not a user of Tapestry, but reading the documentation of the Facelets, i do not see nothing much better than use of JSF with Tiles Support (I´m using Tiles + JSF + MYfaces) for the presentation tier.

    Anyone can point what are the advantages of using Facelets in contrast of Tiles if exist one ?

    Thanks
  33. What is it better than Tiles ?[ Go to top ]

    Hi, I´m not a user of Tapestry, but reading the documentation of the Facelets, i do not see nothing much better than use of JSF with Tiles Support (I´m using Tiles + JSF + MYfaces) for the presentation tier.Anyone can point what are the advantages of using Facelets in contrast of Tiles if exist one ?

    Thanks

    Facelets uses the new EL API for *correct* variable management in the view (> JSP 2.1). When people talk about Tiles features, Facelets provides the same thing-- document based though. You have ui:composition, ui:component, ui:define, ui:insert, ui:decorate, ui:remove, etc... So there's quite a large toolkit there for developers to choose from to handle view definitions.

    Cheers
  34. SUBJ