Discussions

News: Tech Talk: Craig McClanahan on JavaServer Faces

  1. Craig McClanahan, project lead for Sun's Java Studio Creator and original author of Struts, discusses JavaServer Faces and where it stands in the web framework landscape, as well as its relationship to Struts and some other frameworks. Along the way, he also mentions some of the capabilities in the expression language to be extensible.

    View Tech Talk

    Threaded Messages (54)

  2. Craig McClanahan: "I was the co-specification lead for JavaServer Faces 1.0, which was recently finalized. [...]"

    So, how old is that tech-talk?

    I am not quite sure but i think JSF 1.0 was released in march 2004 so i really can't figure out why you don't add date information to the post.
  3. Craig McClanahan: "I was the co-specification lead for JavaServer Faces 1.0, which was recently finalized. [...]"So, how old is that tech-talk?I am not quite sure but i think JSF 1.0 was released in march 2004 so i really can't figure out why you don't add date information to the post.

    +1

    Kindly add DATE information
  4. "I was the co-specification lead for JavaServer Faces 1.0, which was recently finalized. [...]"
    So, how old is that tech-talk?I am not quite sure but i think JSF 1.0 was released in march 2004 so i really can't figure out why you don't add date information to the post.

    Sorry ... this one was my botch during the interview ... in the context of the other questions I was answering in the context of JavaServer Faces being relatively recently standardized, but "recently" is definitely relative :-). Anyone who has ever been interviewed in an environment like this will appreciate that the Q&A on tape doesn't always match what you would say if you were totally preparing the presentation ahead of time, like you do for a conference session.

    FWIW, this interview was conducted at TSSJS in March 2005. Much better turnaround than my last TSS interview, which took over a year before it was published :-).

    Craig
  5. Questions[ Go to top ]

    Very interesting interview. Is it possible if we knew about such interviews in advance and we will be able submit our own questions. Than TSS should ask on our behalf.

    TNX
  6. JSF's focus is to be a view tier technology. It's not in it's 1.0 format designed to take over the whole web application space.

    I'm using JSF as a full MVC technology. It is not a perfect fit to this, but it isn't bad, and, I would suggest, it is good enough for this in a large number of cases, and I am having trouble pinning down exactly what JSF is supposed to be missing in the area of MVC. I would be very interested in a detailed comparative review of web technologies to explain what features such a technology is expected to have.

    I do find this matter of 'focus' mildly annoying. I am after something simple in a single product to develop web applications. I don't want to have to kludge together different products with different areas of 'focus' to get what I am supposed to need. I have recently started to make use of JSF-Spring, and that took some major research and hunting through Javadocs and blogs in order to get it working. If I have to combine yet another product to add supposedly missing features from JSF due to it's 'focus', I'll end up with a real headache. It feels to me like building a fragile system, with too many servlets, listeners, and application parameters all having to be set up in a precise order. Development should be simpler.

    I am hoping that Shale will, at some time in the future, provide what I need... perhaps with no such 'focus'!
  7. This is the problem that I spoke about with you on another thread a few months back Steve.
    I suspended researching JSF out of frustration.

    The JSF community is really doing a horrible job of selling JSF. I'm going to wait a while longer and hope that they can sort out what exactly it is they doing so I can take this technology seriously.

    People such as Rick Hightower are writing articles explaining how JSF is a replacement for Struts while Hans Bergsten writes in his book "JavaServer Faces" that JSF and Struts are not the same thing with different objectives (JSF is a "user interface framework" and Struts is an "application framework") and can be used together.

    It seems to me that much of the misinformation surrounding JSF is being spread by JSF advocates because they can't build a consensus on what JSF is.
  8. I agree that with the strong presence and success of Struts, it's hard to decide where to invest one's time and money. Craig breaks it down to two categories: those that already have implemented Struts and those building new applications.

    If your app is already built in Struts, then you don't want to throw away that investment, so Craig advocates (and rightly so) that you should keep using your Struts backend plumbing (Actions, ActionForms) and just use JSF for the pure visual components. That is, use the JSF standard tags and third party JSF components that are coming out in the market. In addition, you'll need to plan to use the Struts / JSF integration package to glue them together. This is a win-win since you get all the benefits of the JSF UI components without having to rewrite all your existing Action and ActionForms (and can continue to write more Action and ActionForms).

    The decision is much easier for new applications. Craig advocates that you evaluate Struts, JSF, and any other web tier solution on each's merits. If the confusion is how to evaluate the merits of Struts vs. JSF, I think one factor that should influence the decision strongly is the standardization aspect of JSF. JSF being the standard sets the stage for a robust UI component market to evolve, which has already started to occur.

    As an author of a third-party custom tag library, let me offer up one perspective of JSF vs. Struts. We get alot of customers that want our visual widgets to "integrate with Struts". We've attempted to do that, but have tried very carefully not to couple our product too tightly to Struts (or any other MVC framework). For example, we don't want to inherit from any Struts class, since that level of coupling would create fragility (think versioning, release schedules, etc.) So a simpler approach it to provide some standalone helper classes that allow indirect integration to occur. The problem with this approach is that you begin to burden the developer with having to learn a new set of proprietary APIs, which doesn't help their situation much. A developer isn't interested in trying how to learn how to glue it together as they've got better things to do, like write code.

    With JSF, the decoupling of responsibilities is more formally separated from the core framework. That is, we'll be able to deliver visual UI widgets, as well as custom validators, converters, renderers, etc. that could snap into your application without the developer having to learn a proprietary API of ours. It's also possible to use a third-party validator with your own hand-written UIComponent. We're excited about the potential for JSF, as I believe many third-party component authors are.

    Joe Pardi
    http://www.dotjonline.com
  9. The JSF community is really doing a horrible job of selling JSF.
     

    I think that is mere reflection of confusing nature of JSF.
  10. While I agree that JSF is confusing, it doesn't have to be.
    Maybe they should figure out what the hell it is that they have created and then they'll be able to explain it in a concise fashion.

    I also don't really like this whole, "well you have to evaluate your needs and then decide if you should be using JSF or Struts or JSF and Struts, etc.". Either it fulfills the needs of enterprise computing or it doesn't.
    If it only covers certain aspects, then say so. Don't make me go do work to figure out what it is that you've done.

    Sell it for what it is, not what it might or might not be.
  11. I also don't really like this whole, "well you have to evaluate your needs and then decide if you should be using JSF or Struts or JSF and Struts, etc.". Either it fulfills the needs of enterprise computing or it doesn't.If it only covers certain aspects, then say so. Don't make me go do work to figure out what it is that you've done.Sell it for what it is, not what it might or might not be.

    Very well said.

    Personally, I like JSF a lot and I'm sure it will be highly successful, but this vagueness from people who are supposed to be promoting the technology is not helping. They do need to 'sell' it more accurately and positively.
  12. I don't think anyone needs to "sell" JSF. It will live or die on its own.

    I think all we (those who believe it has a very good chance of thriving) can really do is help educate what you can with JavaServer Faces and let it sell itself.

    -Chris

    http://jroller.com/page/cschalk
  13. I believe that JSF's main benefit *on its own* is its view technology, and I think the decision to keep it focused that way was smart. Having a one-stop-shop for building your app is nice, but it's a pipe dream to imagine that a committee could design a superior top-to-bottom app framework all at once. In addition to that, there may *never* be a single accepted app framework. While this will be disappointing to some, I think the reality is that there will be a few solidly-integrated combinations to choose from. It *won't* be left to the developer to fight through a sea of alternatives and string together the best ones, with little or no documentation (which is where we've been recently to some extent).

    I think that when the dust settles, Shale will be in one of those combinations, as will Beehive Page Flow (http://incubator.apache.org/beehive). Both frameworks provide a rich controller/flow tier that integrates nicely with JSF. Shale builds on JSF functionality that goes beyond the View (this is where JSF is useful as more than just view technology), while Page Flow remains standalone and can plug in JSF as the view tier.

    (As an aside, one thing that will help JSF get integrated with *any* successful controller framework is the fact that it is consummately pluggable. I haven't found a single behavior that can't be overridden or extended. The pluggability doesn't help the end user directly, but it will definitely help JSF.)
  14. This is the problem that I spoke about with you on another thread a few months back Steve.
    I suspended researching JSF out of frustration.

    I can't remember what I posted. I hope I did not disagree with you too strongly.
    People such as Rick Hightower are writing articles explaining how JSF is a replacement for Struts while Hans Bergsten writes in his book "JavaServer Faces" that JSF and Struts are not the same thing with different objectives (JSF is a "user interface framework" and Struts is an "application framework") and can be used together.

    My experience is that they are both right. JSF is a great and simple system for developing full web applications. It is not just a user interface framework, and it does not require any kind of GUI designer tool. However, it can certainly be used with other frameworks.
    It seems to me that much of the misinformation surrounding JSF is being spread by JSF advocates because they can't build a consensus on what JSF is.

    Absolutely. And this is why this 'focus' issue described in this article is so irritating.
  15. Actually Steve you were the only person on that thread who took the time to constructively respond to my comments and alleviate some of my misunderstand and frustration.

    His JSFness himself Mr. McClanahan responded in what I took to be a really uppity fashion. Mr. Hightower's response was childish at best.
  16. People such as Rick Hightower are writing articles explaining how JSF is a replacement for Struts while Hans Bergsten writes in his book "JavaServer Faces" that JSF and Struts are not the same thing...

    It just reflects how the vision changes during the year. Hans wrote the book more than 1 year ago. Rick writes his article now.
    Did you really expected that somebody (the Author, for example) said the Struts was over, we had a replacment for it already. The community should be prepared smoothly, without revolutions. It was very interesting to observe how the view is changed during the year.
    1. The Struts and JSF are not competitive thecnologies. Do not worry.
    2. Taste the JSF. You can use together with Struts using the integration library
    3. You are able to replace Struts in your existing application step by step
    4. JSF reinvested Struts already. We have to have new Struts which works as an extention for JSF. "Shale : next Struts?"

    --
    Sergey : jsfTutorials.net
  17. People such as Rick Hightower are writing articles explaining how JSF ...
    TSS had discussion about his article that IMO was not very good show case of JSF and was full of misstatements about other frameworks:
    http://www.theserverside.com/news/thread.tss?thread_id=31626
  18. I agree.
    His article did the opposite of what the title indicated it was suppose to do.
  19. It feels to me like building a fragile system, with too many servlets, listeners, and application parameters all having to be set up in a precise order. Development should be simpler.

    Ahhh. The joy of browser UI development. :)
  20. If your application is focussed on compelling visual
    >displays or you need complex components like a tree
    >control or a table that has input fields or something
    >that does back-end communication behind the scenes like a
    >progress meter, then you're likely to want to see
    >JavaServer Faces as your framework.

    Strange. All this could be done in Struts even more easily than in JSF. What is a problem to display tree or edit cell in the grid? There should be something else. E.g. support from Vendors/IDE's for JSF, technology mainstream etc.

    Marina
    http://www.servletsuite.com
  21. >If your application is focussed on compelling visual >displays or you need complex components like a tree >control or a table that has input fields or something >that does back-end communication behind the scenes like a >progress meter, then you're likely to want to see >JavaServer Faces as your framework.Strange. All this could be done in Struts even more easily than in JSF. What is a problem to display tree or edit cell in the grid? There should be something else. E.g. support from Vendors/IDE's for JSF, technology mainstream etc.Marinahttp://www.servletsuite.com

    One of the key things that makes JSF unique is the ability to use thrid party components to build your UI. So yes you could have wrote the HTML+Javascript to implement a tree component for example on your own - and then spend the time making sure it works on all the browsers out there etc.

    JSF offers an easier solution of this - just pick a component that someone else wrote and you have the functionality out of the box.

    Here is a list of the components offered by Oracle's ADF Faces right now: http://www.oracle.com/technology/products/jdev/htdocs/partners/addins/exchange/jsf/doc/tagdoc/core/imageIndex.html
    How long would it take you to build all these components for your application.
  22. One of the key things that makes JSF unique is the ability
    >to use thrid party components to build your UI. So yes you
    >could have wrote the HTML+Javascript to implement a tree
    >component for example on your own - and then spend the
    >time making sure it works on all the browsers out there
    >etc.

    Again: JSF is good, but sales arguments are wrong.
    You can write tree with tag files, custom tags etc. It could be (and it is) cross browser too. You do not need JSF for that. Is not it?


    >Here is a list of the components offered by Oracle's ADF
    >Faces right now:
    >http://www.oracle.com/technology/products/jdev/htdocs/partn
    >ers/addins/exchange/jsf/doc/tagdoc/core/imageIndex.html
    >How long would it take you to build all these components >for your application.

    there is a much more: http://www.servletsuite.com/jsp.htm
    and so what?

    It is not against JSF, I am just looking the proper arguments.
  23. Again: JSF is good, but sales arguments are wrong.You can write tree with tag files, custom tags etc. It could be (and it is) cross browser too. You do not need JSF for that. Is not it?

    JSF is a standard component platform that at first glance, seems a lot like JSP tags. But the problem with JSP tags is that they strictly exist in the view. With JSF, your complete tree of tags is available for manipulation within your actions in the full lifecycle of MVC.

    Now, sales argument-- I split JSF into two parts-- the Components and the Handlers. The component platform is the big selling point. The idea that you can download a component (much like a JSP tag) that can do much more in conjunction with your application other than participate in rendering the view. The second part, the handlers, are all interchangable, extendable, and wrappable. This is where the flexability comes into play for your development group-- you can choose Shale with Hivemind or Spring MVC with EJB3 beans, etc. The component part is agnostic to your handler implementations so it's much like customizing your own JSP container with security filters, exception handling, state management, etc.

    -- Jacob (JSR 252 EG)
  24. The value of components[ Go to top ]

    One of the key things that makes JSF unique is the ability to use thrid party components to build your UI. So yes you could have wrote the HTML+Javascript to implement a tree component for example on your own - and then spend the time making sure it works on all the browsers out there etc.JSF offers an easier solution of this - just pick a component that someone else wrote and you have the functionality out of the box.Here is a list of the components offered by Oracle's ADF Faces right now: http://www.oracle.com/technology/products/jdev/htdocs/partners/addins/exchange/jsf/doc/tagdoc/core/imageIndex.htmlHow long would it take you to build all these components for your application.

    I think the component framework aspect of JSF is often overlooked, even though it's the most compelling aspect. As someone who has done a decent amount of Delphi development, I think components have the potential to radically simplify the way we develop applications. And the fact that JSF opens the doors for Java web-based components is its key benefit. (It has lots of other key features, too, but that's not the point.)

    I think after JavaOne, it might be more clear just how many component vendors are going to join the fray. It's quite an exciting time for Java web development.

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

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

    And the fact that JSF opens the doors for Java web-based components is its key benefit.
    Please! The door is open for many years: have you heard of Tapestry or WebObject?

    By the way creating components in Tapestry is MUCH easier than in JSF.
  26. The value of components[ Go to top ]

    And the fact that JSF opens the doors for Java web-based components is its key benefit.
    Please! The door is open for many years: have you heard of Tapestry or WebObject?
    Obviously he means tool support.
    Tapestry components are not considered *real* components by unwashed JSP masses, because you cannot drag and drop them on WYSYWYG editor and with mouseclick open properties dialog and change its properties.

    That's what JSF brings to java.
    By the way creating components in Tapestry is MUCH easier than in JSF.
    It does not matter because creating components is not for average user. Using components is. That's why wide vendor tool support will make JSF mainstream? and leave things like Tapestry in niche.

    Well all this web frameworks feast of course untill ClickOnce comes and kills everyone :)
    But that's completely different story.
  27. The value of components[ Go to top ]

    It does not matter because creating components is not for average user.

    I am sorry, this is simply untrue. This is like saying that creating objects in Java is not for the average user.

    There is a significant value in components, expecially in a commercial environment.

    The average user does not create web components at the moment both because there were no components in frameworks like JSP and because doing that in frameworks like JSF is rather hard without expensive tools.
  28. The value of components[ Go to top ]

    Like it or not, the fact that JSF sets a standard for components means that it becomes commercially interesting to start writing for it. If there is money to be made then a market will appear. No serious vendor is going to invest resources in writing component sets for something like Tapestry because it is relatively niche (in the big picture) when they could invest the same effort writing to a standard that they know is going to have longevity and be supported in the various design time IDE environments.
  29. The value of components[ Go to top ]

    Like it or not, the fact that JSF sets a standard for components means that it becomes commercially interesting to start writing for it. If there is money to be made then a market will appear. No serious vendor is going to invest resources in writing component sets for something like Tapestry because it is relatively niche (in the big picture) when they could invest the same effort writing to a standard that they know is going to have longevity and be supported in the various design time IDE environments.
    Agreed.
    And it means software vendors again push technology on consumers (IT departments and consulters) without much need for it.
    I think so because server side component model that could be rendered to anything is utopia.
  30. I think so because server side component model that could be rendered to anything is utopia.

    At the latest NL JUG conference Duncan Mills of Oracle had shown quite impressive JSF demo: the same interface was running in browser, in PDA emulator, at VT100 screen and sort of chat client.

    It is not that I can believe him that everyone could start doing things like this tomorrow. Or that it really makes sense to 100% reuse same screen flows and components just rendering them to different clients. But I can think of applications that could make use of it.

    Seriously, it seems more like philosophical question: to improve technology, should we
    A) make it more usable (think of annotations, EJB3 and Hibernate XML mapping), or
    B) just make GUI tools with wizards to hide its ugliness and to appeal to unwashed masses (think of WSAD)?

    While I'm one for the first approach, the second makes me think of "mascon chemistry" in "Futurologist's Congress" novel by Stanislaw Lem. It definitely worth quoting but I couldn't find English text. So forgive me my "wooden" English. I hope it still conveys the basic idea though.
    "...under the influence of psychochemicals in excessive doses the body fails. Hair is lost or the tail disappears suddenly...
    - Do you mean - the tail _grows_ suddenly?
    - No, I really do mean "disappears". Last thirty years everyone's got a tail. This is a side effect of teaching literacy by an injection of Orphographine. Such efficient instant training comes not for free indeed.
    - It just can't be so - I've been on a beach and I've seen no one with a tail!
    - Well, you talk just like a child, really. The tails are masked by Anti-Tailine, which turns nails black and causes bad breath.
    - And these side effects are also masked?
    - Sure!
    ..."
  31. The value of components[ Go to top ]

    I think so because server side component model that could be rendered to anything is utopia.

    Yes, but isn't it nice to have the possibility of at least rendering to some alternative presentation methods? The MyFaces JSF implementation already comes with both HTML and WML. I have heard of interesting JSF work with SVG and even Flash.

    I think the ability to render to alternative presentation technologies is a major strength of JSF, and will become very important as users of come to expect richer functionality client-side.
  32. The value of components[ Go to top ]

    I think the ability to render to alternative presentation technologies is a major strength of JSF, and will become very important as users of come to expect richer functionality client-side.

    I am very sceptical about it. Sure it works fine for 'hello world' type of screens, but as complexity of UI and event dependency grows, it usually becomes a nightmare to support varous target dependent renderers. Hell, it is still difficult to render advanced HTML+CSS correctly in supposedly spec compliant browsers (IE, Moz, Opera,etc).
  33. The value of components[ Go to top ]

    I think the ability to render to alternative presentation technologies is a major strength of JSF, and will become very important as users of come to expect richer functionality client-side.
    I am very sceptical about it. Sure it works fine for 'hello world' type of screens, but as complexity of UI and event dependency grows, it usually becomes a nightmare to support varous target dependent renderers. Hell, it is still difficult to render advanced HTML+CSS correctly in supposedly spec compliant browsers (IE, Moz, Opera,etc).

    This is true, but if JSF cuts out even part of the effort, isn't that a good thing? Surely it is better to have a framework that allows this in principle...
  34. The value of components[ Go to top ]

    You may end up not being able reuse the same UI between different presentations, but at least you can reuse the "knowledge" (same API's, probably same tools). You'd have to learn just the specific UI's widgets, the rest would be the same (validation, navigation, domain model, IOC, etc.)
  35. Strange. All this could be done in Struts even more easily than in JSF.

    Sorry, I am really disagree with this statment. I remember about couple years ago, I wrote an instruction how to add common validators to the simple Struts application to check that one field is required. This instruction contained 14 (fourteen !) required steps to accomplish. It was very hard to explain how useful this feature was if it requires 14 steps to memorize.
    It requires only two steps in JSF to have the same thing. This is only one example.

    --
    Sergey : jsfTutorials.net
  36. Strange. All this could be done in Struts even more easily than in JSF.
    Sorry, I am really disagree with this statment. I remember about couple years ago, I wrote an instruction how to add common validators to the simple Struts application to check that one field is required. This instruction contained 14 (fourteen !) required steps to accomplish. It was very hard to explain how useful this feature was if it requires 14 steps to memorize.It requires only two steps in JSF to have the same thing. This is only one example. --Sergey : jsfTutorials.net

    Last time I was in a Struts project, we had to rely on a DHTML guru for the UI who finally hijacked the project to a javascript show.

    Now with ASP.NET, I can build the UI myself. Reusable Web UI components should be a good thing in the Java world too.
  37. Interview Date[ Go to top ]

    Please post the interview date on these Tech Talks. It's kind of amateurish that the interviewee usually has to come on to the thread and try to recall when the Q&A was conducted to provide context.
  38. O'Reilly OSCON 2005[ Go to top ]

    Craig McClanahan is scheduled to give a presentation about JSF and Shale at the O'Reilly OSCON in August.

    http://conferences.oreillynet.com/cs/os2005/view/e_sess/6478

    <quote>
    The Evolution of Web Application Architectures
    Craig McClanahan, Architect, Sun Java Studio Creator, Sun Microsystems, Inc,.

    Track: Java
    Date: Wednesday, August 3rd, 2005
    Time: 1:45pm - 2:30pm
    Location: Portland 254

    The last five years have seen tremendous evolution and an explosion of new options for architecting a web application based on Java technologies. This session briefly reviews the key architectural features of several existing frameworks, examines the impact of a new standardized API (JavaServer Faces) in this space, and glances at some potential future directions, including Beehive (at Apace) and Shale (recently accepted as a subproject of Apache Struts).
    </quote>


    Also, Howard Lewis-Ship will be giving a presentation about Tapestry.

    <quote>
    Tapestry In Action
    Howard Lewis Ship, Independent Software Consultant

    Track: Java
    Date: Wednesday, August 3rd, 2005
    Time: 5:20pm - 6:05pm
    Location: Portland 254

    The Jakarta Tapestry web application framework is a comprehensive, component-based approach to building web applications: Java applications that truly execute on the Web. Tapestry allows you to develop a web application without thinking in terms of HTTP or the Java Servlet API. Instead, you stay focused on objects, methods, and properties specific to your application, and the framework provides the low-level plumbing to fit everything together. Building web applications with Tapestry is addictive...and fun!

    In this session, we'll assemble several simple web applications, starting with basic HTML files and adding Tapestry instrumentations. Along the way, we'll see a glimpse into how Tapestry improves the whole cycle of web application developer, with a focus on developer productivity. In Tapestry, less is more--less Java code results in more productivity and greater robustness.
    </quote>
  39. O'Reilly OSCON 2005[ Go to top ]

    Craig McClanahan is scheduled to give a presentation about JSF and Shale at the O'Reilly OSCON in August.

    While I'm definitely looking forward to this one (it's in my home town, and from an angle I don't get to address very often in my day job), there's also another opportunity for "inquiring minds" to learn about Shale. At JavaOne, David Geary and I will be presenting a session entitled "Shale: The Next Struts?" (TS-7397) that introduces the features, and we'll have time to address some of the strategic questions as well.

    Craig
  40. shale vs spring webflow[ Go to top ]

    Hi Craig,

    This recent thread on TSS suggested to me that your plans for tailoring Shale to JSF were voted off and that you turned to Spring Webflow.
    Now I get the impression that the Shale - JSF link is still going to happen.
    Since I will be making a choice for a large JSF project what we're going to do re controllers I want to get a feeling what the de facto standard will be with respect to controllers in conjunction with JSF.
    Can you elaborate on this please?

    groeten,
    Joost
  41. shale vs spring webflow[ Go to top ]

    Hi Craig,This recent thread on TSS suggested to me that your plans for tailoring Shale to JSF were voted off and that you turned to Spring Webflow. Now I get the impression that the Shale - JSF link is still going to happen.Since I will be making a choice for a large JSF project what we're going to do re controllers I want to get a feeling what the de facto standard will be with respect to controllers in conjunction with JSF. Can you elaborate on this please?groeten,Joost

    The thread you referenced discussed a proposal I made to the Spring developers about how to link Spring WebFlow with pure JavaServer Faces, as well as volunteering to work on an implementation. I still intend to follow through on the latter part (although pre-JavaOne was probably not a very smart time for me to offer significant hours, given my day job :-).

    In the mean time, Shale already incorporates a very simple version of what Spring web flow supports called "dialogs" (in addition to its existing support for view controllers. Once the "Spring + pure JSF" integration is done, a "Shale + Spring" user will have a choice of a simple or a complete flow implementation, but a Shale-only user will still have a flow solution available. The "use cases" sample app uses this technology to manage a login process like what you see on portals, with "create a new profile" and "remember me" capabilities.

    Nightly builds of Shale, and the sample app, are available at http://cvs.apache.org/builds/struts/nightly/struts-shale/
    and its subdirectories.

    Craig
  42. shale vs spring webflow[ Go to top ]

    Thanks for clearing that up.
  43. Will the JSF become a case that we must make all the open source stuff and cool thing become JCP Standard?

    We know JCP is a birocratic things. And Open Source is the most creative and open thing.

    I am agree with the standard, so we cannot depend on one vendor. which i am glad apache harmony started.

    I just still confuse, how the JCP team can become part of the community and still get update and of course update his spec from the most creative and valuable things from the community.

    the community can be vendor propietary or open sourcer.

    I just think WebWork is a cool job, i am use it intensively, but I see that JSF is compared with Struts also.

    can WebWork team become JSF team, and how about the creativity in WebWork happen after JSF?

    Frans
  44. Is podcast version available[ Go to top ]

    Is podcast version of the talk available? I really like to be able to listen to it during my drive.

    Thanks!

    Chao
  45. IMHO, It is very wrong to state that JSF is superior to Struts and any new project should consider JSF over Struts.

    Let's look at the UI layer:

    JSF supports components-oriented UI building. That is a paradigm championed and popularized by Visual Basic in desktop applications. Granted that a lot of web-based applications (Online Banking, eCommerce, Corporate Systems) do want to look and act like a desktop application - that is a good thing, improves productivity and brings standard look-and-feel to the UI.

    But hold it there - that's exactly what desktop applications aim on (most, at least) - standard look-and-feel. Alas, it is not such a strong statement for web. On the web, there is a large portion of portal systems that do not want standard look-and-feel. A web-site is a brand for lots of companies and they want original design.

    What this means is - if you are in the business of being a Portal Toolkit vendor, than JSF is not for you - whether you have invested in Struts or are just starting. Components-based concept is not well-suited there. What is the most important in that area is - HTML-friendly templating that non-programmers can use easily to brand the system.

    Now, there is a components-oriented framework - Tapestry - that has easy templating, but JSF does not. JSF's core templates are JSPs and ask any graphic designer if they think JSP is easy to use. There is no doubt that the answer will be - no.

    So for that niche (and it is not a small one) - developers are much better off using Struts + Velocity, for example.
  46. IMHO, It is very wrong to state that JSF is superior to Struts and any new project should consider JSF over Struts.

    A very strong statement, considering how rich and complex both approaches are.
    Let's look at the UI layer:JSF supports components-oriented UI building. That is a paradigm championed and popularized by Visual Basic in desktop applications.

    Yes, but JSF also supports event-driven UI handling - the idea that a web page is composed of objects which send method calls to a controller. This is a paradigm championed by powerful GUI systems way before Visual Basic.
    Granted that a lot of web-based applications (Online Banking, eCommerce, Corporate Systems) do want to look and act like a desktop application - that is a good thing, improves productivity and brings standard look-and-feel to the UI.But hold it there - that's exactly what desktop applications aim on (most, at least) - standard look-and-feel. Alas, it is not such a strong statement for web. On the web, there is a large portion of portal systems that do not want standard look-and-feel. A web-site is a brand for lots of companies and they want original design.What this means is - if you are in the business of being a Portal Toolkit vendor, than JSF is not for you - whether you have invested in Struts or are just starting. Components-based concept is not well-suited there.

    I think this is a totally confused statement about what JSF is about. It is nothing at all to do with standard look-and-feel or desktop applications. All JSF components have style attributes which allow the full richness of CSS to be used, and to be customised and changed at any time. This makes JSF eminently suitable to systems such as Portal Toolkits. In fact, JSF has an advantage in that the Toolkits may allow additional or customised JSF components to be easily added by the user.
    What is the most important in that area is - HTML-friendly templating that non-programmers can use easily to brand the system.Now, there is a components-oriented framework - Tapestry - that has easy templating, but JSF does not. JSF's core templates are JSPs and ask any graphic designer if they think JSP is easy to use. There is no doubt that the answer will be - no.So for that niche (and it is not a small one) - developers are much better off using Struts + Velocity, for example.

    I think this is vastly condescending to graphic designers. JSF JSPs are just tags, and that is all. I can see there might be an issue of graphic designers where expected to use rich JSP EL or something complex like that, but that is not the way JSF is used. The JSF tags for forms and controls are pretty much as simple as the HTML tags.

    Given a decent JSF GUI designer the graphic designer can have full control of appearance, styles, everything.... or if the don't have a JSF designer, let them use HTML form tags, and convert the tags with some XSLT...
  47. All JSF components have style attributes which allow the full richness of CSS to be used, and to be customised and changed at any time. This makes JSF eminently suitable to systems such as Portal Toolkits.
    Steve, yes but there is only that much one can do with CSS. I am not an expert but in my experience - the power of CSS customizations, while significant, is vastly overestimated. I have tried the the CSS-oriented design suggested by some experts but the nice myth they present in books did not turn out as nicely in practice. Maybe it's just me but, with the risk of being called arrogant, I do not see why an average "templator" would be more capable than me.

    Steve, since you apparently know much more than me about JSF, could you, please, answer the following question? How possible/easy is substituting JSP with Velocity templates in JSF, in reality? Craig's answer on this seemed like a speculation, to me.

    Does it look like JSF will have a full-fledged, out-of-the-box support for alternative templating engines like Velocity? I am not a big fan of JSP, whether used in JSF, Struts or wherever and prefer Velocity. This preference comes simply from the feedback from designers - people who are _meant_ to be working on templates, would rather work with Velocity than JSPs.

    thanks.

    P.S. When I say "full support" I mean a situation when equivalent Velocity macros are available for usage for main JSP tags of JSF. It should be equivalent at the level that JSP and VMs can be used interchangably without a problem. When somebody suggest me to write a controller/renderrer or something like that - I see that as a possible point of extension - not support.
  48. Does it look like JSF will have a full-fledged, out-of-the-box support for alternative templating engines like Velocity? I am not a big fan of JSP, whether used in JSF, Struts or wherever and prefer Velocity. This preference comes simply from the feedback from designers - people who are _meant_ to be working on templates, would rather work with Velocity than JSPs.thanks. P.S. When I say "full support" I mean a situation when equivalent Velocity macros are available for usage for main JSP tags of JSF. It should be equivalent at the level that JSP and VMs can be used interchangably without a problem. When somebody suggest me to write a controller/renderrer or something like that - I see that as a possible point of extension - not support.

    I don't mean to interject, but to provide an example, there's another view technology for JSF that's being developed under Sun's guidance called 'Facelets'. It has a heavy emphasis on valid XML markup with built in templating and Tapestry functionality similar to 'jwcid'.

    JSF Facelets

    Facelets only needs to provide a custom ViewHandler to JSF-- all components, statemanagers-- everything else works 'out of the box'.

    -- Jacob
  49. I do not see why an average "templator" would be more capable than me.Steve, since you apparently know much more than me about JSF, could you, please, answer the following question? How possible/easy is substituting JSP with Velocity templates in JSF, in reality?

    I may have been misunderstanding what you were saying. I assumed I was responding to your comments about look and feel, and that use of JSF implied somehow that the web applications would look and act like a desktop application.
    Does it look like JSF will have a full-fledged, out-of-the-box support for alternative templating engines like Velocity? I am not a big fan of JSP, whether used in JSF, Struts or wherever and prefer Velocity. This preference comes simply from the feedback from designers - people who are _meant_ to be working on templates, would rather work with Velocity than JSPs.thanks. P.S. When I say "full support" I mean a situation when equivalent Velocity macros are available for usage for main JSP tags of JSF. It should be equivalent at the level that JSP and VMs can be used interchangably without a problem. When somebody suggest me to write a controller/renderrer or something like that - I see that as a possible point of extension - not support.

    As JSF is a specification and not a product, out-of-the-box support depends on what is provided by a particular JSF implementation - it depends which vendor's box you open! However, at the moment, I don't know of an implementation that allows such support.
  50. Velocity support[ Go to top ]

    I am not sure if you can plug velocity the way velocity is used in web frameworks (using the velocity servlet to render velocit y templates), but there is a way to have some velocity support in JSF, you can write Velocity components, which basically use Velocity as rendering templates and pass the JSF parameters down. That would be rather straightforward to implement, to my knowledge of the framework.

    I have been using JSF for almost half a year now, and although the learning curve, once you dig deeper than faces-config and the standard tags, and the datamodel classes which come out of the box, which most users probably will be happy with, is one of the steepest for any framework I had yet to encounter, it pays off in the long run.

    I Implemented a full blown webapp presentation ready with a hibernate backend and lots of custom controls within about 10 days, 7 of them were basically spent for the implementation of the custom controls, and some bugs I encountered in the way and some misunderstanding of Hibernate on my side, 3 for the webapp itself.

    The tools I used were none, except a few handwritten xdoclet templates and a tool which generated the hibernate mapping classes.
    The hardest part was basically the implementation of the custom controls, and keeping track of the code artefacts scattered around the system, but good tools should handle that in the long run.

    I have to admint however, I really spent a long time upfront to get a grasp on all the functionality and constraints JSF has. Currently JSF is rather tool friendly, but rather hard to program without tools or code generators, there are too many xml based artefacts which are made for being easy to parse by machines which have to be maintained.
  51. Velocity support[ Go to top ]

    I have been using JSF for almost half a year now, and although the learning curve, once you dig deeper than faces-config and the standard tags, and the datamodel classes which come out of the box, which most users probably will be happy with, is one of the steepest for any framework I had yet to encounter, it pays off in the long run.
    Currently JSF is rather tool friendly, but rather hard to program without tools or code generators, there are too many xml based artefacts which are made for being easy to parse by machines which have to be maintained.

    I am curious when people say that JSF is hard to learn and hard to program without tools, as I can honestly say that my experience is the exact opposite. I'm not sure how JSF could be simpler. The tags for components are placed on a web page, and the properties and events of the are mapped to properties and methods in beans via simple XML in a single configuration file. After having used Struts, I found JSF to be incredibly intuitive. I also find it very easy to hand-code - I don't use tools. There may be verbose (so easy-to-read) XML tags in the configuration file, but any decent IDE will handle XML without having to have any additional JSF support. The tags are certainly no more work than in Struts.
  52. Velocity support[ Go to top ]

    I am curious when people say that JSF is hard to learn and hard to program without tools, as I can honestly say that my experience is the exact opposite. I'm not sure how JSF could be simpler. The tags for components are placed on a web page, and the properties and events of the are mapped to properties and methods in beans via simple XML in a single configuration file. After having used Struts, I found JSF to be incredibly intuitive. I also find it very easy to hand-code - I don't use tools. There may be verbose (so easy-to-read) XML tags in the configuration file, but any decent IDE will handle XML without having to have any additional JSF support. The tags are certainly no more work than in Struts.

    I don't think it's so much JSF, but the way that JSP handles integrating into JSF. You go through the work of developing a Validator, not only to you have to put a name/class entry in the faces-config.xml, but you also have to develop another JspTag along with a full descriptor. So, I wouldn't blame JSF, just that it's work to properly integrate within JSP. It's neither spec's fault.

    I've taken those complaints and developed a new framework called Facelets. I don't mean to grandstand the project (really ;-)), but there's zero tag development time for JSF objects and the pages look and feel like JSPX/Tapestry.

    Facelet Overview

    Templating in Facelets

    Tapestry Behaviors

    Zero Tag Development Example

    -- Jacob Hookom (JSR 252 EG and EL-API)
  53. This preference comes simply from the feedback from designers - people who are _meant_ to be working on templates, would rather work with Velocity than JSPs.
    Why do not use Tapestry and let those folks work with HTML?
  54. This preference comes simply from the feedback from designers - people who are _meant_ to be working on templates, would rather work with Velocity than JSPs.
    Why do not use Tapestry and let those folks work with HTML?

    Actually, I don't like the idea of 'designers' touching any of the actual web pages. They only have a partial understanding of the full toolset available to a Java programmer and often times I've found that a programmer can tackle the solution in a much more efficient manner than simply bending over to accomodate a 'designers' inability to fully utilize dynamic frameworks.

    The right way to tackle web pages.
  55. This preference comes simply from the feedback from designers - people who are _meant_ to be working on templates, would rather work with Velocity than JSPs.
    Why do not use Tapestry and let those folks work with HTML?

    They could, but JSF has real advantages: it is a JSR specification and there are a rapidly increasing number of freely available high-quality components available from multiple vendors. JSF also allows developers the possibility of supporting more than just HTML.