JavaServer Faces interview: Ted Farrell and Adam Winer

Discussions

News: JavaServer Faces interview: Ted Farrell and Adam Winer

  1. Lots of developers are taking a look at JavaServer Faces (JSF) technology from Sun. Oracle has been making significant investments into the technology also. On behalf of TSS, Miko Matsumura interviews two of Oracle’s key technical people around JSF, Ted Farrell and Adam Winer.

    Ted Farrell is chief architect for Application Development Tools at Oracle Corporation. Ted is responsible for the technical and strategic direction of Oracle's development tools products, including JDeveloper 10g and the ADF framework. Ted has more than 15 years of
    experience building enterprise-class applications and tools.

    Adam Winer is the Oracle representative to the JavaServer Faces Expert Group, and the architect of ADF Faces. He has more than 10 years of experience developing user interface frameworks.

    Ted and Adam provide some of their thoughts on the JSF specification, Oracle’s implementation and the future of the technology and its use.

    What is the future of JavaServer Faces?

    [Adam Winer] "In the immediate future, the single biggest task for the JSF specification itself is becoming a more integrated part of the J2EE platform, and working better with core J2EE technologies like JSP and JSTL. The good news is that JSF 1.2 will be included as a core component of the J2EE 5.0 specification. The first fruits of this effort have already made an appearance with the early drafts of the JSF 1.2 and JSP 2.1 specifications, where we (the J2EE expert groups) have unified our expression language APIs, which will bring a lot of benefits to both JSF and JSP.

    However, I feel that the most critical part of the future of JSF will come not from the work of the expert group on the specification - though that is important - but instead will come from the efforts of the JSF community out there to build a large and healthy ecosystem of JSF components and JSF technology. We think ADF Faces can be a vital part of that ecosystem."

    What is Oracle doing with JSF?

    [Ted Farrell] "Oracle fully supports industry standards, and JSF is no different. Oracle has had dedicated resources (lead by Adam) involved with the JSF expert group since the beginning and has made valuable contributions to the specification. Oracle produces both a rich set of Faces components as well as a visual design-time to allow developers to easily use the technology to build applications. Oracle was the first major vendor on the market to demonstrate working Faces components."

    [Adam Winer] "Oracle ADF Faces [add URL: http://www.oracle.com/technology/products/jdev/htdocs/partners/addins/exchange/jsf/index.html] is, in large part, a large component library built on top of the JSF standard. It offers a number of UI framework features, such as client-side validation and a dialog framework, that aren't available elsewhere. ADF Faces uses the Sun reference implementation and runs on top of any compliant JSF implementation - there isn't an Oracle implementation of JSF."
     
    Is JSF usable without an IDE?

    [Adam Winer] "Absolutely. JSF can be used without an IDE in the same way that HTML pages can be built without Dreamweaver, and that Struts code can be written in Emacs. Nothing in JSF requires an IDE.

    What I think has caused some confusion is that JSF has also put a lot of effort into ensuring that JSF is very toolable, so that an IDE can add more value to JSF than it could, for example, to old-style JSPs. There's a rich set of information available to IDEs in a user's faces-config.xml and a component library's faces-config.xml that can be used to enhance the experience of a user that is using tools. So, it isn't that life is now harder for developers not using an IDE, but instead that life is significantly better for developers that are using an IDE."

    Some complain that JSF tags are too far from HTML and thus unfriendly to web designers - please comment.

    [Adam Winer] "I can't quite understand that complaint in terms of the JSF tags provided by the JSF specification. Most of these are one-to-one replacements for HTML tags, like <h:inputText> instead of <input type="text">.

    However, if you begin to look at the ADF Faces component library, you do see a move away from HTML and towards higher-level components. I believe that while raw HTML editing has its place and will continue to have its place, there is an enormous advantage towards starting to move to higher-level components that provide lots of user interactivity. Too many of the web pages built today look the same as they did five years ago, and only the biggest, best-staffed sites are offering really new user interfaces. A lot of that comes from this constant need to re-invent the wheel and rebuild every page from the lowest common denominator. The ADF Faces rich client effort is a fine example of how JSF lets us move forward."

    Why would someone choose JSF over classic JSP and Struts, how would you differentiate, and will JSF replace Struts

    [Adam Winer] "Struts is, at its core, a Controller framework. There are pieces of it that operate as a View - like its HTML tags and the Tiles library - but these are generally peripheral to where it truly adds value.

    JSF, on the other hand, is at its core a View framework, and it solves a lot of problems in this area that Struts has simply never addressed. Most significantly from our perspective, it provides a UI component model that enables a much richer component set and user interaction model.

    JSF won't "replace" Struts any more than Java replaced C++, but my belief is that over the next few years there will be more innovation around the JSF standard than on top of Struts, and where Struts will move forward is in the area of Controller features that aren't handled by JSF."

    What is Oracle's vision for JSF post JSF 1.1?

    [Ted Farrell] "Oracle plans to continue to build on the JSF technology. We are extending our support by adding render kits for DHTML, Mobile & telnet devices. This allows us to provide a single programming interface to our users (J2EE/Faces) and have them be able to support a wide variety of devices. Many other vendors’ UI solutions require the developer to have in-depth knowledge of DHTML, JavaScript or mobile graphics technologies."

    Does ADF Faces support platforms beyond Oracle?

    [Adam Winer] "Yes, it does. ADF Faces (and ADF as a whole) is designed to run on top of application servers and databases other than Oracle."

    [Ted Farrell] "We certify the technologies on JBoss, WebLogic & WebSphere, as well as SQLServer, DB2 and MySql databases."

    Why would someone choose Oracle's JSF offering over MyFaces or ... How are you differentiated?

    [Ted Farrell] "With the Faces standard, tools and runtimes from all different vendors can work with any Faces-compliant component. Therefore, the big differences in vendor technologies come down to the components. Oracle ADF Faces is a diverse set of enterprise-class components that are very data aware. Many out-of-the-box components might look nice, but when it comes to getting the data from your application displayed on the page so it can be manipulated and viewed by your users, the implementation of the components make all the difference. Instead of having to write a whole bunch of extra code or extend the components to get them as interactive as you need them, ADF Faces gives you dozens of ready-to-use, data aware components that you can easily customize to your own look-and-feel using the built-in "skinning" technology."

    [Adam Winer] "ADF Faces is a much broader and more robust set of components than any other available today. ADF Faces is already being used widely inside of Oracle, and as such it includes features like accessibility and internationalization that may be afterthoughts elsewhere. But one of the great advantages of JSF as a standard is that using ADF Faces doesn't lock you into only using ADF Faces. Developers can combine components from multiple JSF vendors."

    How does JSF compare to rich web client technologies such as Macromedia's Flex, DHTML or SVG?

    [Ted Farrell] "While there are many technologies on the market that can be used to display applications on the client, you also have to consider the cost of those technologies. Some questions that come up with our customers are "do I have to learn a new programming language?", "how many types of devices does it support?" and "can I reuse the components in different environments?". The big difference with Faces and the rest of the technologies is that the answers to these questions are "no", "as many as you want" and "yes".

    With Faces, you program to a single, consistent programming interface and then the components handle the rest. For example, some of the ADF Faces components can render to HTML, web devices, DHTML/JavaScript and even Telnet. The programmers don't have to learn to program in each of these environments and languages. Instead, they have a single API with a single development tool across all the different thin-client technologies."

    Tell me about Oracle's contribution to the JSF Expert Group.

    [Ted Farrell] "Oracle has participated in JavaServer Faces since it was first announced to the public and has been a major contributor since the very first expert group meeting. Oracle came to the table with a lot of experience building a UI framework for the web in ADF UIX and J2EE development tool work in J2EE, and we were able to contribute much based on that experience. Adam Winer, the Oracle member of the expert group, has been one of the most active members from the earliest kick-off meetings through today's design work on JSF 1.2."

    What is missing in the current JSF specification that Oracle would like to contribute back to the EG?

    [Adam Winer] "A couple of features come quickly to mind. First, JSF does not work with the JSTL <c:forEach> tag that is loved by many J2EE developers, and it wasn't obvious how <c:forEach> could be changed to work. ADF Faces has found a way to make it work, and is working to contribute that back into the J2EE standard. Second, client-side input validation is not currently supported by the standard JSF components, but is supported in ADF Faces, and that can be contributed back as well."

    Looking at adoption of Faces, what would be the main obstacle for Faces to become the ASP equivalent in the J2EE world?

    [Ted Farrell] "I think Faces' adoption in the industry, like any other standard, is directly tied to its adoption among the different software vendors. In the case of Faces, every major software vendor is working on providing solutions for the technology. With the vendors dedicating resources to this effort, and working with their customers to match the technology to their real-world needs, the future of Faces should be strong and secure"

    On behalf of the community at TheServerSide.COM, thanks for talking with us today about JSF.

    Threaded Messages (33)

  2. JSF and Struts[ Go to top ]

    Very good interview,

    My only question is that in my opinion, it´s clear that struts is a controller central framework and JSF is a view central framework, you can use both with the jsf-struts integration library but, i think that the evolution of the JSF specification will be the incorporation of the controller part of the struts framework, and, in a near future, the struts framework development will be stopped and the efforts will be on free open source implementation/components library like ADF , Myfaces, Ourfaces, etc....
  3. http://today.java.net/pub/n/Shale
  4. In this week's installment of OTN's Mastering J2EE Application Development Series, Craig McClanahan, creator of Struts, shares his views on Integrating JSF with Struts in Your J2EE Applications). He does refer to project (code named "Shale") that envisions a Struts 2.0 that is built around JavaServer Faces.

    Checkout The Best of Both Worlds: Integrating JSF with Struts in Your J2EE Applications

    You might also be interested in this article Build complex Web UIs using components from the JSF-compliant Oracle ADF Faces framework
  5. JavaServer Faces[ Go to top ]

    JSF might be an improvement over JSP, but lets compare oranges to oranges: What (technical) advantages JSF has over Tapestry or Echo or WebOnSwing. In other words: There are component oriented frameworks which provide event driven programming model, in which way JSF is better or different?
  6. JavaServer Faces[ Go to top ]

    JSF might be an improvement over JSP, but lets compare oranges to oranges: What (technical) advantages JSF has over Tapestry or Echo or WebOnSwing. In other words: There are component oriented frameworks which provide event driven programming model, in which way JSF is better or different?

    Main advantage is that it's going to be part of J2EE 5.0.

    Which means:

    Support of vendors. To management, it will keep switching costs down. It may also mean, by the time J2EE 5 is out, that there are tools that support the framework to make life easier for developers.

    Lower cost of support due to developer pool of J2EE. Use the "bus" adage. If Bob gets run over by a bus, who can support this? Ideally, something in J2EE will have a larger pool of developers to hire from. There are exceptions to this rule, but not in this specific space, with the alternatives you've outlined.
  7. JavaServer Faces[ Go to top ]

    JSF might be an improvement over JSP, but lets compare oranges to oranges: What (technical) advantages JSF has over Tapestry or Echo or WebOnSwing. In other words: There are component oriented frameworks which provide event driven programming model, in which way JSF is better or different?
    Main advantage is that it's going to be part of J2EE 5.0. Which means:Support of vendors. ...

    That is a promise and a kind of ‘political’ advantage.
    Entity Beans are in J2EE spec for 5 years already and vendor supported, but it does not make them very attractive for a lot of uses, does it?
  8. JavaServer Faces[ Go to top ]

    JSF might be an improvement over JSP, but lets compare oranges to oranges: What (technical) advantages JSF has over Tapestry or Echo or WebOnSwing. In other words: There are component oriented frameworks which provide event driven programming model, in which way JSF is better or different?
    Main advantage is that it's going to be part of J2EE 5.0. Which means:Support of vendors. ...
    That is a promise and a kind of ‘political’ advantage. Entity Beans are in J2EE spec for 5 years already and vendor supported, but it does not make them very attractive for a lot of uses, does it?

    Let me rephrase answer then :)

    If you're in a highly political business environment, any technology in a "standard" is going to have an advantage. Anything outside of a standard will have to truly shine, or have become a defacto standard.

    If you're not in an environment like that, JSF probably doesn't have the advantage...yet. If you're a consultant looking to sell your services with your own framework, then...JSF is definately not for you.

    I can't give you the answer I think you're looking for. Only the perspective I have from the middle of Ohio.
  9. JavaServer Faces[ Go to top ]

    ...JSF is definately not for you.I can't give you the answer I think you're looking for. Only the perspective I have from the middle of Ohio.
    My perspective (from KC till summer :) )
    - do not care much about politic because is able to define politic in the proximity;
    - do want to jump from Struts to something more convenient and efficient;
    - do not want wasting time on mastering something inefficient/short living;
    - do NOT want to invent and promote own framework,
    - do want to master something that will be reasonably usable and efficient in the next 3-5 years;

    JSF looks like half-baked solution for me (sort of band-aid to cure tuberculosis) therefore I look for technical information that could help me make a decision. So…any links and thoughts please
  10. JavaServer Faces[ Go to top ]

    Even in big companies, politics can be influenced. You just need the right people for it.

    Check out Wicket, Tapestry or Echo if you want to be able to program neat OO, want to be able to easily create custom components, etc.

    Use JSF if you want the drag 'n drop and want to reuse market place components.
  11. JavaServer Faces[ Go to top ]

    ...JSF is definately not for you.I can't give you the answer I think you're looking for. Only the perspective I have from the middle of Ohio.
    My perspective (from KC till summer :) )- do not care much about politic because is able to define politic in the proximity;- do want to jump from Struts to something more convenient and efficient;- do not want wasting time on mastering something inefficient/short living;- do NOT want to invent and promote own framework, - do want to master something that will be reasonably usable and efficient in the next 3-5 years;JSF looks like half-baked solution for me (sort of band-aid to cure tuberculosis) therefore I look for technical information that could help me make a decision. So…any links and thoughts please

    If you've got Struts experience, then I would just maybe understand basics of JSF and keep a close eye on Struts 2 (Shale), which basically says that they plan to use JSF as the view component, and concentrate on Struts being the controller.

    As you can see: http://www.apache.org/~craigmcc/struts-shale/ The proposed API will include 4 packages of JSF integration components to handle the view.

    Unfortunately, the on-line proposal to read appears to be down at this time.

    http://svn.apache.org/viewcvs.cgi/*checkout*/struts/trunk/contrib/struts-shale/README.html
  12. JavaServer Faces[ Go to top ]

    If you've got Struts experience, then I would just maybe understand basics of JSF and keep a close eye on Struts 2 (Shale), which basically says that they plan to use JSF as the view component, and concentrate on Struts being the controller.
    I would say that exactly because I am a long time Struts user I see JSF as optional and unnecessary wheel spinning without real progress.
  13. JavaServer Faces[ Go to top ]

    If you've got Struts experience, then I would just maybe understand basics of JSF and keep a close eye on Struts 2 (Shale), which basically says that they plan to use JSF as the view component, and concentrate on Struts being the controller.
    I would say that exactly because I am a long time Struts user I see JSF as optional and unnecessary wheel spinning without real progress.

    I'll tell u what I like then...I really like the injection points for JSF managed beans (ala Spring). My first app just used session beans due to its simplicity, but it was really nice to let the "engine" (application bean) inject itself into the session beans via the faces-config file.

    One of my coworkers is going to use it because of the validation features for a pet learning project.

    IMHO, it wouldn't hurt to play with it...because Shale is basically saying it will be the view controller for Struts 2.
  14. JavaServer Faces[ Go to top ]

    My perspective (from KC till summer :) )
    - do not care much about politic because is able to define politic in the proximity;
    - do want to jump from Struts to something more convenient and efficient;
    - do not want wasting time on mastering something inefficient/short living;
    - do NOT want to invent and promote own framework,
    - do want to master something that will be reasonably usable and efficient in the next 3-5 years;

    JSF looks like half-baked solution for me (sort of band-aid to cure tuberculosis) therefore I look for technical information that could help me make a decision. So…any links and thoughts please

    Check out WebWork. That's my completely fair and unbiased opinion :-)
  15. JavaServer Faces[ Go to top ]

    Check out WebWork. That's my completely fair and unbiased opinion :-)
    Thanks, could you provide a biased opinion/comparison between WebWork and Tapestry (do not have to type, links are fine )? I am kind of semi settled/focused on Tapestry now and would like to verify my position and assumptions.
  16. JavaServer Faces[ Go to top ]

    Thanks, could you provide a biased opinion/comparison between WebWork and Tapestry (do not have to type, links are fine )? I am kind of semi settled/focused on Tapestry now and would like to verify my position and assumptions.

    Well, let me preface by saying that I'm a core developer on WebWork and not that familiar with the details of Tapestry.

    That said, I'm not a huge fan of the page controller paradigm or using event handling / listeners for components in a web page. For me, it's really cutting against the grain of the medium. HTTP is a request / response protocol much better suited to a command pattern (IMHO).

    I also like libraries that are relatively small and loosely coupled. For instance, XWork is the command pattern framework WebWork uses. WebWork is the wrapper on top of XWork to translate HTTP requests and responses to the way XWork works. It adds a ServletDispatcher, some web-specific interceptors, etc, and a taglib.

    There is also XMLRPCWork which is an XMLRPC front end to XWork. There's MessageWork which I wrote which is a JMS framework built on XWork to handle messages, route messages, etc. There's an ObjectDispatcher which can be used on the client side to bundle up commands to be sent to the server, executed, and returned to the client. There's a mail dispatcher that listens to a mailbox and executes Actions based on the email it receives. Someone's working on SwingWork to act as the MVC behind Swing.

    This is not to say that Tapestry is not well designed. I haven't really looked into the internals (except to note the IMyInterface naming, yuck :) ), but what I've seen is that it's all one framework. It's got too much of a mix of presentation and controller for me (just for me, your preferences may differ).

    It works well for a lot of people and people whom I respect and think are very intelligent really like it. I'm not going to say that one or the other should be the "one true way", I think it depends on your personal preferences and how you design and code. I think there are several solutions out there that are well designed and work well. Of note among those that would not make that list (for me) are Struts and JSF, but YMMV.
  17. JavaServer Faces[ Go to top ]

    Main advantage is that it's going to be part of J2EE 5.0. Which means:Support of vendors. To management, it will keep switching costs down. It may also mean, by the time J2EE 5 is out, that there are tools that support the framework to make life easier for developers.Lower cost of support due to developer pool of J2EE. Use the "bus" adage. If Bob gets run over by a bus, who can support this? Ideally, something in J2EE will have a larger pool of developers to hire from. There are exceptions to this rule, but not in this specific space, with the alternatives you've outlined.

    This sounds exactly like what people used to say about EJBs, even Entity Beans.
  18. JavaServer Faces[ Go to top ]

    Main advantage is that it's going to be part of J2EE 5.0. Which means:Support of vendors. To management, it will keep switching costs down. It may also mean, by the time J2EE 5 is out, that there are tools that support the framework to make life easier for developers.Lower cost of support due to developer pool of J2EE. Use the "bus" adage. If Bob gets run over by a bus, who can support this? Ideally, something in J2EE will have a larger pool of developers to hire from. There are exceptions to this rule, but not in this specific space, with the alternatives you've outlined.
    This sounds exactly like what people used to say about EJBs, even Entity Beans.

    So if a method is incorrect 10% of the time, yet right the other 90%, does that make it an invalid method?

    I offer this suggestion as one who has reported to managers who report to managers who believe they're able to make technical decisions because they know how to use MS Project or wrote a Hello World program. By the time the information gets down to people who actually know something, you spend time trying to clean up their mess.

    That's why, for me, it's much more important to have exceptional standards so that they'll be more likely to be picked by management. And hence, it's also important to know something about the poor standards...because they might get picked too.

    Up to you if you think JSF is a poor standard or not. However, you do know what Entity Beans are? Learn the enough of the technology to be dangerous and able to speak to it...not enough to be an expert.
  19. Accepting Ted's comment that JSF supports different devices and reuse of components in different environments, I wonder if Flex and XAML will generate enough momentum to squeeze JSF into a niche market?

    Have I just inferred that support for multiple devices etc is a niche market. I expect many will consider that this is hardly the case. As I do myself :-).

    Perhaps I need to better understand Flex and XAML support for different devices....
  20. When MS designed WebForms, instead of teaching VB programmers how to separate View from Model, MS provided them with evil page-oriented paradigm, easing the pain of switching from desktop to web development. The VB guys now joyfully mess up web applications just the way they used to do it with desktop. I don't even want to get started on the viewstate. MS recently realized that page-based approach in WebForms brings only that far, so they are going to roll out built-in support for Front Controller in ASP.NET 2.0 (which the old-fashioned Struts has from day one). MS also plans to deprecate WebForms after Avalon/XAML rolled out. When this technological leap happens, Java software engineers will be adopting JSF, which cannot perform a redirect within faces request/response cycle.
  21. ... JSF, which cannot perform a redirect within faces request/response cycle.
    Can you explain this a bit further? I am reading a JSF book now, in case I need/decide to use it. So why is a redirect needed? I don't think Echo or Web-On-Swing can do that.


    I agree about WebForms. The page paradigm needs to go away for those things that are truly application UIs. It is still great for document style and basic searching websites.

    Got any links to the Avalon/XAML killing WebForms? I would love to see that.

    Mark
    (These are my personal views. Feel free to disagree.)
  22. ... JSF, which cannot perform a redirect within faces request/response cycle.
    Can you explain this a bit further? I am reading a JSF book now, in case I need/decide to use it. So why is a redirect needed?
    I thought it was you who pointed me out at this book: Alex and Philips Guide to web publishing" after TSS published my huge article about Redirect-after-Post pattern. Oh, no it was Karl Banke. Then I would like to reiterate very briefly.

    The actions of model update and view rendering must be separated. This is simply a good modular design for a desktop application, but for web application this means better usability and robustness. Data submission must occur during one request (usually POST), and page rendering must occur during another independent request (usually GET). Thus you can safely refresh a page without resubmitting the previous form. And you can go back and forward is browser session history without resubmitting stale forms and without seeing "Do you want to resend POSTDATA?" message.

    The separation of input and output into two requests allows to provide easier navigation with less restrictions. This model works great with state stored completely on the server, so you can leave the application, browse another website and then come back to the same URL and you will get the same output as before, because state is stored on the server, not transported back and forth in the hidden fields or in the request parameters.
     
    So, from what I see in the specs, there are three request/responce types:
    * Non-Faces Request Generates Faces Response
    * Faces Request Generates Faces Response
    * Faces Request Generates Non-Faces Response

    The second option is "the most common lifecycle ... [which] includes user interface controls that will submit a subsequent request to this web application, utilizing a request URI that is mapped to the JSF implementation’s controller" (2.1.2)

    "The handleNavigation method may select a new view by calling createView() on the ViewHandler instance for this application, optionally customizing the created view, and then selecting it by calling the setViewRoot() method on the FacesContext instance that is passed. Alternatively, the NavigationHandler can complete the actual response (for example, by issuing an HTTP redirect), and call responseComplete() on the FacesContext instance." (7.4.1)

    "The responseComplete() method signals the JSF implementation that the HTTP response for this request has been completed by some means other than rendering the component tree, and that the request processing lifecycle for this request should be terminated when the current phase is complete. For example, an event listener that decided an HTTP redirect was required would perform the appropriate actions on the response object (i.e. calling ExternalContext.redirect()) and then call this method." (6.1.7)

    If I understand the specs correctly, responseComplete() this transfers application outside Faces lifecycle. I am not saying that it is impossible to use redirection in JSF, but looks like that JSF does not have built-in support for that within standard Faces request/response lifecycle. Using redirection appears to be more like a hackish round-trip. Frankly, I have not tried to compile a real JSF application yet, I make my judgement based solely on specs. Seems that JSF already stores a lot of view-related data on the server, it could include support for redirection as well. Should I send my suggestions to JCP? ;)
    Got any links to the Avalon/XAML killing WebForms? I would love to see that.
    From John Montgomery's Weblog: "Windows Forms will continue to be part of the .NET Framework and supported as such and is the main way to write managed code today to prepare for Avalon. ... When delivered, Avalon will become Microsoft’s strategic UI platform. ... The interoperability technology [between Avalon and Windows Forms] will help customers smoothly transition to Avalon. ... Following the release of Avalon 1.0, the next version of Visual Studio following Visual Studio 2005 will contain tools and designers to support Avalon. At this point, customers should start to move their new development efforts to Avalon."
  23. Michael,

    When you use the <redirect/> element - in standard faces-config.xml navigation rules - or call ExternalContext.redirect() and FacesContext.responseComplete() for any alternative approach - you are following exactly the "POST for data submission, subsequent GET for rendering" model that you espouse. I don't understand why you turn around and say "Using redirection appears to be more like a hackish round-trip.", since redirection is exactly what you have to do to follow the POST/GET model you favor, JSF or no JSF.

    In a sense, this does go outside of the JSF lifecycle, but since you redirect back to another JSF page, from the perspective of the user, it's simply a JSF POST for data submission, followed by a JSF GET for rendering.

    Regards,
    Adam Winer
  24. Michael,When you use the <redirect/> element - in standard faces-config.xml navigation rules - or call ExternalContext.redirect() and FacesContext.responseComplete() for any alternative approach - you are following exactly the "POST for data submission, subsequent GET for rendering" model that you espouse.
    Adam, I finally checked out all needed jars and build the "Guess number" sample. I added <redirect/> element and it worked beatifully. I apologize, it IS possible and easy to create an application which has input and output separated. I should not jump to quick conclusions after merely reading the specs. On the other hand, I would like to see this approach as standard in JSF, so it would encourage to create user-friendly web applications. I did not find redirection not even in one JSF sample. It should not be hard to follow this pattern, because JSF already keeps the state on the server. This is where JSF clearly better than Web Forms with its clunky _viewstate (though developers do not have to use _viewstate).
    I don't understand why you turn around and say "Using redirection appears to be more like a hackish round-trip.", since redirection is exactly what you have to do to follow the POST/GET model you favor, JSF or no JSF.
    No, I thought I would be a roundtrip in JSF terms.
    In a sense, this does go outside of the JSF lifecycle, but since you redirect back to another JSF page, from the perspective of the user, it's simply a JSF POST for data submission, followed by a JSF GET for rendering.
    Thanks for clarifying this, Adam. While we on it, may I ask you another question? Struts has Controller.nocache element, which allows to set "no-cache, no-store" headers in the response. I did not find cache-relative settings in faces-config.xml. Is it possible to mark responses as non-cacheable? I guess if JSF intends to supersede Struts, it has to support all Struts features.
  25. Adam, I finally checked out all needed jars and build the "Guess number" sample. I added <redirect/> element and it worked beatifully. I apologize, it IS possible and easy to create an application which has input and output separated. I should not jump to quick conclusions after merely reading the specs. On the other hand, I would like to see this approach as standard in JSF, so it would encourage to create user-friendly web applications. I did not find redirection not even in one JSF sample. It should not be hard to follow this pattern, because JSF already keeps the state on the server. This is where JSF clearly better than Web Forms with its clunky _viewstate (though developers do not have to use _viewstate).

    Like every interesting technique, there are tradeoffs to using PRG as your mechanism for avoiding double submits. The most important ones are the extra time it takes for the second round trip, and the fact that you can't use request attributes to pass data from the "from" page to the "to" page any longer. For some applications, these costs are going to be too high.

    One of the small goodies I recently added to Shale was a small JSF component called Token, which basically does for JSF what transaction tokens do for Struts apps, but with a difference ... the actual check of the token is done in the validator for the Token component. That means the only developer gesture needed to enforce submit protection is to add this component nested inside any form that needs double submit protection (which is <strong>NOT</strong> all of them).

    It certainly makes sense for people describing JSF to talk about the double submit issue -- I would just quibble with your conclusion (in the article) that redirects are *the* solution. They are only *a* solution, and any discussion of the topic should discuss other options as well (along with their tradeoffs).


    I don't understand why you turn around and say "Using redirection appears to be more like a hackish round-trip.", since redirection is exactly what you have to do to follow the POST/GET model you favor, JSF or no JSF.
    No, I thought I would be a roundtrip in JSF terms.
    In a sense, this does go outside of the JSF lifecycle, but since you redirect back to another JSF page, from the perspective of the user, it's simply a JSF POST for data submission, followed by a JSF GET for rendering.
    Thanks for clarifying this, Adam. While we on it, may I ask you another question? Struts has Controller.nocache element, which allows to set "no-cache, no-store" headers in the response. I did not find cache-relative settings in faces-config.xml. Is it possible to mark responses as non-cacheable? I guess if JSF intends to supersede Struts, it has to support all Struts features.
  26. Grumble grumble ... no preview mode ... grumble grumble.
    Adam, I finally checked out all needed jars and build the "Guess number" sample. I added <redirect/> element and it worked beatifully. I apologize, it IS possible and easy to create an application which has input and output separated. I should not jump to quick conclusions after merely reading the specs. On the other hand, I would like to see this approach as standard in JSF, so it would encourage to create user-friendly web applications. I did not find redirection not even in one JSF sample. It should not be hard to follow this pattern, because JSF already keeps the state on the server. This is where JSF clearly better than Web Forms with its clunky _viewstate (though developers do not have to use _viewstate).

    Like every interesting technique, there are tradeoffs to using PRG as your mechanism for avoiding double submits. The most important ones are the extra time it takes for the second round trip, and the fact that you can't use request attributes to pass data from the "from" page to the "to" page any longer. For some applications, these costs are going to be too high.

    One of the small goodies I recently added to Shale was a small JSF component called Token, which basically does for JSF what transaction tokens do for Struts apps, but with a difference ... the actual check of the token is done in the validator for the Token component. That means the only developer gesture needed to enforce submit protection is to add this component nested inside any form that needs double submit protection (which is <strong>NOT</strong> all of them).

    It certainly makes sense for people describing JSF to talk about the double submit issue -- I would just quibble with your conclusion (in the article) that redirects are *the* solution. They are only *a* solution, and any discussion of the topic should discuss other options as well (along with their tradeoffs).
  27. One of the small goodies I recently added to Shale was a small JSF component called Token, which basically does for JSF what transaction tokens do for Struts apps, but with a difference ... the actual check of the token is done in the validator for the Token component. That means the only developer gesture needed to enforce submit protection is to add this component nested inside any form that needs double submit protection (which is <strong>NOT</strong> all of them).

    It certainly makes sense for people describing JSF to talk about the double submit issue -- I would just quibble with your conclusion (in the article) that redirects are *the* solution. They are only *a* solution, and any discussion of the topic should discuss other options as well (along with their tradeoffs).
    Craig, thanks for joining. During last six months or so I was passionately promoting this [not as new as I initially thought] idea of separating input (usually submitted by POsT) from output (usually loaded by GET). Despite your position that this is just *a* solution, I believe that this is *the* solution, at least in terms of current HTTP 1.1 standard. Now I will try to convince you, please be impartial.

    First off, what is more important, the correctness, robustness and usability of an applicaiton, or savings on network roundtrip? We are developing end-user applications, not geeky assembly hacks. End users want the comfort, they want being cared of, they want to have option to make mistakes. They often do not know what they want or what they do, so they jump around back and forth. They are often impatient and think that the if they kick the application again, it returnes result faster, so they hit Reload (or even resubmit) all the time. These users will have better user experience, if the page they are reloading merely shows current business data from the server, and if the page they going back to, does not allow to resubmit data.

    This whole resubmit thing has usability and technology layers. On technology layer it is indeed possible to detect resubmit and to react on it, great. But what about freaking POSTDATA dialogs, which drive me nuts? Am I the only psycho concerned by these popups here and there? They are ugly, they pollute user interface, but best of all that they can be avoided. I started to think about redirection after I got infuriated with POSTDATA messages on every second website. Hell, my online banking experience is just like that. And another website which sells car accessories, they have a long hierarchy of goods so it takes three to five screens to delve inside, and when you unwind back, you see POSTDATA messages for every previous page! I would strange the guy who did this.

    Now let us talk about savings on network traffic. If a user reloads a page which is a result of form submission, he resubmits the request again. Here go the form fields including possibly bunch of hidden fields. Don't forget about additional processing on the server. And if we recall technologies like Web Forms, which provide lazy developers with handy _viewstate, we can talk about kilobytes or even tens of kilobytes. Which are encrypted and decryption takes time too. You think that viewstate ping-pong is more efficient than sending object ID with redirection request? If you talk about time needed for the roundtrip, this does not make a noticeable impact either. A user stares on a web pages a lot longer than it takes to display another page. I would say, the response time within two seconds is tolerable, but usually it takes less than a second even on a dialup connection. And what are you saving the bandwith for? For someone to fill the void in the cable with another 700MB of porn?

    Now, what I am arguing for. It is separation of input from output. It has two slightly different levels. First level is logical: the model update should happen only once, when data is submitted, and consecutive responses should simply display current server object. Second level is user experience: a user should not see nasty POSTDATA messages. Thus, if a request changes server state (either GET or POST) or if it is simply a POST, then response should be redirected.

    Benefits:
    * Painless refresh and navigation back and forward, because no data is submitted, data is only shown.
    * Robustness of the application, because there is less chance to resubmit stale data (unless a user explicitly clicked Submit button again, but there is another solution for this).
    * Unversal view, which means that the same view can be used to display existing object or to input a new object, because all that view cares about is object ID. It does not expect any other information in the request.
    * Free browsing: a user can mix and match viewed pages, jump here and there, go to another application then return back, and he will see the same output, because server state has not changed. With parameters sent from one page to another as request query parameters, the flow is frozen and one cannot jump out of it without breaking the whole thing.
    * web is about being stateless and is about client/server. Not really that different from X Window, i think. Web is about addressing the resource, not a page, and about getting a view of that resource relevant to client type and media, not some cast in iron HTML page. Using page controller paradigm and viewstate is not stateless and not MVC. It is the spaghetti for lazy ex-VB developers. Using redirect allows for cleaner separation of input and output, thus it is better from conceptual standpoint of web resources and their presentation. Also, it is very RESTy.
    * MSIE and Mozilla do not add a page to session history if they are redirected to the same URL. That means that when you submit a form and it is invalid, you return to the same page with error messages. You submit it again, oops, errors. You decide to give up and go back, and you immediately see the preceding logical page. If you do not have redirection, then you unwind as many pages back as many times you mistaken on entry, looks very ugly if you ask me.
    * No need to check for double submit tokens, because resubmit can happen only if a user does this explicitly, and maybe he really means that.
    * To solve the double submit problem completely I suggest to serve responses as "no-cache, no-store" and to always synchronize view with server state. Thus, if a shopping cart was submitted, it would be removed from the server, so on clicking Back browser would try to reload shopping cart ("no-store", see?) and would not get any. So, the cart cannot be resubmitted, voila.

    Cons:
    * server stores more information per session. But as we know, processor speed may soon be in more demand than memory size.
    * If a user does not explicitly cancels a particular application mode, then server would keep objects related to that mode until session ends.
    * more service oriented than page oriented (I think this is actually a benefit, this is why I still use Struts).
    * Cannot reset an application or module by simply navigating to the same location without request parameters.
    * Requires network roundtrip (oh, come on).

    If you are not convinced, please try two simple CRUD applications that I created to promote Redirect-after-Post idea:
    This one is a forwarding application, and this one is a redirecting application. I am sorry, the second one has different HTML because nicer pages with explanations were lost after I updated the application. See yourself how the user experience is different. Try going back and forward, try to reload pages or to resubmit data. I think that benefits of redirect are so much outweight the drawbacks that it is *the* way to go. It is *the* approach that must be easily supported and promoted. Check Appfuse/Equinox sample apps, they blew up when I tried innocent "Delete item/view list/go back and delete same item again" sequence. All because they (1) use forwarding instead of redirection, and (2) allow browser to cache stale view which does not correspond to server state anymore.
  28. One of the small goodies I recently added to Shale was a small JSF component called Token, which basically does for JSF what transaction tokens do for Struts apps, but with a difference ... the actual check of the token is done in the validator for the Token component. That means the only developer gesture needed to enforce submit protection is to add this component nested inside any form that needs double submit protection (which is <strong>NOT</strong> all of them).It certainly makes sense for people describing JSF to talk about the double submit issue -- I would just quibble with your conclusion (in the article) that redirects are *the* solution. They are only *a* solution, and any discussion of the topic should discuss other options as well (along with their tradeoffs).
    Craig, thanks for joining. During last six months or so I was passionately promoting this [not as new as I initially thought] idea of separating input (usually submitted by POsT) from output (usually loaded by GET). Despite your position that this is just *a* solution, I believe that this is *the* solution, at least in terms of current HTTP 1.1 standard. Now I will try to convince you, please be impartial.

    Hey, you're both partially right. The right solution is *BOTH* a form token *AND* redirect after processing. The problems with just a token have been covered by Michael. The problem with just redirect is that the user can click the button more than once, even accidentally. Then you have a race condition for which one changes data first, or maybe they both do if you don't have good optimistic concurrency controls.

    On the Token control for JSF, Craig, what happens if the JSF page you're submitting the form to doesn't have the Token control? Do you have to put a Token control on every page? Can you have different namespaces of valid tokens so you can be working in 2 different parts of the application at once?
  29. The problem with just redirect is that the user can click the button more than once, even accidentally. Then you have a race condition for which one changes data first, or maybe they both do if you don't have good optimistic concurrency controls.
    * Data must be submitted using form controls, because they can be disabled dynamically.
    * After form is submitted, a small javascript immediately disables submit button.
    * If a client does not support javascript, the data is locked on the server, so another submit will either immediately bounce or will wait on thread monitor, and then fail on some data-relevant condition.

    Tokens make sense to solve implicit resubmit, caused by simple navigation back and forward when redirection is not used and when form is resubmitted by browser. In this case it is a web-layer problem being solved in the web layer.

    But if redirection is used, there is no implicit resubmit, so there are no issues in the web layer. Data may be resubmitted only explicitly, and the framework may have a clue is it a valid resubmit or not. This is why it should not prevent this resubmit and should deliver data straight to the Model. It is the Model who has to decide will it accept input data or not. And do not forget, that if you serve all pages as "no-store", they will not be cached on the browser. Thus, you cannot resubmit a stale page: if you go back, the resource (not the page!) will be accessed again from the server, and if its state is changed or business data corresponding to the resource is lost, then this resource will not be delivered to the client, so the client will not be able to resubmit the same data.

    I see use for tokens, but only as the last resort, when the crippled Model cannot correctly resolve data resubmission.
  30. * Data must be submitted using form controls, because they can be disabled dynamically.* After form is submitted, a small javascript immediately disables submit button.* If a client does not support javascript, the data is locked on the server, so another submit will either immediately bounce or will wait on thread monitor, and then fail on some data-relevant condition.

    See, this is much more complicated than using a token. I'm talking about one line of configuration and one JSP tag per form like this:

    <ww:token/>
    Tokens make sense to solve implicit resubmit, caused by simple navigation back and forward when redirection is not used and when form is resubmitted by browser. In this case it is a web-layer problem being solved in the web layer.But if redirection is used, there is no implicit resubmit, so there are no issues in the web layer. Data may be resubmitted only explicitly, and the framework may have a clue is it a valid resubmit or not.

    This is naive. People click buttons more than once. Your javascript won't always stop them. Why not handle it up front?
     This is why it should not prevent this resubmit and should deliver data straight to the Model. It is the Model who has to decide will it accept input data or not. And do not forget, that if you serve all pages as "no-store", they will not be cached on the browser. Thus, you cannot resubmit a stale page: if you go back, the resource (not the page!) will be accessed again from the server, and if its state is changed or business data corresponding to the resource is lost, then this resource will not be delivered to the client, so the client will not be able to resubmit the same data.I see use for tokens, but only as the last resort, when the crippled Model cannot correctly resolve data resubmission.

    See, my model is my domain model, which are POJOs mapped to the database by Hibernate. I don't want to clutter them with a bunch of presentation error handling code. XWork's interceptors allow me to encapsulate this into things like the TokenInterceptor and not have to deal with it in my model, which IMO, is not the right place for this responsibility.
  31. See, this is much more complicated than using a token. I'm talking about one line of configuration and one JSP tag per form like this:<ww:token/>
    And a user sees the POSTDATA window? Is it only me who cannot stand them? Ah, whatever.
    This is naive. People click buttons more than once. Your javascript won't always stop them. Why not handle it up front?
    Right, javascript is only a helper, this is why Model must be locked during update, as I stated.
    See, my model is my domain model, which are POJOs mapped to the database by Hibernate. I don't want to clutter them with a bunch of presentation error handling code. XWork's interceptors allow me to encapsulate this into things like the TokenInterceptor and not have to deal with it in my model, which IMO, is not the right place for this responsibility.
    I do not suggest to mix presentation with model, contrary I am against that. But what if your model is accessed via web service? What if your enterprise module is accessed by another application? What if you change web front end to thick Swing app? What if someone tried to access database directly? The token cannot help in any of these cases. That is why business data must be validated as close to the core as possible (imho). Or are you saying that data resubmit is impossible using web service or some API call?
  32. And a user sees the POSTDATA window? Is it only me who cannot stand them? Ah, whatever.
    But I didn't say you shouldn't use redirect, I said you should use both.
    I do not suggest to mix presentation with model, contrary I am against that. But what if your model is accessed via web service? What if your enterprise module is accessed by another application? What if you change web front end to thick Swing app? What if someone tried to access database directly? The token cannot help in any of these cases. That is why business data must be validated as close to the core as possible (imho). Or are you saying that data resubmit is impossible using web service or some API call?

    Well, I've got an XWork dispatcher to run my same Actions via XML/RPC. SOAP should be no problem. I've got a JMS dispatcher for XWork Actions. There's projects for using XWork behind Swing. But that's not really the point. The point is that what you're talking about is locking at the database, or pessimistic concurrency control. It doesn't scale. Go do a search for "optimistic concurrency strategies". I use a version column on my tables to let me catch concurrent modifications, and the first one gets in, all other fail to either be started over or try to re-do their work.
  33. The point is that what you're talking about is locking at the database, or pessimistic concurrency control. It doesn't scale. Go do a search for "optimistic concurrency strategies". I use a version column on my tables to let me catch concurrent modifications, and the first one gets in, all other fail to either be started over or try to re-do their work.
    No, I am not talking about pessimistic locking, it is not practical for most web apps. As a matter of fact I prefer optimistic myself. I was talking about locking the model the very time you are applying data from a client to the Model to prevent concurrent updates. Database, obviously, can handle it itself. Seems that we have a little misunderstanding here. Anyway, to conclude this, I just wanted to say that I prefer to do validatation as close to the model (or storage) as possible. Apparently, you prefer to put more functions in the UI layer.
  34. ASP.NET ("WebForms") and Windows Forms are both shipping today with .Net Framework 2.0.

    John Montgomery's blog post [1] attempts to position Windows Forms and WPF/XAML ("Avalon") as they are both .Net based frameworks that enable building Client software.

    To correct the comments in this page:
    ASP.NET is not getting replaced by WPF/XAML!

    ASP.NET enables developers to build great web solutions.

    WPF/XAML provides a great way to build Windows Applications, either as installed, always up-to-date applications, or as applications that run in the browser with no prompts for the user.

    WPF/XAML requires that users have Windows XP, Windows Server 2003 or Windows Vista. WPF/XAML will enable building very rich ui experiences. WPF/XAML will release when Windows Vista does.

    ASP.NET in conjunction with "Atlas" will enable great HTML based websites that take advantage of AJAX technologies.

    Hope that clears things up a bit.

    Thanks,
    Rob Relyea
    Microsoft
    WPF (Windows Presentation Foundation), Program Manager
    http://longhornblogs.com/rrelyea


    [1] http://blogs.msdn.com/johnmont/archive/2004/11/27/271026.aspx