Discussions

News: Book Excerpt: Building AJAX JSF Components

  1. Book Excerpt: Building AJAX JSF Components (12 messages)

    This chapter excerpt, taken from JavaServer Faces: The Complete Reference, covers the fundamentals of AJAX APIs and builds on creating custom JSF components by showing how to bring AJAX practices to component development. This chapter also reviews two AJAX JSF component examples, and offers some tips and tricks for developing an AJAXian Faces component.
    As you will see later in this chapter, employing AJAX-only practices by hand is very tricky and error prone, and can be very frustrating for Web developers or page authors. It's particularly difficult dealing with browser quirks to achieve a solution that will run for as many users as possible. For example, the very way in which you obtain a reference to an XMLHttpRequest object differs across different browsers, even though the API is the same once you have it. The powerful encapsulation mechanism offered by the Faces componenet and event model is ideally suited to allow a component developer to provide AJAX-enabled (or AJAXian) components that are no more difficult to use than any other normal Faces component.
    What are your experiences working with AJAX and JSF?

    Threaded Messages (12)

  2. I use ajax4jsf it enables Ajax functionality for standard JSF components without writing a single line of javascript code.
  3. ugly code in JSF components[ Go to top ]

    This comment is not specifically on this book, but JSF overall. Writing custom JSF Components the "standard way" reminds me of the old days servlet (no JSP yet). Lots of embedded html and javascript code inside java code. See page 260-262 of this book. Still looking for good frameworks and tools to help develop custom JSF components. Ajax4JSF and its subproject Ajax4GWT is a decent start, but still have alot of effort needs to be done.
  4. Re: ugly code in JSF components[ Go to top ]

    This comment is not specifically on this book, but JSF overall. Writing custom JSF Components the "standard way" reminds me of the old days servlet (no JSP yet). Lots of embedded html and javascript code inside java code. See page 260-262 of this book. Still looking for good frameworks and tools to help develop custom JSF components. Ajax4JSF and its subproject Ajax4GWT is a decent start, but still have alot of effort needs to be done.
    There's no reason you have to use ResponseWriter. You're more than welcome to use some sort of templating system, even if it's a text/html file in the class path that you read in and do a bunch of String.replaceAll() calls on. The examples likely don't go into that so as not to confuse too much. Personally, I do a mix of templating and ResponseWriter. Jason Lee, SCJP JavaServer Faces Reference Implementation Dev Team http://blogs.steeplesoft.com
  5. Re: ugly code in JSF components[ Go to top ]

    There's no reason you have to use ResponseWriter. You're more than welcome to use some sort of templating system, even if it's a text/html file in the class path that you read in and do a bunch of String.replaceAll() calls on.
    Just to add to that, I know of several cases where people have implemented the rendering portion of a component using Velocity. One case in point is the current version of the eXo platform. It's trivial to delegate to a template engine from the JSF component class. That being said, I think JSF 2.0 should make it easier to use a template language (a la Facelets) for stateful components. (You can already get a mileage with Facelets for stateless components/compositions). Kito D. Mann Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
  6. Re: ugly code in JSF components[ Go to top ]

    Yes I know, we can use velocity or other templating framework to make custom jsf component development better. But isn't this in a similar situation as writing EJBs (1.0, 2.0), yeah we can use xDoclet to make life a little better.
    That being said, I think JSF 2.0 should make it easier to use a template language (a la Facelets) for stateful components. (You can already get a mileage with Facelets for stateless components/compositions).
    totally agree.
  7. templating vs. ResponseWriter[ Go to top ]

    When we started to implement our component library, just after couple of weeks we realized that using pure ResponseWriter for rich component development was a dead end. So, we implemented the template system based on the velocity engine. The template was interpreted in run-time. The Exadel Visual Component Platform 1.0 was build using this technique. However, the syntax of such templates looked pretty proprietary and we had a concern about performance as soon as it was a run-time. With releasing Ajax4jsf we introduced the new templating mechanism where templates used JSP-like syntax and were compiled into the java code during the code-generation. The generated code is a classical JSF renderers that use ResponseWriter. So, using this approach we have the advantages of the both parts - using templatess for design and development and using compiled java code in run-time. The mentioned technology is a part of Ajax4jsf and named Component Development Kit (CDK). We use it for out internal development and it really boost the development. -- Sergey : http://ajax4jsf.dev.java.net
  8. Re: ugly code in JSF components[ Go to top ]

    That being said, I think JSF 2.0 should make it easier to use a template language (a la Facelets) for stateful components. (You can already get a mileage with Facelets for stateless components/compositions)
    With ICEfaces we commonly recommend the facelets approach because new ajax components can be created as compositions purely from the JSF standard components (no ICEfaces-specific work, other than adding the .jar file, is required). Ted Goddard http://jroller.com/page/tedgoddard
  9. Re: ugly code in JSF components[ Go to top ]

    There's no reason you have to use ResponseWriter. You're more than welcome to use some sort of templating system, even if it's a text/html file in the class path that you read in and do a bunch of String.replaceAll() calls on. The examples likely don't go into that so as not to confuse too much. Personally, I do a mix of templating and ResponseWriter.
    Although I will agree that using ResponseWriter is a "should" rather than a "must", think for a minute about how your components might be used. Do you want them to work in the context of a development tool? Especially one like Sun Java Studio Creator, that is focused on visual drag-and-drop development? If so, think for a second about what such a tool needs in order to provide a high quality design time experience for YOUR components. When the user clicks on the visual representation of your component on the design surface, what does the user expect? Naturally, they expect the component that rendered that visualization to be selected, and its properties exposed for modification in a property sheet of some sort. Now, how does the tool know which component (which might be part of an arbitrarily complex tree of components such as a table or a tree) to select, when you click on a particular point in the visual representation? You've got it ... based on the fact that the renderer for your components is careful to pay attention to the third argument to the startElement() method on ResponseWriter. If you don't care about tooling support for your components, feel free to ignore this advice -- although it is perfectly feasible for non-programmatic template based solutions to obey it. But, you need to know that ignoring this API is going to reduce the potential user base for your components to *only* those that don't want to use graphical based design tools to build applications using those components. It would be a shame for component developers to ignore this reality.
    Jason Lee, SCJP
    JavaServer Faces Reference Implementation Dev Team
    http://blogs.steeplesoft.com
    I may be a bit out of touch with the JSF RI development process since I moved over to be architect for Sun Java Studio Creator, but could you please help me understand the reality of your claim to be on the "Reference Implementation Dev Team"? Craig McClanahan
  10. Re: ugly code in JSF components[ Go to top ]

    As soon as the first comments mentioned Ajax4jsf and, I guess, G4jsf, I would like to put in my two cents here. I suggest the both approaches make sense. Further more, there are not only two of them. All depends of the motivation why you need a new functionality. If you are the component developer and your business is building a rich faces component library, the classic approach make sense without a doubt. You can create the components that have build-in Ajax behavior and this allows others to use them without having a deal with bunch on Javascript and extra work to wire the "standard" components together. If you are the end developer and your business is developing web applications for your customer, using page-wide Ajax support like Ajax4jsf make sense. Yes, actually, you can try to create components first and then use them, however, how our practice says the lifecycle for creating components, especially if we speak about rich components, is much longer than required. Creating the component vs. the same functionality as a part of the project, you have a little bit different motivation. The component presumes using it elsewhere. So, you try to generalize the behaviours to make it possible to use elsewhere. In case of particular project, you already know that you need to have and what you do not. So, there is no reason for generalization, if customer does not want to pay for what he/she does not want to have. Third approach is using compositions. Facelets allows to create components based on the composition of another components. So, you can incorporate an Ajax functionality into the composition using Ajax4jsf and then using this composition in the same manner like you have a real component. I suggest it is an ideal solution if you do not find a suitable third party component, but want to reuse some functionality along the project or/and even along the several projects. Sergey Smirnov : https://ajax4jsf.dev.java.net
  11. Re: ugly code in JSF components[ Go to top ]

    This comment is not specifically on this book, but JSF overall. Writing custom JSF Components the "standard way" reminds me of the old days servlet (no JSP yet). Lots of embedded html and javascript code inside java code. See page 260-262 of this book. Still looking for good frameworks and tools to help develop custom JSF components. Ajax4JSF and its subproject Ajax4GWT is a decent start, but still have alot of effort needs to be done.
    If you are developing a custom component, you could use Xkins to extract the HTML and javascript code from java and put in a template, and also add skinning capabilities. See http://xkins.sourceforge.net for more information. Also there is Xkins Faces, a plain implementation of this concept, but it has too few Renderers (I have not time to implement more:( ). In fact, they are decorators of other renderers, just "wraps" the original renderer and add html to create different looks and feels, and the HTML is externalized to the template, which can be Velocity Templates, Groovy, or any other custom templating language (an Xkins extension) Regards, Guillermo Meyer
  12. I begun my first real live JSF job just 3 months ago and i had to do some ajax stuff right away. I came to the conclussion that ajax can be shoehorned into it but is not a natural fit, at least not whith the current state of the API. JSF can be all that but it needs more focus on java instead of templates. I guess that will never happen. Why can i not construct components with an API, in that case neither responsewriter or templates are needed. But no there is not even a simple addChild method wich can be called from outside the component. And when i perform getChildren i only get the static stuff. It might be all possible what i want but it is so damn non-intuitive that i cannot find my way. Positive thing about JSF is that it is a lot better than good old struts. Finally no more struts at work, great!
  13. btw h:panelgrid seems nice and compact at first glance but ends up being a big PITA when nested, dunno whats going on anymore, must look at html source to figure out bweeeh!!!