Discussions

News: Facelets fits JSF like a glove

  1. Facelets fits JSF like a glove (128 messages)

    Trying to combine JSF and JSP is like trying to shoehorn a foot into a glove: it's possible, but not pleasant. This article introduces developers to Facelets' easy HTML-style templating and reusable composition components that fits JSF like a glove.

    While working on a JavaServer Faces (JSF) project recently, I had the pleasure of using Facelets for the first time. What I most liked about Facelets was that it let me create reusable composition components. Being able to take a page (like a JSP) and turn it into a component has been a real boon to my JSF development ever since. My conclusion? If you're not using Facelets, you're not getting the most you can out of JSF.

    The mismatch between JSF and JavaServer Pages technology is a serious problem in JSF development. The issue is how to integrate JSP's dynamic content into JSF's component-based model. JSP is singularly focused on generating dynamic output, whereas JSF requires JSP to coordinate building a component model. The disjunct occurs because that task is beyond the original intention of JSP.

    Most JSF developers simply learn to navigate such problems on an ad-hoc basis, but that's kind of like duct-taping a pillow to a hammer so it won't hurt coming down on your head. Facelets is a much more comprehensive solution: a templating language that is geared toward the JSF component model.

    Facelets fits JSF like a glove.

    Have you tried Facelets?
    Have you compared the Facelets approach to other technologies like Tapestry?

    Threaded Messages (128)

  2. Spec?[ Go to top ]

    Are facelets part of the JSF spec? Is it support by any other vendors besides IBM?
  3. RE: Spec?[ Go to top ]

    Facelets does not part of JSF spec but may be part of future versions of spec.
    Facelets does not supported officialy by any vendor, but as Jackob Hookom states facelets developed under Sun's guidance.
    (no sign of IBM (AFAIK))
  4. Re: IDE Support[ Go to top ]

    Facelets does not part of JSF spec but may be part of future versions of spec.Facelets does not supported officialy by any vendor, but as Jackob Hookom states facelets developed under Sun's guidance.(no sign of IBM (AFAIK))

    Actually, Exadel Studio Pro has had Facelets support for some time. You can also get some IDEs to support to (unofficially) support the tags.

    Hopefully we'll se others on the bandwagon soon. I've talked to people at BEA and IBM about it. (Oracle's ADF Faces, by the way, works with Facelets as well).

    ---
    Kito D. Mann
    Author, JavaServer Faces in Action
    http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
  5. Spec?[ Go to top ]

    Are facelets part of the JSF spec? Is it support by any other vendors besides IBM?

    Like many great technologies (Hibernate, Spring, Tiles, WebWork), Facelets is not part of the official spec.

    I think Facelets will impact future JSF specs. (Maybe even JSP). But this is just speculation.

    Facelets is very useful. And component composition is a big boon to JSF development.
  6. Spec?[ Go to top ]

    I'm very interested in feedback (good and bad). Rick's article already seems to have encouraged some new ideas within the users lists, which is excellent. Overall, the article is very fair in highlighting Facelets features while properly explaining current limitations.
  7. Spec?[ Go to top ]

    Like many great technologies (Hibernate, Spring, Tiles, WebWork), Facelets is not part of the official spec.

    Sorry Rick I didn't mean that it needed to be part of a spec to be useful or considered. I was just wondering where facelets stood.

    I am really looking forward to JSF, but am not very happy with the JSP implementation of it currently, so I'm hoping that a better implementation comes a long soon. Facelets may be what I'm looking for. I will have to give them a try.
  8. Faclets vs Tapestry[ Go to top ]

    The problem I see with facelets is the tag based approach.
      <title><ui:insert name="title">Default title</ui:insert></title>

    Although the code above would render correctly on a browser without any J2EE engine, it will cause problems with HTML editors unlike the attribute based approach of Tapestry which would get ignored and kept.

    I would still avoid JSP or any other tag based approach to user interface development unless libraries have been set up to match the needs of an industry solution rather than a low level MVC framework. The reason is developers would have to maintain two sets of source files one from the HTML developers that have to get signed off and the transformed to JSP/JSF set.

    Sure there might be tools that allow WYSIWYG JSP writing but you'd be imposing tool restriction on non-Java developers. Its better to use whatever tool does the job best.
  9. Faclets vs Tapestry[ Go to top ]

    There are a couple options here:
    Simply use EL <title>#{title}</title> instead of spans
    Use <span jsfc="h:outputText" value="#{foo}"/>
    Use a Facelets TagDecorator to automatically translate <input type="text" value="#{bean.var}"/> to <h:inputText value="#{bean.var}"/> at compile time
  10. Faclets vs Tapestry[ Go to top ]

    One other option, in light of the wicket thread:
    <span jsfc="ui:component" binding="#{page.menu}"/> and then have a 'getMenu()' method on a backing bean that returns a UIComponent model that's constructed programmatically, separate from the markup completely
  11. Is Facelets production ready?[ Go to top ]

    Facelets depencs on JSF 1.2 and JSP 2.1.

    You can read that Faclets can work with MyFaces, but only if you use some jars from JSF 1.2/JSP 2.1 implementation from Glassfish project. Too trickly for me.

    Facelets is promising technology and I will consider Facelets for new projects, but after my favorite Java EE implementation upgrades to Java EE 5.

    Nebojsa
  12. Facelets depencs on JSF 1.2 and JSP 2.1. You can read that Faclets can work with MyFaces, but only if you use some jars from JSF 1.2/JSP 2.1 implementation from Glassfish project. Too trickly for me.Facelets is promising technology and I will consider Facelets for new projects, but after my favorite Java EE implementation upgrades to Java EE 5.Nebojsa

    I don't think this is true. I've read on the user list for facelets that most seem to be using Facelets 1.0.7 with MyFaces 1.1.1...
  13. Re: MyFaces and Facelets[ Go to top ]

    Facelets depencs on JSF 1.2 and JSP 2.1. You can read that Faclets can work with MyFaces, but only if you use some jars from JSF 1.2/JSP 2.1 implementation from Glassfish project. Too trickly for me.Facelets is promising technology and I will consider Facelets for new projects, but after my favorite Java EE implementation upgrades to Java EE 5.Nebojsa
    I don't think this is true. I've read on the user list for facelets that most seem to be using Facelets 1.0.7 with MyFaces 1.1.1...

    You're right, Frank. I have used MyFaces and Facelets and it works just fine. It's also not a very complicated feat.

    ---
    Kito D. Mann
    Author, JavaServer Faces in Action
    http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
  14. Re: MyFaces and Facelets[ Go to top ]

    Facelets depencs on JSF 1.2 and JSP 2.1. You can read that Faclets can work with MyFaces, but only if you use some jars from JSF 1.2/JSP 2.1 implementation from Glassfish project. Too trickly for me.Facelets is promising technology and I will consider Facelets for new projects, but after my favorite Java EE implementation upgrades to Java EE 5.Nebojsa
    I don't think this is true. I've read on the user list for facelets that most seem to be using Facelets 1.0.7 with MyFaces 1.1.1...
    You're right, Frank. I have used MyFaces and Facelets and it works just fine. It's also not a very complicated feat.---Kito D. Mann Author, JavaServer Faces in Actionhttp://www.JSFCentral.com - JavaServer Faces FAQ, news, and info

    Please, give me a reference to detailed description how to setup Tomcat+MyFaces+Facelets.

    Section on MyFaces setup in Facelets documentation is short:

    "Apache MyFaces has it's own version of the JavaServer Faces API included in its distribution. Currently, Apache MyFaces is only up to the 1.1 specification, but has not yet passed the TCK."

    After that you can read that Facelets depends on JSF 2.0 API and some parts of JSF 2.0 implementation.

    There is a lot of peope on e-mail list who mention they use MyFaces, but I haven't found clear answer hot to set it up myself.

    Nebojsa
  15. Re: Is Facelets production ready?[ Go to top ]

    I mentioned in another post that Facelets works fine with MyFaces, but I wanted to address the topic of Facelets being production ready. The answer is definitely yes. Lots of people are using it (see the mailing list), and I'm using it for parts of JSF Central (JSP is in use as well). Facelets has been stable for quite some time.

    ---
    Kito D. Mann
    Author, JavaServer Faces in Action
    http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
  16. Re: Is Facelets production ready?[ Go to top ]

    Yep, it certainly feels production ready. One aspect not consistently mentioned is that it's also faster than JSPs, both at development and deployment time. At development, it's not producing a .class file, so there's no interminable waiting for the translation/compiler process. And at deployment time, our internal benchmarks have shown very promising improvements in performance/scalability, due to the much more optimized page assembly process (the Facelet counterpart to a JSP Tag object is cached and reused instead of recreated on each request).
  17. Re: Is Facelets production ready?[ Go to top ]

    Like a recent politician, I am going to say the following: It depends on what you mean by production ready.

    I've had some issues working with older versions of MyFaces (1.1.1). It seems to work with the latest version of Facelets, you need to work with the latest nightly build of MyFaces.

    You can use Facelets (not recent version) with MyFaces 1.1.1, but then you don't get some of the bug fixes in the latest release.

    I am using MyFaces 1.1.1 and Facelets 1.0.7 in app that should go into production in March. It works well enough for our needs.
  18. Like a recent politician, I am going to say the following: It depends on what you mean by production ready.

    In my case "production ready" means "ready do decide to use Facelets in all new projects". It is stronger then "ready to use it in the specific project".

    To decide to use Facelets in all new projects, you are concerned about all possible issues, but in the specific project you are not concerned about issues you can work around or resolve on ad hoc bases in this project.
    I've had some issues working with older versions of MyFaces (1.1.1). It seems to work with the latest version of Facelets, you need to work with the latest nightly build of MyFaces.You can use Facelets (not recent version) with MyFaces 1.1.1, but then you don't get some of the bug fixes in the latest release.

    It just desn't look like production ready IMO.

    As I understand you have to put JSF 1.2 API from RI an JSF 1.1 implementation from MyFaces in the same application!
    Morever you, if you dont run on JSP 2.1 enabled container, you have to add JSP 2.1 EL API and implementation from Glassfish projec on servlet 2.3 containter (JSP 2.1 depends on servlets 2.4).

    It is realy too trickly for me, sory. And BTW, JSF 1.2 RI and Glassfish are in beta.

    This configuration may run Facelets somehow, I will not put my business to depend on it.

    Please don't misunderstand me, I like Facelets and I want to use it, but I just want to be clear abaut current state of Facelets and issues.

    Early addopting of JSF was painful for me and I am not sure is Facelets solution for painless JSF or anather painful early addopting.

    Also I need to reuse some JSP views and plain JSP pages even if I use Facelets.
    I am using MyFaces 1.1.1 and Facelets 1.0.7 in app that should go into production in March. It works well enough for our needs.

    What servlet container/app server do you use?

    Nebojsa
  19. Like a recent politician, I am going to say the following: It depends on what you mean by production ready.
    In my case "production ready" means "ready do decide to use Facelets in all new projects". It is stronger then "ready to use it in the specific project".To decide to use Facelets in all new projects, you are concerned about all possible issues, but in the specific project you are not concerned about issues you can work around or resolve on ad hoc bases in this project.

    We have decided to use it on all new application (for now anyway). We are using Facelets 1.0.7 and MyFaces 1.1.1. When MyFaces 1.1.2 comes out we will evaluate it with the latest version of Facelets and likely adopt it.
    I've had some issues working with older versions of MyFaces (1.1.1). It seems to work with the latest version of Facelets, you need to work with the latest nightly build of MyFaces.You can use Facelets (not recent version) with MyFaces 1.1.1, but then you don't get some of the bug fixes in the latest release.
    It just desn't look like production ready IMO.

    Then don't use it. I don't agree. The value out weigh the issues for us. Facelets is fairly stable. It is more stable (it seems) than many of the JSF implementations.

    I am using MyFaces 1.1.1 and Facelets 1.0.7 in app that should go into production in March. It works well enough for our needs.
    What servlet container/app server do you use?Nebojsa
    Tomact 5.5.x.
  20. Still too much JSP[ Go to top ]

    I had hopes for this article in that it promised less JSP for JSF.

    Right. Total failure on that front from what I can tell. Tags everywhere, with the added bonus of a templating syntax on top of the tag pollution.

    I will not take JSF seriously until they abandon JSP and taglibs, or fix JSPs and the EL. Tapestry uses OGNL, a much better templating/data access language.

    Am I the only person who hates taglibs and the EL?
  21. Still too much JSP[ Go to top ]

    Those are not jsp tags. They are jsf tags. The syntax is similar, which you seem to have a problem with. I agree with the author in that those of us that have been doing web development with jsp and jstl with whatever framework, jsf with facelets will be easier to pick up than say something like tapestry. I inherited a tapestry app at my current job, and I don't like it. jsf seem more intuitive to me. But this is all opinion. Use whatever you are comfortable with.

    As far as how good facelets it, I'll have an opinion in a couple of months. I'm starting a new application in the coming weeks, and I've decided to use jsf with with facelets.
  22. Still too much JSP[ Go to top ]

    Those are not jsp tags. They are jsf tags. The syntax is similar, which you seem to have a problem with. I agree with the author in that those of us that have been doing web development with jsp and jstl with whatever framework, jsf with facelets will be easier to pick up than say something like tapestry. I inherited a tapestry app at my current job, and I don't like it. jsf seem more intuitive to me. But this is all opinion. Use whatever you are comfortable with. As far as how good facelets it, I'll have an opinion in a couple of months. I'm starting a new application in the coming weeks, and I've decided to use jsf with with facelets.

    It does look a bit like JSP, but it is not. There were no JSP tag files. JSF is natively supported by Facelets, you don't need taglibs. The articled focused on templates and composition components, and there is a lot more to Facelets than that.

    To me, composition components are the most compelling aspect of Facelets.

    You should check out the articles that Jacob wrote over at JSF central to give you a more balanced view of the technology.

    Here is an example how to render an employee form from a framework that I have been working on.

        <q:form crud="#{EmployeeCRUD}" focusField="lastName">
          <q:fields fieldNames="firstName,lastName,phone,current,birthDate,startDate"/>
          <q:checkBoxes fieldName="roles" />
          <q:dropdown fieldName="department" />
          <q:list fieldName="group" />
        </q:form>

    The above form renders Tomahawk Calendar component for birthDate and startDate. It renders related objects for editng as well. (Employee is in a department. Employee has many Roles. Employee is in a group. Etc.).

    The equiv. plain JSF/JSP would be a bit verbose. The real value add of Facelets (IMO) is the ability to define composite components (fields, checkBoxes, dropDown, list, form). This means that editing the Look and Feel for fields is in one place (you can break out anytime you want and mix and match components with composite components) the same for a standard form, etc. etc.
  23. Still too much JSP[ Go to top ]

    As said, it's not JSP tags at all. You're also completely free to use nothing but HTML with the jsfc attribute:

      <input type="text" jsfc="h:inputText" value="#{hello.world}" />

    For EL vs. OGNL, Facelets only uses the EL API - it has no dependencies on the EL syntax per se - and the EL APIs go through an ExpressionFactory that's replaceable. An OGNL fan should be able to code an ExpressionFactory that routes through OGNL, then you'd have Facelets + JSF using OGNL. (I've personally never been that concerned with this: yeah, OGNL has more features, I usually find EL sufficiently rich for my needs.)
  24. Re:L Still too much JSP[ Go to top ]

    I had hopes for this article in that it promised less JSP for JSF. Right. Total failure on that front from what I can tell. Tags everywhere, with the added bonus of a templating syntax on top of the tag pollution.

    As someone else pointed out, Facelets supports the same tag syntax as the JSF JSP tags, but it's definitely not JSP. Facelets also supports a Tapestry-style syntax that doesn't use these tags.
    I will not take JSF seriously until they abandon JSP and taglibs, or fix JSPs and the EL. Tapestry uses OGNL, a much better templating/data access language. Am I the only person who hates taglibs and the EL?

    Have you looked at JSF 1.2 and JSP 2.1? We fixed all of the JSP issues that plagued previous releases. There was even a group specifically dedicated to this task. As a result of that effort, the EL has been broken out into its own package, and might be handled through a separate JSR in the future. (The EL itself has improved as well.)

    Also, note that JSF _not_ require JSP, as Facelets and Struts Shale's Clay show.

    ---
    Kito D. Mann
    Author, JavaServer Faces in Action
    http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
  25. Still too much JSP[ Go to top ]

    Am I the only person who hates taglibs and the EL?

    No, I hate them too. It started when I discovered JSTL EL was a little different from JSF EL. That such a thing could ever happen says a lot.
  26. Still too much JSP[ Go to top ]

    Am I the only person who hates taglibs and the EL?
    No, I hate them too. It started when I discovered JSTL EL was a little different from JSF EL. That such a thing could ever happen says a lot.

    That was another JSP vs. JSF decision, but now the new EL-API will be a separate spec and is #{..} vs. ${..} agnostic. Example, Facelets can use either interchangably-- doesn't care. Actually, as Adam noted, Facelets doesn't care what EL implementation you use, so you could provide an OGNL or JS or C# EL implementation and use it with JSF 1.2 and Facelets. In relation to the previous TSS article on the new Script JSR, the EL API is much more robust with ELResolver chains and variable resolution for customizing concerns. You can with JSF, include a JBoss Seam variable resolver alongside a Spring variable resolver (although you may end up opening a rift in space that will consume us all).

    Anyways, now that the EL-API is separate (javax.el.*), we can take a look at evolving the EL semantics w/ projections and method invocation.
  27. Still too much JSP[ Go to top ]

    Am I the only person who hates taglibs and the EL?
    No, I hate them too. It started when I discovered JSTL EL was a little different from JSF EL. That such a thing could ever happen says a lot.

    I think the most anoying thing about taglibs , el and markup templates in general is that they break OO semantics. I dont mean to be negative about facelets but I prefer to work with a GUI API that generates HTML. What is wrong with that, why do we use templates? Is eclipse build with markup templates? Or are am i just an api person and are most developers template people?
  28. Still too much JSP[ Go to top ]

    Am I the only person who hates taglibs and the EL?
    No, I hate them too. It started when I discovered JSTL EL was a little different from JSF EL. That such a thing could ever happen says a lot.
    I think the most anoying thing about taglibs , el and markup templates in general is that they break OO semantics. I dont mean to be negative about facelets but I prefer to work with a GUI API that generates HTML. What is wrong with that, why do we use templates? Is eclipse build with markup templates? Or are am i just an api person and are most developers template people?

    http://www.jsfcentral.com/articles/facelets_3.html
  29. Still too much JSP[ Go to top ]

    I think the most anoying thing about taglibs , el and markup templates in general is that they break OO semantics. I dont mean to be negative about facelets but I prefer to work with a GUI API that generates HTML. What is wrong with that, why do we use templates? Is eclipse build with markup templates? Or are am i just an api person and are most developers template people?

    No, I'm with you all the way. Have you checked out echo2?
  30. Still too much JSP[ Go to top ]

    I have. And loving it. (Obviously I am an API person too)
  31. Still too much JSP[ Go to top ]

    I think the most anoying thing about taglibs , el and markup templates in general is that they break OO semantics.

    Exactly. That's what I hate about frameworks (not just web frameworks) that focus on 'declarative' instead of old skool OO programming. While the declarative way sometimes can speed up development quite a bit, you'll often end up painting yourself in the corner because framework X didn't think of supporting case Y. Or you'll end up with a mess of functionality scattered throughout files that all have different sematics (and which your IDE might not understand, refactor, etc). And to overcome that, new frameworks are being build on top of that, which in the case of facelets DO make JSF a lot nicer to work with, but are imo still an admission of weakness in the first place. Stacking more frameworks makes it harder to understand what is happening under the hood, and it gets you more possible points of failure.
    I dont mean to be negative about facelets but I prefer to work with a GUI API that generates HTML.

    If you want to generate HTML, there's nothing wrong with templates imo. Let's you keep close to the source of things, and if you don't use that, you have to come up with abstractions (like a layout mechanism) which might distract you from your intended end result. However, sounds like Echo is a framework you'll like.
    Or are am i just an api person and are most developers template people?

    I don't think most developers are. It just seems like a lot of framework builders think it is the developer's holy grail to cancel out actual programming from the development process :)
  32. Still too much JSP[ Go to top ]

    I don't think most developers are. It just seems like a lot of framework builders think it is the developer's holy grail to cancel out actual programming from the development process :)

    This has been going on since LISP was in vogue back in the 1970s. There's this balancing act between code and data. Data-driven code can be really useful at times. But when you take it too far, you wind up making the data into code again (and usually a weaker version of the code too). The right balancing point to my eye seems to be making an extensible code-based framework where a few very specific and very limited problems are extended to be data driven.
  33. Still too much JSP[ Go to top ]

    Like any feature, data-driving something should be use-case based and need-driven.
  34. Still too much JSP[ Go to top ]

    And to overcome that, new frameworks are being build on top of that, which in the case of facelets DO make JSF a lot nicer to work with, but are imo still an admission of weakness in the first place. Stacking more frameworks makes it harder to understand what is happening under the hood, and it gets you more possible points of failure.

    I don't think you really understand what JSF is. It's more of a platform than a framework. Not to play with terms but you are right in saying that there is a lot of plugability and flexability. The goal of this JSR is quite emense and overwhelming at times, but it's point is to provide a foundation that developers and vendors and use off the shelf or build upon. I look at what wicket is doing and what clay does, and I see a lot of similarities in that I can, with JSF, construct a component model in Java code and expose it via the binding attribute of all JSF components. Essentially, wickets scaffolding objects could be wrapped over JSF just as easily as JBoss Seam can delegate injection lifecycles and state coordination within the JSF platform.

    In summary, I do like the focus that wicket presents, but a lot of the ideas could be implemented as a Java-centric facade on top of JSF as a platform and as part of the JEE 5 spec.
  35. Still too much JSP[ Go to top ]

    I've obviously got my own personal issues going on here, but I'd like someone out there to understand why this concept just fundamentally doesn't work for me, even if they don't necessarily agree with me fully.

    I believe that programming is a linguistic enterprise and that the whole point of building platforms and frameworks is not to provide mathematical abstractions by committee which are infinitely extensible and toolable, but to provide simple, highly refined abstractions that fully solve the problem at hand by leveraging language and what people already know about the world.

    From my perspective, a really good /anything/ in programming tells a story and functions to a very high degree in terms of specific, carefully chosen language. That seems to have gotten lost somewhere along the way in programming... or maybe only dimly recognized in the first place.
     
    The result for me as a programmer of today's corporate, committee-driven process is something like reading a novel written by the marketing team at a publishing company.

    I would never be satisfied with Wicket written in JSF for this reason (if that's what you're suggesting). It's like saying "we've got this great drama", why don't you add some funny bits and ship it as a comedy? For me, a big part of Wicket has been trying to make the packages and classes and methods of the framework lead the programmer through the story of building a web application. It's not for me to say whether we accomplished this or not, but that is what we have been trying to do. I really do not get the same sense about JSF (just for example). Why that is, I don't precisely know. But for a counter-example, look at the collections classes. This is great stuff to me because it's so well thought out as a story. How things are organized and named and how things work forms a consistent and detailed narrative which anyone can pick up on immediately (at any scale). I wish other stuff in Java could be more like this. More like the old days when Java was new and telling a story with the JDK that made so much more sense than the available alternatives. We were going to take over the universe. What happened?
  36. Still too much JSP[ Go to top ]

    More like the old days when Java was new and telling a story with the JDK that made so much more sense than the available alternatives. We were going to take over the universe. What happened?

    We did take over.
  37. Still too much JSP[ Go to top ]

    More like the old days when Java was new and telling a story with the JDK that made so much more sense than the available alternatives. We were going to take over the universe. What happened?
    We did take over.

    And who's helping that? 'You' didn't make my job nicer nor did you help me develop faster, more robust etc. Exactly those things that an API like collections did for me.
  38. Still too much JSP[ Go to top ]

    More like the old days when Java was new and telling a story with the JDK that made so much more sense than the available alternatives. We were going to take over the universe. What happened?
    We did take over.
    And who's helping that? 'You' didn't make my job nicer nor did you help me develop faster, more robust etc. Exactly those things that an API like collections did for me.

    As someone who switched from Struts to JSF, I certainly found that JSF made my job nicer and helped me develop a lot faster. I am about to take a look at Facelets, and I expect - from the reports I have heard - that it will improve things even more.

    Java makes even more sense than the alternatives these days than it did many years ago. I remember the time when it was was dead slow, and with buggy implementations on platforms such as Linux. Java when new was barely usable, as I remember things.
  39. Still too much JSP[ Go to top ]

    Yeah, if you are comparing with Struts, I agree. JSF is a step forward.
  40. Still too much JSP[ Go to top ]

    I believe that programming is a linguistic enterprise and that the whole point of building platforms and frameworks is not to provide mathematical abstractions by committee which are infinitely extensible and toolable, but to provide simple, highly refined abstractions that fully solve the problem at hand by leveraging language and what people already know about the world.

    Yes totally! I believe components are the building blocks of that functionality. We take known pieces of knowledge and development and then compose them into higher level concepts that ease development. You can have experts from EJB3 or from some vendor provide you with a foundation of components from which to compose applications. Spring does the same with all of their API's beans that simplify the JEE stack. JSF's role as a spec seeks to gather knowledge under a common interface.

    ....I would never be satisfied with Wicket written in JSF for this reason (if that's what you're suggesting). It's like saying "we've got this great drama", why don't you add some funny bits and ship it as a comedy? For me, a big part of Wicket has been trying to make the packages and classes and methods of the framework lead the programmer through the story of building a web application.

    Again, I really am fond of the Java-centric approach for development. But, I still have intimate knowledge of the fact that JSF component models can be composed out within java code too. Providing a foundation of contracts in Java, and using the binding attribute of JSF, you can have 'page' POJOs with properties that programatically compose your dynamic bits.

    -- Jacob
  41. Still too much JSP[ Go to top ]

    Again, I really am fond of the Java-centric approach for development. But, I still have intimate knowledge of the fact that JSF component models can be composed out within java code too. Providing a foundation of contracts in Java, and using the binding attribute of JSF, you can have 'page' POJOs with properties that programatically compose your dynamic bits.-- Jacob

    I have no doubt that you can do almost anything in JSF (or JSP for that matter). The truth is, you can create really nice OO programs in C if you follow the right discipline. The trouble I have with JSF isn't that it can't do the job, but rather that the narrative isn't compelling and powerful and intuitive to me. It doesn't hide the parts and concepts I don't want to be bothered with by maximally leveraging what I already know. A framework is great when it makes complex things look easy because of all the hard work and abstracting and refactoring that went into telling a great story.

    Now I could try to make some big long argument by zeroing in on dozens of qualitative issues that rub me the wrong way just on the surface of JSF (although I'm no JSF guru), but the bottom line is that I know enough to know I don't like it and it's a value judgement in the end. For me, the root problem is that JSF just doesn't tell the story of web application development in a conservative, expressive, powerful, intuitive way.

    Why should I need 'intimate knowledge' of JSF to make components and models work? Shouldn't that be blindlingly obvious and intuitive in the API itself? Wouldn't 'extends' be a good way to create new components? Wouldn't setModel() be a good way to set the model on a component? And so on... Shouldn't the code itself tell the story in a way that obviates much of the need for documentation? Want to write a Wicket web application? public class MyWebApplication extends WebApplication { }. Could anyone fail to understand that? (I'm not suggesting wicket is ideal, just that we really put a HUGE amount of work into making our story as obvious and as simple and as powerful as possible. This meant a lot of /cutting/ and refactoring of code, btw)

    JSF DOES solve a certain class of problems for a certain class of people. What rubs me the wrong way is that some JSF advocates seem to think that just because their story is COMPLETE and WELL KNOWN, it ought to be good enough for the rest of us. It's not! Some of us want to hear a simpler story! One that moves US rather than vice versa. I'm reminded of this quote:

    "Poor Faulkner. Does he really think big emotions come from big words? He thinks I don't know the ten-dollar words. I know them all right. But there are older and simpler and better words, and those are the ones I use."

      -- Ernest Hemingway
  42. Still too much JSP[ Go to top ]

    Jonathan, I understand your points, but let me compare a couple things then for everyone else, using the Wicket GuestBook Example:

    In JSF, we work with plain old POJOs, test anything you want within a static main or a local JUnit without mocks. The logical extension of 'WebPage' isn't necessary with JSF. While abstraction/delegation can always occur, it's not necessary with JSF since the wiring/ioc logic is externally configured, promoting re-use. JSF provides a blank sheet to compose your Java code (or story) however you want in simple bean terms-- you decide how to scale complexity-- as simple of a story as you want without complicating your Java with component knowledge or semantics.

    Instead of tying to 'onSubmit', you just provide a public method that returns an Object-- String, Enum, etc to control flow. So I could just have public String addComment() as my action method on my POJO bean, disregarding the 1:1 relationship between forms and actions. Within a given view/form, I can have N actions/events for various CRUD requirements.

    On to wicket documents. How does Guestbook.html, with id decoration any different than what Tapestry or Facelets can do? What logic can I optionally include or coordinate in that document without declaring or matching the UI with the Java code? Many have mentioned the compositional capabilities of Facelets and since components can/are defined in the document, you have the ability to re-use pieces of the UI independent of assertions within a page based Java model. IMHO, JSF has a *true* component model for this reason. Rick's article has a great example of this where a whole series of CRUD components for the UI work directly off of the same beans you wrote 8 months ago for use with Hibernate.

    Please don't get me wrong. I think the facade that Wicket provides is a great 'story', but JSF and Wicket have different goals. Just like Spring provides hand-holding bean wrappers for JEE artifacts and concerns, I see no reason why someone couldn't publish the same for JSF, although I'm not sure the need is really there given that there are no APIs asserted on your Java model.
  43. Still too much JSP[ Go to top ]

    I think the facade that Wicket provides is a great 'story', but JSF and Wicket have different goals. Just like Spring provides hand-holding bean wrappers for JEE artifacts and concerns, I see no reason why someone couldn't publish the same for JSF, although I'm not sure the need is really there given that there are no APIs asserted on your Java model.

    You shouldn't make the mistake of assuming that Wicket is hardwired to web server technology simply because we provide a WebPage abstraction that directly and intuitively solves the problems of 99.9% of our audience. Wicket is about programmatic manipulation of markup in general. The wicket.markup.html package and wicket.protocol.http package are just the present focus of things. To dismiss Wicket as a facade that provides a mere layer of hand-holding above something that is somehow JSF-like is to misunderstand its essential nature. There is a lot more to Wicket than meets the eye... by design.

    If other people decide for themselves (and not due to FUD and marketing) that JSF is the best story for them, more power to them. Everyone has their own aesthetics and needs and I'm all for more stories. I just urge readers to be literate and make an informed decision.
  44. Still too much JSP[ Go to top ]

    Instead of tying to 'onSubmit', you just provide a public method that returns an Object-- String, Enum, etc to control flow. So I could just have public String addComment() as my action method on my POJO bean, disregarding the 1:1 relationship between forms and actions. Within a given view/form, I can have N actions/events for various CRUD requirements.

    I've read this several times now and I still don't understand what you're getting here with JSF except for a tooling hook. The addComment() or equivalent method is in the business layer in a good app. The fact that a form onSubmit() method calls it doesn't hardwire the two things into a 1:1 relationship! You can call the methods in the business layer from anywhere. Right? In fact, a well-coded onSubmit() handler in Wicket is typically going to be something like a single line call into the busines layer to persist the object. A very simple, readable line that you can put anywhere and which everyone will understand at first glance. And if you want more submit buttons that do fancy crud things to objects in the form, you just override onSubmit() on each form button... this is even highly reusable since you can provide stock buttons for something like a listview which do the crud operations no matter what is in the list. In fact, ListView actually includes methods that get moveUpLink, moveDownLink and removeLink components for the list that you can place anywhere you want (this may not be exactly how you want this done, but it's nice free functionality). I'm just totally lost as to why the JSF approach is better, except that it's easier to tool. The abstraction you're talking about, since it is not focused, actually makes the problem harder to solve (for me without tools, anyway).
  45. Still too much JSP[ Go to top ]

    I don't think you really understand what JSF is. It's more of a platform than a framework.

    I don't think you really understand how most developers are totaly not intersted in whether JSF is a framework or a platform when reading a line like: 'JavaServer Faces technology simplifies building user interfaces for JavaServer applications', which is the first line of SUN's description of JSF.
    I look at what wicket is doing and what clay does, and I see a lot of similarities in that I can, with JSF, construct a component model in Java code and expose it via the binding attribute of all JSF components. Essentially, wickets scaffolding objects could be wrapped over JSF just as easily as JBoss Seam can delegate injection lifecycles and state coordination within the JSF platform.In summary, I do like the focus that wicket presents, but a lot of the ideas could be implemented as a Java-centric facade on top of JSF as a platform and as part of the JEE 5 spec.

    I was deliberatly not mentioning Wicket in this thread, sorry it ended up here.

    But... it is very interesting that you say that. In fact some people - including me - looked at whether/ how we could integrate with JSF. Not that anyone on the lists asked for it, but just to play nicely with the rest of java land. My conclusion was that the JSF is highly procedural in nature, and thus not a very good match with Wicket.

    If you think we crappy programmers again didn't understand a thing about JSF, and you or someone else has a bit of spare time, please check out this feature request to investigate JSF interoperability. If you can write that within a month, I'll never bitch about JSF again :)
  46. Still too much JSP[ Go to top ]

    My conclusion was that the JSF is highly procedural in nature, and thus not a very good match with Wicket.If you think we crappy programmers again didn't understand a thing about JSF, and you or someone else has a bit of spare time, please check out this feature request to investigate JSF interoperability. If you can write that within a month, I'll never bitch about JSF again :)

    Heheh, if I didn't have so much on my plate right now, I might just take you up on that, hmmm.... ;-)

    I am kind of struck by the comment that JSF is procedural. I have to disagree-- request/action frameworks feel more procedural than what our component frameworks are doing. I know we discussed this in Kito's W.A.G, but the 5 steps of MVC are common to all frameworks. You have components that encapsulate/participate in all phases of MVC, not just rendering. The lifecycle/controller of JSF only interacts with the top most root element of the view, allow it and all of its children to manage their own state and behavior. To me, this feels very OO. You could grab instances of JSF components and when you validate, you just call validate on them-- when you render, you just call render on them.
  47. Still too much JSP[ Go to top ]

    Heheh, if I didn't have so much on my plate right now, I might just take you up on that, hmmm.... ;-)

    And I wasn't even kidding. If it is possible to create such an integration without too many sacrifices, that'd be awesome. In the end, it's all about choice for developers. Let us hear when you have more time then :)
  48. Still too much JSP[ Go to top ]

    Yeah, I took a long stare at JSF one afternoon and could not figure out how to integrate it with Wicket in either direction. I'm not entirely sure if it's even possible without major modifications to one framework or the other.

    Wicket is very listener-oriented and event driven and the details of request processing and response generation are intentionally buried in the framework implementation details for HTTP/HTML. In fact, in Wicket 1.2, the whole request-processing/response-generating strategy is actually abstracted out and replaceable, so it's OO all the way down and you're not tied to any specific strategy if a new markup protocol comes along (I've had some interesting thoughts about what this might mean, but that's another story). JSF, on the other hand, seems to have a more explicit model where the sequence of request processing is part of the component contract (please correct me if I'm wrong). So, the two things don't seem to me like they actually meet at all because the approaches are so wildly different.
  49. Wicket 1.2 Follow-up[ Go to top ]

    In fact, in Wicket 1.2, the whole request-processing/response-generating strategy is actually abstracted out and replaceable, so it's OO all the way down and you're not tied to any specific strategy if a new markup protocol comes along (I've had some interesting thoughts about what this might mean, but that's another story).

    Just curious what markup/protocols you had in mind? Markup targetting different devices or semantic XML markup?

    Also like to mention that I appreciated your comments on targetting data-driven solutions to specific well-defined problems, and the larger point about expressiveness / programming narratives. Well put.
  50. Wicket 1.2 Follow-up[ Go to top ]

    I'm really not sure. The world right now is very HTTP/HTML. You could, of course, do something with existing markup or existing protocols. But this does not interest me very much.

    My thought right now is more towards a new definition of what a browser is. You could create a very interesting Java browser by having markup tags defined by Swing/Java2D Sprocket-like components. But these components would have a basis in the server as well. In such a world, you've got Wicket components that are actually emanating very sophisticated sprockets on the client and the browser is really just a big Sprocket factory.

    In a somewhat bigger version of this vision, the gap between client and server actually disappears and the markup floats around on the network along with its sprockets (which can be installed via something like OSGi) and that markup actually knows how to seek out and connect securely to Wicket components that might be running (or might start up!) anywhere. The markup may require Java code (either sprockets or backing components) in a Jini-like way, but it's just a markup file. The binding to the "client" interactivity and the "server" components occurs at the time it's needed. So there's no fixed server. Just markup that you can browse to or email or load from a file and once you have the network you've got interactivity (with a little encryption and a lookup mechanism).
  51. Still too much JSP[ Go to top ]

    request/action frameworks feel more procedural than what our component frameworks are doing.
    One can create and use components with action frameworks or even with plain JSP. All depends on your definition of component.
  52. Still too much JSP[ Go to top ]

    Am I the only person who hates taglibs and the EL?
    No, I hate them too. It started when I discovered JSTL EL was a little different from JSF EL. That such a thing could ever happen says a lot.
    I think the most anoying thing about taglibs , el and markup templates in general is that they break OO semantics. I dont mean to be negative about facelets but I prefer to work with a GUI API that generates HTML. What is wrong with that, why do we use templates? Is eclipse build with markup templates? Or are am i just an api person and are most developers template people?

    In theory you could build JSF without any markup language. I still prefer templates for document oriented things.
  53. and we need gloves in canada..[ Go to top ]

    I found facelets when I was evaluating JSF and about to give up and go back to struts.. facelets addressed all my major concerns with JSF and made UI development fun again :)

    my three favourite things about facelets are:

    1) facelets makes custom component, validator and converters development quick, easy and fun.. which is the only way component-based ui technology is going to succeed

    2) although tiles is good, IMO, facelet's templating is better.. (and still improving)..

    3) you can mix and match jsf, jstl and plain html tags.. this is especially useful for creating custom components without writing any java code

    also, I think it should be mentioned that you can't beat the support on the user dev list.. props to the facelets crew for that!

    james
  54. Re: and we need gloves in canada..[ Go to top ]

    I think it should be mentioned that you can't beat the support on the user dev list.. props to the facelets crew for that! james

    +1 for that. I've been subscribing to the list for a couple of weeks now and find that Jacob Hookom, who is the main Facelets developer and member of the JSF expert group I believe, posts responses daily to user problems.

    They are very responsive...
  55. Facelets fits JSF like a glove[ Go to top ]

    Trying to combine JSF and JSP is like trying to shoehorn a foot into a glove
    If you are Java man (as in prehistoric), putting a glove on your foot is easy and might even seem natural. But for those of us who are more evolved, it is a painful experience. :) Me? I think I am beyond even needing to put gloves on my hands. ;)
  56. Series of articles about Facelets[ Go to top ]

    FYI, there is a series of articles by Jacob Hookom (Facelet's creator) at JSF Central. It starts with an intro and describes different sets of features, so it's great to read if you're new to the technology.

    ---
    Kito D. Mann
    Author, JavaServer Faces in Action
    http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
  57. I was working with a dedicated, intelligent junior Java programmer the other day to get a JAAS login page to work in a Web app that used JSF. I had read the JSF 1.1 spec and almost puked, then avoided dealing with JSF except to work minimally within it (around it, really) implementing some DHTML menus for some of our apps.

    So I am trying to suss out how the hell to get the web.xml and faces-config.xml cooperating. Things like welcome pages and authentication elements in web.xml seem to have no friendly counterpart in the faces-config.xml. I noticed our TLD file sitting there in the WEB-INF. I've worked with Servlets and JSP almost since the beginning. There's this mountain of stuff that the JCP keeps dropping on us and it is all so poorly integrated, refactored, reduced.

    People aren't going to give up on JSF, JSP, Myfaces, etc. No. People are just going to be forced to look elsewhere for a new solution that takes all this crap and spits out a neat, condensed framework that does the same thing. And the JCP will be forced to chase behind it and crown it the canonical solution eventually. And then, sure enough, given the oligarchic and aristocratic nature of the JCP, they'll build on it and make another big mess.

    Ahh, that feels better. Screw JSF. It's a pile of crap.
  58. Fair is fair :-) The JAAS stuff is a dissapointment, but Kito has covered how to do this in his writings on JSF.

    You could say the same thing about going from a simple JDBC Rowset to a full blown ORM with lazy/proxy configuration, etc. Yeah, it can be a pain to get up and running, but people do so because it will make app maintenance easier down the road.

    In applicable terms, Action frameworks are pretty lightweight to get up and running, but as your requirements ramp up within the UI and managing state, then choosing JSF/component frameworks makes more sense. I've been yanked through the coals on a different project, trying to coordinate the state of sortable tables, filtered data, with assorted forms. I did it, but it's a custom solution that with a JSF component/state management, for which I wouldn't have needed to concern myself with or anyone else's time. There's that 'drop in factor' with components in a lot of the new frameworks.
  59. Here's a quick way to do authentication and annotation-driven, role-based authorization in Wicket (there are more flexible ways to do this as well):


    public class MyAuthenticatedWebApplication extends AuthenticatedWebApplication
    {
    public static class MyAuthenticatedWebSession extends AuthenticatedWebSession
    {
    private boolean signedIn;

    public MyAuthenticatedWebSession(AuthenticatedWebApplication application)
    {
    super(application);
    }

    public boolean authenticate(String username, String password)
    {
    return signedIn = username.equals("jonathan") && password.equals("jonathan");
    }

    public boolean isSignedIn()
    {
    return signedIn;
    }

    public Roles getRoles()
    {
    if (signedIn)
    {
    return new Roles("ADMIN");
    }
    return null;
    }
    }

    protected Class< ? extends AuthenticatedWebSession> getWebSessionClass()
    {
    return MyAuthenticatedWebSession.class;
    }

    protected Class< ? extends SignInPage> getSignInPageClass()
    {
    return SignInPage.class;
    }

    public Class getHomePage()
    {
    return HomePage.class;
    }
    }

    public class HomePage extends WebPage
    {
    }

    <html>
    <head>
        <title>HomePage</title>
        <link rel="stylesheet" type="text/css" href="style.css"/>
    </head>
    <body>
        <h2>Welcome!</h2>
        
        This page should be accessible to everyone.
        
    <wicket:link><a href="AdminPage.html">Admin Page</a></wicket:link><br/>
    <wicket:link><a href="SignOutPage.html">Sign Out</a></wicket:link>

    </body>
    </html>

    @AuthorizeInstantiation("ADMIN") // Require "ADMIN" roled to instantiate this page
    public class AdminPage extends WebPage
    {
    }

    <html>
    <head>
        <title>AdminPage</title>
        <link rel="stylesheet" type="text/css" href="style.css"/>
    </head>
    <body>
        <h2>Welcome ADMIN!</h2>
        
        This page should only be accessible if you are signed in as an administrator.
        
    <wicket:link><a href="HomePage.html">Home</a></wicket:link><br/>
    <wicket:link><a href="SignOutPage.html">Sign Out</a></wicket:link>

    </body>
    </html>

    public final class SignInPage extends wicket.authentication.SignInPage
    {
    }

    <html>
    <head>
        <title>SignInPage</title>
        <link rel="stylesheet" type="text/css" href="style.css"/>
    </head>
    <body>
    <h2>Sign In</h2>
        <i>Username and password are both "jonathan"</i>
        
        <span wicket:id="signInPanel"/>
    </body>
    </html>

    public class SignOutPage extends wicket.authentication.SignOutPage
    {
    }

    <html>
    <head>
        <title>SignOutPage</title>
        <link rel="stylesheet" type="text/css" href="style.css"/>
    </head>
    <body>
    <h2>Goodbye!</h2>

    <wicket:link>
    <a href="HomePage.html">Home</a>
    </wicket:link>
    </body>
    </html>
  60. Nothing would stop a developer from doing the *exact* same artifacts with JSF, because JSF works directly with POJOs. Even with the new EL and plugable property/variable resolution, you could tie in Aegis or custom ActionListeners or PhaseListeners on the global level.

    I agree with the original poster though that JAAS/Realms should've been tied into JSF directly, but within the JSF API itself, you can access principle/role information agnostically from a portlet or servlet deployment (see here).

    Really though, thanks Jonathan for spamming yet another thread with lots of wicket code.

    Yours, Jacob
  61. Well, sorry about the code, but frankly talking about the code doesn't make my point. The truth of the matter is you can accomplish the exact same thing in JSP or assembly language. It's a matter of expressiveness, simplicity, legibility, intuitiveness and direct applicability to the problem. I ran screaming from JSP, JSF and Tapestry not because I wanted to go build something, but because I found that these technologies didn't cut it. If you'd like to see why, please post the /complete/ code for a JSF application demonstrating authentication and role based authorization (the above code is the ENTIRE application)... maybe I'm behind the times and it will be shorter, simpler, more legible and more intuitive than the code above, but I seriously doubt it.
  62. http://wicket.sf.net/
  63. Wicket seems verbose to me[ Go to top ]

    http://wicket.sf.net/

    I went through some of the examples in the Wicket documentation. It seems a bit verbose compared to JSF. This is just a cursory look. I will admit Wicket does seem cool.

    I am pretty big on the idea of web components. I wouldn't mind working on a project that used Wicket, Echo2, Tapestry, and JSF. There seems to be more JSF projects available. I have no problems getting work doing JSF.

    I helped put an app into production mere months after JSF was released.
  64. Wicket seems verbose to me[ Go to top ]

    http://wicket.sf.net/
    I went through some of the examples in the Wicket documentation. It seems a bit verbose compared to JSF. This is just a cursory look. I will admit Wicket does seem cool. I am pretty big on the idea of web components. I wouldn't mind working on a project that used Wicket, Echo2, Tapestry, and JSF. There seems to be more JSF projects available. I have no problems getting work doing JSF.I helped put an app into production mere months after JSF was released.

    I wouldn't mind working on a project that used Wicket, Echo2, Tapestry, or JSF.

    I forget "or" and just put "and". It would be strange project indeed if it used all of those at the same time.

    My point....
    I've spent a lot of time trying to make Struts do things it was never designed to do. Those same things are child's play in JSF as they would likely be in Echo2, Wicket, and/or Tapestry.

    Any component oriented development would be more preferable (to me) than Struts. This is not to say never to working wtih Struts, but it would not be my choice.
  65. Component based frameworks[ Go to top ]

    Any component oriented development would be more preferable (to me) than Struts. This is not to say never to working wtih Struts, but it would not be my choice.

    Same here.
  66. Component based frameworks[ Go to top ]

    Any component oriented development would be more preferable (to me) than Struts. This is not to say never to working wtih Struts, but it would not be my choice.
    Same here.

    "Would you like fries with that?" would be better than Struts.
  67. Component based frameworks[ Go to top ]

    Any component oriented development would be more preferable (to me) than Struts. This is not to say never to working wtih Struts, but it would not be my choice.
    Same here.
    "Would you like fries with that?" would be better than Struts.

    That's pretty funny. :o)
  68. Component based frameworks[ Go to top ]

    Any component oriented development would be more preferable (to me) than Struts. This is not to say never to working wtih Struts, but it would not be my choice.
    Same here.
    "Would you like fries with that?" would be better than Struts.
    I guess the upside is that contract would last longer. Just as long as the customer understands that. :)
  69. Component based frameworks[ Go to top ]

    Any component oriented development would be more preferable (to me) than Struts. This is not to say never to working wtih Struts, but it would not be my choice.
    Same here.
    "Would you like fries with that?" would be better than Struts.
    I guess the upside is that contract would last longer. Just as long as the customer understands that. :)

    I didn't think of that. I am losing money by doing JSF. Heheh. :)
  70. Component based frameworks[ Go to top ]

    I didn't think of that. I am losing money by doing JSF. Heheh. :)
    Well, there is no way you can be good consultant then, right? :) lol.
  71. Wicket seems verbose to me[ Go to top ]

    Any component oriented development would be more preferable (to me) than Struts. This is not to say never to working wtih Struts, but it would not be my choice.

    And what prevents you from using components in Struts?
    Or what does in mean component in your terms?

    Marina
    http://www.servletsuite.com
  72. Wicket seems verbose to me[ Go to top ]

    Any component oriented development would be more preferable (to me) than Struts. This is not to say never to working wtih Struts, but it would not be my choice.
    And what prevents you from using components in Struts?
    Or what does in mean component in your terms?

    Marina
    http://www.servletsuite.com

    Action-oriented frameworks, or all MVC frameworks, cover the same 5 steps in some form or another: decode, validate, update, invoke, encode. Encode is basically rendering the view. JSF's true component framework-- they are self contained, participate in all MVC steps, and are relationally agnostic (UIComponent<->UIComponent). We're not just talking about rendering. In terms of something similar in the MVC realm-- take WebWorks' Action Chaining to the next level where you have a root action (or UIViewRoot) that gets a request event, and then the process perculates through a series of succeeding actions in the chain (or child UIComponents) to participate in updating, validation, behavior invocation, and rendering. Basically, we aren't just talking about rendering stuff to the screen.
  73. Wicket seems verbose to me[ Go to top ]

    JSF's true component framework-- they are self contained, participate in all MVC steps, and are relationally agnostic (UIComponent<->UIComponent). We're not just talking about rendering. In terms of something similar in the MVC realm-- take WebWorks' Action Chaining to the next level where you have a root action (or UIViewRoot) that gets a request event, and then the process perculates through a series of succeeding actions in the chain (or child UIComponents) to participate in updating, validation, behavior invocation, and rendering. Basically, we aren't just talking about rendering stuff to the screen.

    it could be true for any JavaBean. It is not against JSF. I am just confused with the term "true" component. Does it mean in your explanation that non-JSF is not "true"? It sounds so :(
  74. Wicket seems verbose to me[ Go to top ]

    Any component oriented development would be more preferable (to me) than Struts. This is not to say never to working wtih Struts, but it would not be my choice.
    And what prevents you from using components in Struts?Or what does in mean component in your terms?Marinahttp://www.servletsuite.com

    Well just to make the problem a little bit more accessible, you can make components, use program a taglib, but as soon as you want to do more than rendering you have to program a framwork for providing component hooks back into the action, as soon as you have more complicated stuff, you have to add hooks which provide an event system on top of the single event system action. And guess what, you just have duplicated the effort JSF has done for you already.
  75. Wicket seems verbose to me[ Go to top ]

    Well just to make the problem a little bit more accessible, you can make components, use program a taglib, but as soon as you want to do more than rendering you have to program a framwork for providing component hooks back into the action, as soon as you have more complicated stuff, you have to add hooks which provide an event system on top of the single event system action. And guess what, you just have duplicated the effort JSF has done for you already.

    In my view the component must be framework agnostic. The component != framework. And we should not mix that.
  76. Wicket seems verbose to me[ Go to top ]

    In my view the component must be framework agnostic. The component != framework. And we should not mix that.

    To reply to both of your comments, components in JSF terms, are composed by relationship, not by type. This allows you to evaluate the view in whole or in part since they are self-contained objects within the system, sharing a common contract of integration and composed independently of chosen tools (straight java, JSP, facelets, clay, etc). This really echos the signifigance of JSF's component model.

    For your point above, your business components are agnostic of the framework, ideally suited within JSF-- since they do work with POJOs and JSF's UIComponents instead act upon your model instead of requiring your model to act upon them. So with JSF, you aren't mixing 'that'.
  77. Wicket seems verbose to me[ Go to top ]

    Well just to make the problem a little bit more accessible, you can make components, use program a taglib, but as soon as you want to do more than rendering you have to program a framwork for providing component hooks back into the action, as soon as you have more complicated stuff, you have to add hooks which provide an event system on top of the single event system action. And guess what, you just have duplicated the effort JSF has done for you already.
    In my view the component must be framework agnostic. The component != framework. And we should not mix that.

    Impossible, due to the fact, that HTML neither knows components nor events, nor a binding so that you can influence that stuff on a backend side.
    The problem is you have to rely on something as soon as you have a non stateful non event aware protocol underneath.
    To give you an example classical windowing toolkits. X comes closest, no components, there is no component model which does not need a framework underneath. In windows you have that but only because the components are covered to a big degree by Windows and also the event system, but as soon as you need components, you already run into different frameworks.

    Good thinking, but show me the possibility of having a framework agnostic component model in HTML it is not possible unless you go for a framework and provide hooks from every framework there is into this component framework.

    You cannot go for components without some kind of binding into the backend and without adding a decent event system, to the one event system html has.
  78. Wicket seems verbose to me[ Go to top ]

    Impossible, due to the fact, that HTML neither knows components nor events, nor a binding so that you can influence that stuff on a backend side.

    HTML is a presentation stuff. You should use HTTP here, is not it? And because we are talking about web development it is correct to rely on HTTP.

    Anything you are doing in JSF (or whatever do you use) for the web will be covered by HTTP at the end of the deal.
  79. Impossible, due to the fact, that HTML neither knows components nor events, nor a binding so that you can influence that stuff on a backend side.
    HTML is a presentation stuff. You should use HTTP here, is not it? And because we are talking about web development it is correct to rely on HTTP.Anything you are doing in JSF (or whatever do you use) for the web will be covered by HTTP at the end of the deal.

    I much prefer a framework that hide the protocol detail for me. I taught we all agreed the Context design pattern is a very good practice. Especially, if a new Http version appears in the future. Who knows?

    By the way, Oracle has developped a telnet renderkit so Http is not always the protocol used in the end with JSF.
  80. I much prefer a framework that hide the protocol detail for me. I taught we all agreed the Context design pattern is a very good practice.

    right, that is what framework is for. But "hide" does not mean "dismiss" or "eliminate".
    Especially, if a new Http version appears in the future. Who knows?By the way, Oracle has developped a telnet renderkit so Http is not always the protocol used in the end with JSF.
    ja,ja - web 3.0 :)
  81. Wicket seems verbose to me[ Go to top ]

    Any component oriented development would be more preferable (to me) than Struts. This is not to say never to working wtih Struts, but it would not be my choice.
    And what prevents you from using components in Struts?Or what does in mean component in your terms?Marinahttp://www.servletsuite.com
    Well just to make the problem a little bit more accessible, you can make components, use program a taglib, but as soon as you want to do more than rendering you have to program a framwork for providing component hooks back into the action, as soon as you have more complicated stuff, you have to add hooks which provide an event system on top of the single event system action. And guess what, you just have duplicated the effort JSF has done for you already.

    Come on. Reinventing the wheel is fun! :o)
  82. Facelets fits JSF like a mask[ Go to top ]

    Is it just me or does mixing Facelets and gloves seem wrong to you? How about "Facelets fits JSF like a mask"? Or "Facelets, like putting lipstick on a JSF"? "Facelets the facts, its JSF"?
  83. Facelets fits JSF like a mask[ Go to top ]

    Is it just me or does mixing Facelets and gloves seem wrong to you? How about "Facelets fits JSF like a mask"? Or "Facelets, like putting lipstick on a JSF"? "Facelets the facts, its JSF"?

    Cute. Have you tried Facelets? Did you get a chance to read the article?

    JSF is the most productive web app API that I have used. Facelets makes it a lot more productive.

    We have compared older apps to newer apps with a framework (developed internally) that utilizes Facelets. We saw drastic reduction in code. Composition Components are sweet.
  84. Facelets fits JSF like a mask[ Go to top ]

    Is it just me or does mixing Facelets and gloves seem wrong to you? How about "Facelets fits JSF like a mask"? Or "Facelets, like putting lipstick on a JSF"? "Facelets the facts, its JSF"?
    Cute. Have you tried Facelets? Did you get a chance to read the article?JSF is the most productive web app API that I have used. Facelets makes it a lot more productive.We have compared older apps to newer apps with a framework (developed internally) that utilizes Facelets. We saw drastic reduction in code. Composition Components are sweet.

    Totally agree, working with JSF after 2 or 3 years of Struts is very refreshing.
  85. And facelets of course!
  86. Facelets fits JSF like a mask[ Go to top ]

    And facelets of course!

    Good to know. I thought you were more of a detractor. I didn't get (understand) the mask comment.

    I would never guessed that you were a fan. Good to know. Thanks.
  87. Facelets fits JSF like a mask[ Go to top ]

    JSF is the most productive web app API that I have used. Facelets makes it a lot more productive.
    Isn't it a contradiction? If Facelets makes it a lot more productive then JSF can't be the most productive API :-)
  88. Facelets fits JSF like a mask[ Go to top ]

    JSF is the most productive web app API that I have used. Facelets makes it a lot more productive.
    Isn't it a contradiction? If Facelets makes it a lot more productive then JSF can't be the most productive API :-)

    No. Even the most productive API can be made more productive, as nothing - not even JSF - is perfect :)
  89. Facelets fits JSF like a mask[ Go to top ]

    Isn't it a contradiction? If Facelets makes it a lot more productive then JSF can't be the most productive API :-)
    No. Even the most productive API can be made more productive, as nothing - not even JSF - is perfect :)
    A very productive API can, the most productive API can't by definition. People tend to exaggerate.

    OT: I'm dissappointed by the fact that TSS still doesn't have the post preview functionality.
  90. Facelets fits JSF like a mask[ Go to top ]

    Isn't it a contradiction? If Facelets makes it a lot more productive then JSF can't be the most productive API :-)
    No. Even the most productive API can be made more productive, as nothing - not even JSF - is perfect :)
    A very productive API can, the most productive API can't by definition.
    So, if a racer is the fastest, he could not improve and become faster becuase then he wouldn't be the fastest? Me thinks something be lost in the translation.
  91. The fastest racer (or not?)[ Go to top ]

    So, if a racer is the fastest, he could not improve and become faster becuase then he wouldn't be the fastest? Me thinks something be lost in the translation.
    After the racer gets faster she is still the same racer. But when we add something to an API, we get other API. An API is sort of immutable object. And if the new API is more effective than the old then the old can't have been the most effective. Maybe I'm theorizing a bit.
  92. The fastest racer (or not?)[ Go to top ]

    Maybe I'm theorizing a bit.
    Just a wee bit. Or something.
  93. Facelets fits JSF like a mask[ Go to top ]

    Isn't it a contradiction? If Facelets makes it a lot more productive then JSF can't be the most productive API :-)
    No. Even the most productive API can be made more productive, as nothing - not even JSF - is perfect :)
    A very productive API can, the most productive API can't by definition. People tend to exaggerate.OT: I'm dissappointed by the fact that TSS still doesn't have the post preview functionality.

    If you read what I wrote, I said the most productive API that I used--this is a subjective statement for sure but not an exageration by any means. This is a personal opinion based on the web APIs that I have used. This statement is not much of an exageration as it relates a personal experience and opinion.
  94. Facelets fits JSF like a mask[ Go to top ]

    JSF is the most productive web app API that I have used. Facelets makes it a lot more productive.
    Isn't it a contradiction? If Facelets makes it a lot more productive then JSF can't be the most productive API :-)

    The statement was fairly subjective to begin with. Notice the use of I. It is an opinion. My opinion. JSF was the most productive web API that I ever used, and now with Facelets it is even more productive.

    A runner can be the fastest runner. Next year he can run again and run an even faster race. Being the "most" is transitive at best.

    Rome was the most powerful empire. It is not any longer.
  95. Facelets fits JSF like a mask[ Go to top ]

    JSF is the most productive web app API that I have used. Facelets makes it a lot more productive.
    Isn't it a contradiction? If Facelets makes it a lot more productive then JSF can't be the most productive API :-)

    No it is clearly not a contradiction. The fastest runner can always run even faster in another race.
  96. Facelets fits JSF like a mask[ Go to top ]

    Is it just me or does mixing Facelets and gloves seem wrong to you? How about "Facelets fits JSF like a mask"? Or "Facelets, like putting lipstick on a JSF"? "Facelets the facts, its JSF"?

    The correct understanding of what is going on here is to go back to the original requirements for JSF 1.0, which said (among other things) that it needed to be usable with or without JSP. Surprise, surprise, we actually delivered on that.

    Don't miss the most critical point -- the components themselves have *NO* knowledge of what view persistence technology you are using in a particular app. The same components that work in a JSP-based app for me can work in a Facelets-based or Clay-based app for you.


    Craig McClanahan
  97. build me a swing app with it[ Go to top ]

    No knowledge of the UI?

    Wasnt JSF supposed to be able to do fat client and web equally well when it was ahem..."introduced"?

    Show me a swing app and a web app using the same components.
  98. portlets? creator? oscache?[ Go to top ]

    Does anybody know if Facelets works seemlessly with portlets? How about IDE support from Netbeans or Creator? Creator has a great visual editor - it'd be fantastic if it could generate facelets markup.

    Finally, is it possible to reuse existing JSP libraries such as OSCache?

    /me heads over to join the mailing list
  99. portlets? creator? oscache?[ Go to top ]

    Does anybody know if Facelets works seemlessly with portlets? How about IDE support from Netbeans or Creator? Creator has a great visual editor - it'd be fantastic if it could generate facelets markup.Finally, is it possible to reuse existing JSP libraries such as OSCache?/me heads over to join the mailing list

    The issues is not Facelets. The issue is what Portlet JSF bridge are you going to use.

    Facelets should work anywhere JSF works. I had no issues getting Facelets to work in Portlets.
  100. portlets? creator? oscache?[ Go to top ]

    Does anybody know if Facelets works seemlessly with portlets? How about IDE support from Netbeans or Creator? Creator has a great visual editor - it'd be fantastic if it could generate facelets markup.Finally, is it possible to reuse existing JSP libraries such as OSCache?/me heads over to join the mailing list
    The issues is not Facelets. The issue is what Portlet JSF bridge are you going to use.Facelets should work anywhere JSF works. I had no issues getting Facelets to work in Portlets.

    I recant. Facelets should work anywhere MyFaces and JSF RI 1.2 work.
  101. Comments on my blog as well[ Go to top ]

    Please read the comments on my blog as well.

    http://jroller.com/page/RickHigh?entry=facelets_fits_jsf_like_a
  102. Facelets fits JSF like a glove[ Go to top ]

    In our company, we hav walked trough many aspect of java/web applications for 6 years:
    - Started with servlets
    - went to jsp
    - a "rapid" approach on struts
    - use of the first RI of JSF
    - and after all, adopt facelets

    When we've started to work on Struts, JSF was coming out, so we took the choice to go ahead, and jump over Struts.

    We succeed on a first project with jsf ri 1.0, and after that have developed many application on jsf myFaces.

    But, we found JSF very to capitalize and reuse, with lot of "core" java development, not fitting to a rapid application development paradigm, with high productivity level.

    Discovering facelets on last summer (at its born I think), I was convicted on its benefits.

    We gave us a few month to study it, waiting stabilization in the release, developing some tests applications.

    Documentation is light, but it's because Facelets are easy to understand...
    My fear was to see this project falling down, but with Jacob's great job and all the others "gurus" contributors, I feel secured.

    Now, since the beginning of the year, we use it as a base part of development tooling, in conjonction with hibernate 3, with no JSP.

    A fist production project is on the run, and my conclusions are clear :
    - Facelets provide less code effort.
    - Facelets give ability to capitalize and reuse.
    - Code architecture is more intuitive.
    - Many perspectives, tooling (Exadel and others), Rich Client (XulFaces)...


    I don't know if Facelets fits JSF like a glove, but it keeps my development team hands in a cold and comfortable place.
  103. I think Facelets is a great way to develop webapps ... just write your html code and your fancy js for your "cool" ui and test it.... and then just add your jsfc attributes. Developing your own component is easy too.

    But there is one thing i could not figure out: How do i use Ajax with Facelets? Could not find any examples on that. Especially important for me is partial rendering of components (like http://smirnov.org.ru/en/ajax-jsf.html).

    any suggestions?
  104. <snip>...How do i use Ajax with Facelets? Could not find any examples on that. Especially important for me is partial rendering of components (like http://smirnov.org.ru/en/ajax-jsf.html). any suggestions?

    There are several approaches to incorporating Ajax in JSF projects.

    For example, Sun Studio Creator 2 has a set of example JSF components that incorporate Ajax: http://developers.sun.com/prodtech/javatools/jscreator/reference/fi/2/ajax.html

    The ICEfaces JSF component suite uses another approach that provides many of the benefits of Ajax-enabled web applications without the need to develop in Javascript at all. Essentially, ICEfaces isolates the application developer from having to author the client-side content directly (HTML, CSS, JavaScript). Instead, applications are written using Java JSF components and supporting framework using either JSP or Facelets and standard industry IDEs. Client-side behaviors normally written in JavaScript can be configured, customized, etc. using the Java API provided by ICEfaces, exposed through the JSF components.

    Key benefits are:
        * Smooth, incremental page updates with in-place editing and no full page refresh.
        * Asynchronous page updates driven from the application in real time. (Server-push without polling)
        * Fine-grained user interaction during form entry that augments the standard submit/response loop.
        * No need to author complex JavaScript or test and tailor your content for multiple browser versions, etc.

    The current release is Alpha 0.3. The upcoming Beta release (late March) will add support for Facelets as well as additional rich components (Menu, AutoComplete, etc.), and "cinematic effects/animations" and Drag and Drop support.

    Online demos are available here: http://www.icesoft.com/products/demos_icefaces.html

    The complete ICEfaces Alpha release is also available for free download and distribution if you'd like to check it out: http://www.icesoft.com/downloadA.html

    IMHO the conflux of JSF, Ajax, and Facelets is the "perfect storm" for revolutionizing rich web application development in Java.

    ----

    Ken Fyten
    ICEfaces Product Manager
    ICEsoft Technologies
  105. I did not yet used facelets, but I have been using shale-clay and it's very helpful for my project. Specially composition component like below.
    <strong>In component definition XML</strong>
    <component jsfid="inputPanel" extends="panelGrid">
     <attributes>
       <set name="columns" value="2"/>
       <set name="styleClass" value="inputStyle" />
     </attributes>
     <element jsfid="ouputText">
      <attributes>
        <set name="value" value="@label"/>
      <attributes>
     </element>
     <element jsfid="inputText"
             id="username">
      <attributes>
        <set name="required" value="true"/>
        <set name="value" value="#{@inputValue}"/>
        <set name="validator" value="#{@inputValidate}"/>
      </attributes>
     </element>
    </component>
    <strong>In html file</strong>
     <span jsfid="inputPanel" label="User name: " inputValue="UserManager.userName" inputValidate="ManagedBean.validate"/>
    @ is symbol and you can redefine symbol's value in html or component definition. You may use html as tiles like template or use jsp instead of html.Shale is under development but I think clay is very useful inspite of some minor issue:
    Clay component cannot specify RendererType, so default renderer type is used. And html view show somewhat low performance compared to JSP. I like to know an advantage of facelets compared with clay.
  106. ...You may use html as tiles like template or use jsp instead of html.Shale is under development but I think clay is very useful inspite of some minor issue:Clay component cannot specify RendererType, so default renderer type is used. And html view show somewhat low performance compared to JSP. I like to know an advantage of facelets compared with clay.

    There are a few things:
    Facelets benchmarks faster than JSP for JSF use (~14% faster)
    Tag properties are auto-wired to Components/Validators/Converters, throwing out the majority need to write special Tags or XML configs.
    It's built on the new EL API and Expressions passed to UIComponents will actually report the attribute and line number they came from (here).

    I have my own opinions too on Clay's extra configuration with component/attribute/element. I prefer just explicitly fragmenting component (or composite) content and using straight EL for @XXX replacement instead.
    <ui:composition>
    &nbsp;&nbsp;<h:panelGrid columns="2" styleClass="inputStyle">
    &nbsp;&nbsp;&nbsp;&nbsp;<#{label}
    &nbsp;&nbsp;&nbsp;&nbsp;<h:inputText ... value="#{inputValue}">
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<ui:insert/>
    &nbsp;&nbsp;&nbsp;&nbsp;</h:inputText>
    &nbsp;&nbsp;</h:panelGrid>
    </ui:composition>

    Can be used like:
    <my:username label="me" value="#{me.name}">
    &nbsp;&nbsp;<my:validateRegex pattern="\w+"/>
    </my:username>

    (I hope all of the formatting comes through)
  107. JSFU[ Go to top ]

    Java server faces are disgusting.

    I still have not seen one problem they solve from a coding perspective, from a usability perspective or a standards perspective, I just dont get it.

    Its wannabe abstraction theory that noone needs, wants or will adopt.

    JSF is the JDO of Java UI Frameworks: Dead and deader.

    Leave it alone already unless you are willing to send me a link to a really hot app written in JSF. It doesnt exist and never will.

    Bye see ya later dont bother me with this crap again SUN.
  108. JSFU[ Go to top ]

    http://www.jsfcentral.com/articles/trenches_5.html

    http://www.jsfcentral.com/articles/trenches_2.html

    http://www.jsfcentral.com/ (itself)

    http://seam.demo.jboss.com/home.seam

    Plus, I remember hearing that the military is using it for some of their information delivery/portal stuff.

    Cheers
  109. hmmm...sample apps[ Go to top ]

    Yeah, even the samples look like crap.

    Try again.
  110. A real boon to your development[ Go to top ]

    Mr Hightower,

    Could you post a link to this "real boon to your development" that rocks the Java application space?

    Or is that just aa quote from the forward to some new book you plan to write?
  111. A real boon to your development[ Go to top ]

    Mr Hightower, Could you post a link to this "real boon to your development" that rocks the Java application space?Or is that just aa quote from the forward to some new book you plan to write?

    There are no plans for a book. My book writing days are over. It is a lot of work and most of it is fairly tedious. I want to start a OS project.

    There are some early stage planning for a white paper and a OS project. These will cover productivety improvements gain by using Facelets.

    I took this week off (mostly) to contemplate belly button lint. I am fairly burnt out. I should have some more concrete ideas about the white paper and OS project next week. We have several meetings to disucss these things next week.

    I have been working with JSF (moslty contract work) for customers for the past two years (almost). I find JSF more productive (for richer web apps) than Struts. I find Facelets a good way to get reuse at the UI tier.

    I'll have more to say at a later date (week to a month).

    Wicket seems interesting as does RIFE. I am fairly open minded.

    For now Facelets and JSF (not to mention Hibernate, Spring and AspectJ) has a firm grip on my interests.
  112. A real boon to your development[ Go to top ]

    Holy cow! OS as in Operating System or Open Source?
  113. A real boon to your development[ Go to top ]

    Holy cow! OS as in Operating System or Open Source?

    Open Source. OS seems to be a common abreviation these days and given the context, I was not expecting any confusion.

    But then again one can never guess the reading comprehension abilities of the audience.

    Thanks for the chance to clarify.

    :o)
  114. A real boon to your development[ Go to top ]

    Well, I figured you meant Open Source, but it is actually somewhat ambiguous and my first scan picked up Operating System.

    I wonder what a facelets OS would mean... it's funny how mistakes or ambiguities can occasionally lead to big ideas...
  115. TSS spoiler alert![ Go to top ]

    I have had conversations with folks who espouse unproven weak technology in industry rags. Emails and phone calls.

    And when I cut through the chaff of the new technology argument in the face of common sense if they are honest they say,

    "Well, I said it because I was paid to say it."

    So when you click on the headliners link I guess you have your answer as to whether its really been a "boon to his development" or not.

    Someone post me a link of one HOT PRODUCTION java web app using JSF. Ill file the lame sample JSF apps in the same bucket with the bank account example and the pet store.
  116. TSS spoiler alert![ Go to top ]

    I guess you have your answer as to whether its really been a "boon to his development" or not.Someone post me a link of one HOT PRODUCTION java web app using JSF.

    I can't give you a link, as it isn't up yet, but come back in a few months - I have a major JSF website in production right now.
  117. Blah blah blah![ Go to top ]

    I have had conversations with folks who espouse unproven weak technology in industry rags. Emails and phone calls.And when I cut through the chaff of the new technology argument in the face of common sense if they are honest they say,"Well, I said it because I was paid to say it."

    Blah blah blah! I am getting ripped off. Where is my money? I never got paid to say JSF was cool or Facelets or Spring or Hibernate.

    Everything is a conspiracy these days. It is one thing to be skeptical. It is quite another to live in a closet with alluminum foil on your head to block the evil gamma rays that the government is using to control your brain.

    Make a point why you feel JSF and/or Facelets sucks and then see how quickly Jacob and/or Steve (and/or Kito) rip it apart.

    I'd go with the conspiracy theory if I was you too. It is much safer to do that than opine about the technology where you will get shredded.

    So let me get this straight you don't like JSF and you don't like Faclets. So what do you like?

    I am sure there are not shortcommings or tradeoffs with it. eh?
  118. Blah blah blah![ Go to top ]

    Here's some more blah blah blah ;-)

    http://weblogs.java.net/blog/jhook/archive/2006/02/new_feature_for.html
  119. No Blah blah blah there![ Go to top ]

    Here's some more blah blah blah ;-)http://weblogs.java.net/blog/jhook/archive/2006/02/new_feature_for.html

    I read the link. It was useful information. It had technical meat not twinky conspiracy theories and conjecture.

    I am sure I'll reread a few times and try to digest it fully.
  120. Challenge accepted[ Go to top ]

    I have a knack for spotting failed technology. I just do. And your right it is easy to just say that and move on.
    But thats where common sense meets geek sense meets marketing blah. And you can say IBM isnt paying you to write about it. But I believe someone is which isnt to say that its bull. But I think your gushing over nothing is about as rational as my negative rant. Because "its better than struts" doesnt cut it.

    Theres lots of thing I dont have to write a whitepaper on to know that I should avoid. But if you insist on a think off I will shred your shredders, because I dont even have to blink twice to know junk when I see it.

    I will intentionally waste my time and discover the beauty of JSF and report back when Im over it, if you promise to stop espousing marketecture when I show you what a hoax it is.

    I have seen the JSF stuff and I think comparing JSF to struts is totally unfair. A good programmer can write struts in an hour. Its just a map of forwards. The taglibs are a convenience. The fact that you guys are still talking about struts as a baseline is kinda silly.
  121. Challenge accepted[ Go to top ]

    The fact that you guys are still talking about struts as a baseline is kinda silly.

    If you consider that the majority of new java web applications are still written in Struts, it's not so silly I think. I agree Struts and JSF are way apart when it comes to the implementation, but that's not something an end user typically cares about.
  122. Apps arent written in struts[ Go to top ]

    Just because we have agreed to use struts as a view controller for so long doesnt mean that apps are "written in" struts.
  123. Challenge accepted[ Go to top ]

    I have a knack for spotting failed technology
    Do you do palm readings too? Can you look at RoR's palm and see its future? Is it rosy? ;)
  124. Challenge was not accepted[ Go to top ]

    I have a knack for spotting failed technology. I just do. And your right it is easy to just say that and move on. But thats where common sense meets geek sense meets marketing blah. And you can say IBM isnt paying you to write about it. But I believe someone is which isnt to say that its bull. But I think your gushing over nothing is about as rational as my negative rant. Because "its better than struts" doesnt cut it.Theres lots of thing I dont have to write a whitepaper on to know that I should avoid. But if you insist on a think off I will shred your shredders, because I dont even have to blink twice to know junk when I see it.I will intentionally waste my time and discover the beauty of JSF and report back when Im over it, if you promise to stop espousing marketecture when I show you what a hoax it is.I have seen the JSF stuff and I think comparing JSF to struts is totally unfair. A good programmer can write struts in an hour. Its just a map of forwards. The taglibs are a convenience. The fact that you guys are still talking about struts as a baseline is kinda silly.

    How is the challege accepted? This is the same blah blah blah.

    I think I can sum up your thoughts in one sentence: "I am smart. You are dumb. JSF sucks.".

    Did I get it?
    Is there more?

    But what framework or method do you espouse?

    What do you claim is better and why?
  125. Challenge was not accepted[ Go to top ]

    I have a knack for spotting failed technology. I just do. And your right it is easy to just say that and move on. But thats where common sense meets geek sense meets marketing blah. And you can say IBM isnt paying you to write about it. But I believe someone is which isnt to say that its bull. But I think your gushing over nothing is about as rational as my negative rant. Because "its better than struts" doesnt cut it.Theres lots of thing I dont have to write a whitepaper on to know that I should avoid. But if you insist on a think off I will shred your shredders, because I dont even have to blink twice to know junk when I see it.I will intentionally waste my time and discover the beauty of JSF and report back when Im over it, if you promise to stop espousing marketecture when I show you what a hoax it is.I have seen the JSF stuff and I think comparing JSF to struts is totally unfair. A good programmer can write struts in an hour. Its just a map of forwards. The taglibs are a convenience. The fact that you guys are still talking about struts as a baseline is kinda silly.
    How is the challege accepted? This is the same blah blah blah. I think I can sum up your thoughts in one sentence: "I am smart. You are dumb. JSF sucks.".Did I get it?Is there more?But what framework or method do you espouse?What do you claim is better and why?

    And by one sentence... I meant three short sentences.
    DOH!
  126. Jacob,
    I'm trying to standardize my project build management and I would really appreciate if you could you put facelet in the maven 2 repository on ibiblio ? (i tried myself, but i don't know the versions of the dependencies)...
  127. Jacob, I'm trying to standardize my project build management and I would really appreciate if you could you put facelet in the maven 2 repository on ibiblio ? (i tried myself, but i don't know the versions of the dependencies)...
    Big +1 for my corporation!
  128. Jacob, I'm trying to standardize my project build management and I would really appreciate if you could you put facelet in the maven 2 repository on ibiblio ? (i tried myself, but i don't know the versions of the dependencies)...
    Big +1 for my corporation!

    +1 for me too.
  129. Trying to combine JSF and JSP is like trying to shoehorn a foot into a glove: it's possible, but not pleasant. This article introduces developers to Facelets' easy HTML-style templating and reusable composition components that fits JSF like a glove.While working on a JavaServer Faces (JSF) project recently, I had the pleasure of using Facelets for the first time. What I most liked about Facelets was that it let me create reusable composition components. Being able to take a page (like a JSP) and turn it into a component has been a real boon to my JSF development ever since. My conclusion? If you're not using Facelets, you're not getting the most you can out of JSF.The mismatch between JSF and JavaServer Pages technology is a serious problem in JSF development. The issue is how to integrate JSP's dynamic content into JSF's component-based model. JSP is singularly focused on generating dynamic output, whereas JSF requires JSP to coordinate building a component model. The disjunct occurs because that task is beyond the original intention of JSP.Most JSF developers simply learn to navigate such problems on an ad-hoc basis, but that's kind of like duct-taping a pillow to a hammer so it won't hurt coming down on your head. Facelets is a much more comprehensive solution: a templating language that is geared toward the JSF component model.Facelets fits JSF like a glove.Have you tried Facelets?Have you compared the Facelets approach to other technologies like Tapestry?

    Thanks for the feedback on the Facelets article.
    There will be another article on Facelets due to the interest.

    Thanks again....


    Rick Hightower (linked in)
    JSF, Spring, and Hibernate training and consulting