Discussions

News: Alexander Jerusalem: Does JSF + AJAX really make sense?

  1. I can see how JSF/ASP.NET + AJAX makes sense for small lookup type operations like auto completion and, of course, for encapsulating purely client side operations such as column reordering and simple validations. But if AJAX really catches on, what it ultimately means is that the whole request processing life cycle, on which these frameworks are based, is obsolete.

    JSF and ASP.NET are based on the idea that the whole page (view state) is reconstituted as a server-side component tree on each request, before any event handling code is called (I'm skipping a few details here). Event handlers have access to all of the most current field values, which are already converted and validated. Also, event handlers can modify field values and the page structure itself, or they can redirect to another page.

    All of this is very different when XMLHttpRequest is used to call server-side code. The network is not transparent, the view state on the server is not available or at least not up-to-date, and server-side code cannot change the view directly. Redirects work very differently. For short, there is suddenly controller code on the client.

    The most problematic thing, in my view, is that the client side controller can even change the page structure. It can add controls that are not part of the server-side component tree. So, even if the HTML form is ultimately posted to the server (which need not be the case at all), the view state cannot be reconstituted properly.

    Another problem arises when database updates are done, bypassing the server-side controller, causing additional complexity later on when the server-side controller does it's own updates (probably via some backend "model" code).

    Now, predictably, the reaction of server-side framework designers will be to try to encapsulate all of the client side goings on and take care of all the issues I have outlined above (and probably many more). But I doubt that this is a workable solution. Already, quite powerful JavaScript libraries are popping up everywhere and people will want to use them.

    These libraries will not do things like letting the server-side framework know that they have just added a component that should really be mirrored in the component tree on the server. My fear is that client side features of web frameworks will be limited because the best available client side code cannot be reused and that conroller duplication causes a conceptual mess. In any case, web frameworks would become much more complex and error prone.

    I wonder if it would not be better to either use AJAX very sparingly so it doesn't interfere with existing request processing patterns, or move the controller entirely to the client and forget server-side web frameworks as we know them today.

    Threaded Messages (38)

  2. Thats not generally true. In all well known/popular AJAX frameworks, the idea is to let parts of a web-page make requests and get responses on their own. But all this does not bypass the Controller at all. In fact the XMLHttpRequest(s) will mostly look like 'www.myserver.com/SomeController?a=b', logically speaking. The urls could be masked to something like *.do, but the underlying request is targeted at the Controller.

    I agree with the view-state argument. There needs to be a way the client will notify the server that the component tree has been updated, and that too in the most minimal performance impacting way. Could a standard Javascript API emerge that will let users add a control on client-side thru some interfaces and the API will make sure the event is transmitted to the server and that the server-side component tree gets updated. Too far out may be, who knows!
  3. ...There needs to be a way the client will notify the server that the component tree has been updated..
    It's has to be other way around. If something happend on client, client has to call server and as result server will change his component tree. Then server has to inform client (some way) that component tree was changed and it has to be reflected on client. I guess this is feasible with JSF however not with JSP pages.
  4. ...There needs to be a way the client will notify the server that the component tree has been updated..
    It's has to be other way around. If something happend on client, client has to call server and as result server will change his component tree. Then server has to inform client (some way) that component tree was changed and it has to be reflected on client. I guess this is feasible with JSF however not with JSP pages.

    That will happen automatically with full tree processing on the server side and state-saving: server. With JSF 1.2, the EG standardized an field id for storing view-state on the client. So an AJAX request could be made, sending up the component tree state, and then the response would include the new state.

    -- Jacob (JSF EG)
  5. However to make it efficient we need:
    1. Not use JSP and process component tree directly on server in action. Container will "record" changes and send it to client.
    2. Use JSP and have something what will again compare old tree with new tree and propagate changes.

    Am I right?
    Is't here some better solution?

    TNX
  6. However to make it efficient we need:
    1. Not use JSP and process component tree directly on server in action. Container will "record" changes and send it to client.
    2. Use JSP and have something what will again compare old tree with new tree and propagate changes.
    Am I right?
    Is't here some better solution?
    TNX

    That's kind of the flow of JSF already. There are special ViewHandlers which will render the tree to DOM on the server and then secondly, push DOM changes down to the client.

    To be clearer, JSF restores the components (which might just be a couple of them) and then runs the update/validation/action process, then uses the restored components to re-build the complete tree and renders them back over the outputstream by default (or DOM as in the case above).

    I don't like the DOM solution since there's a lot of overhead in processing the rendering of a whole component model when you 'know' you only want a couple components to 'refresh' back in the client. The web is request/response based anyways, but there's a lot of opportunity to head into new directions.

    -- Jacob (JSF EG)
  7. DOM rendering is precisely the approach used by ICEfaces, which applies AJAX techniques to add asynchronous and incremental page update capabilities to JSF applications.

    The current JSF lifecycle does render the entire component tree for every request (rendering to DOM in the case of ICEfaces), but this is not necessary for DOM rendering. For instance, a component event handler could render the specific component, thereby just updating the DOM subtree associated with that component. Those DOM changes would then be propagated to the browser via AJAX as usual. (We have done testing with this configuration under ICEfaces and performance is very good; the problem is that it introduces a non-standard lifecyle.)

    Ted.
  8. Ted, you guys also use keep-alive processing right? So the request-cycle is really blurred?

    After your presentation at JavaOne, a lot of us from the EG had to pick our jaws up off the floor. I recommend people check out their demos over at ICEFaces.

    -- Jacob (JSF EG)
  9. Ted, you guys also use keep-alive processing right? So the request-cycle is really blurred?

    We actually decouple the request and the response (from the AJAX point of view) as this allows asynchronous updates to be done more naturally. A response always follows a request (if the page changes as a result of the request) but the application can also initiate a render() on the server at any time and update the page. It's necessary to keep the request alive to allow the server to update the page at any time. It's very easy to develop with since the JSF application is completely standard; the only addition is that server-side events can call one API method and initiate a render.

    Ted.
  10. ...There needs to be a way the client will notify the server that the component tree has been updated...
    It's has to be other way around. If something happend on client, client has to call server and as result server will change his component tree. Then server has to inform client (some way) that component tree was changed and it has to be reflected on client. I guess this is feasible with JSF however not with JSP pages.
  11. I have problem to submit new posts to forum. Am I alone?
  12. JSF + AJAX really makes sense. The reason we use AJAX is that we do not want to touch the whole page when we change some component in the page. In JSF, there is a solution: public void setImmediate(boolean immediate) from javax.faces.component.ActionSource. But this solution still sends the whole page back to the client. Using AJAX in JSF, the big problem is to keep state in client. If we keep state in the server side, we can always update the state when we make XMLHttpRequest call to the server and keep latest state in the server side. But if state is saved in the client, the thing becomes more complicate. One possible solution for this case is to make XMLHttpRequest synchronously.

    Welcome to take a loot to: AjaxFaces http://www.ajaxfaces.com/.
    AjaxFaces: General and Complete Integration Solution for JSF and Ajax
  13. oops: "take a look", not "loot"
  14. Check out this component from Coldtags suite:
    http://www.servletsuite.com/servlets/jscalltag.htm

    It works synchronously
  15. In a real component based framework where all state is kept on the server i see no problems. I have never worked with JSF though and cannot really judge about it. For what I know and have read I don't believe JSF is a real component based framework.
  16. Possible Solution?[ Go to top ]

    I have been working on a solution and have found that the way JSF handles component trees is more useful than one would initially presume.

    The issues you are describing come down to the fact that recursive processing is done on the root node of the component tree... that's it. Get around that, then you have a very robust AJAX controller where you can update/evaluate a single component in the request, while still retaining reference (server side) to the full non-transient bits of the component tree.

    Trust me, I made the same rant on Java.net last week, but then came up with a solution w/ a couple [simple] benchmarks in this next blog entry:

    http://weblogs.java.net/blog/jhook/archive/2005/09/jsf_avatar_vs_m_1.html

    The hard part is standardizing something client side, but it's really not necessary, since each component/bean could participate in that solution.

    -- Jacob (JSF EG)
  17. Possible Solution?[ Go to top ]

    Jacob, is it at all posible to work without a navigation xml in JSF? The components could then be responsible for hiding/showing themselves or other components. I ask this because i have a framework that works that way and i think of making it JSF compatible somehow.
  18. Possible Solution?[ Go to top ]

    Jacob, is it at all posible to work without a navigation xml in JSF? The components could then be responsible for hiding/showing themselves or other components. I ask this because i have a framework that works that way and i think of making it JSF compatible somehow.

    Of course, in JSF, actions may return null, which means refresh this page. Also, with custom components, you can invoke any method via Method[Binding/Expressions] back on your model in an async request for RPC-like behavior.

    -- Jacob (JSF EG)
  19. Possible Solution?[ Go to top ]

    thanks for the answer and the good news! Now I wonder what xml is mandatory anyway in JSF, i hope none whatsoever.
    which means refresh this page

    Since i don't think in pages anymore i don't really understand what this means. Normally i manipulate the application tree and the renderer renders the whole application. I guess this is what you mean?
  20. Possible Solution?[ Go to top ]

    thanks for the answer and the good news! Now I wonder what xml is mandatory anyway in JSF, i hope none whatsoever.

    XML isn't manditory, you can manipulate the component tree in straight Java:

    <blockqoute>HtmlInputText input = new HtmlInputText();
    facesContext.getRoot().getChildren().add(input);
    Since i don't think in pages anymore i don't really understand what this means. Normally i manipulate the application tree and the renderer renders the whole application. I guess this is what you mean?

    Yeah, basically. Just the fact that for 'full' page posts, JSF already has built-in 'refresh everything' capabilities. So a solution that would allow partial refreshes for AJAX requests would be nice.
  21. Possible Solution?[ Go to top ]

    So a solution that would allow partial refreshes for AJAX requests would be nice.

    I would say crucial;-) for me at least when i want my current solution to work with JSF.

    All of my components extend from a basecomponent (hmm offcourse they do). They have this property called dynamic. I can say setDynamic() to any component on the server. When a user clicks on that component an ajax request is made to the server. After the event is handled the requesthandler checks if the component that belongs to the event is dynamic, if so then that component should also have a receiver component (or more than one). That receiver component ONLY will be rendered and send back to the client, whereafter it will dynamically replace itself on the client by means of DHTML. This way I can update anything i like on the client without a single line of client side code. I hope you understand what i am trying to say. Does your saying that "it would be nice" implies that it is currently not possible. Is there maybe a workaround if it is not possible in a standarized way?
  22. Possible Solution?[ Go to top ]

    Does your saying that "it would be nice" implies that it is currently not possible. Is there maybe a workaround if it is not possible in a standarized way?

    It's obviously do-able, the ICEFaces folks have done it and so has Oracle ADF. But JSF opens up a large horizontal market for black-box component development, much like the portal spec. That horizontal-market has to have some common features in place for delivering rich functionality and for AJAX, it doesn't exist in the specification at the moment. So we have a bunch of really smart vendors coming up with unique ways to handle the AJAX issue-- now, I the developer, can't really piggy back either of their solutions without being locked in.

    Moving forward Dennis, there would have to be some spec changes to accomodate partial tree handling at the very least. Since components are black-boxes, it's hard for a JSF participant to efficiently assert alternate processing behavior in the big picture of a request lifecycle. So really, you have to go back to the UIComponent API and possible the ViewHandler to accomodate partial trees across the board without uprooting or locking everything that was done before with JSF.

    -- Jacob (JSF-EG)
  23. Possible Solution?[ Go to top ]

    So a solution that would allow partial refreshes for AJAX requests would be nice.
    I would say crucial;-) for me at least when i want my current solution to work with JSF.

    Take a look at AjaxAnywhere.sourceforge.net
    Looks like it does exactly whet you need.
  24. Possible Solution?[ Go to top ]

    Take a look at AjaxAnywhere.sourceforge.netLooks like it does exactly whet you need.

    I checked it out, it looks like something that might be usefull in existing projects. I cannot really use it for my own thing because I already have build me a framework without markup that I want to be JSF compatible. I'am looking for a way to (re)render a single component in the JSF tree without traversing the whole thing.
  25. a[ Go to top ]

    a
  26. Two kinds of applications[ Go to top ]

    As I see it, AJAX can be used in two kinds of applications:

    1) Page-based applications: A traditional web application that flows from one page to the next. You would use a traditional web framework like JSF. Some Ajaxian enhancement like auto-complete and drop-down population make sense here, put it would not be a "pure" Ajax solution.

    2) JavaScript clients: The "rich client" approach, like web mail or google maps. This resembles pre-web client-server applications; the bulk of your UI logic is client-side, and the server is relegated to data management and transactional operations. Traditional web frameworks like Struts and JSF are largely useless here. More likely you would use a client-side JavaScript framework like Dojo or Prototype together with some web-services like framework like SOAP or JSON on the server-side.

    Personally, I see a role for both kinds of applications moving forward.
  27. Two kinds of applications[ Go to top ]

    Paul, I somewhat disagree with you here.

    Take a rich UI application framework like Macromedia Flex, where the whole document is in one page. It uses the concept of components, just like swing, to render some stuff to the screen and provide UI controls. JSF has the same capability, but lacks in the ability to handle partial requests to interact with the server-side part of the component tree. Once that's solved, you can drop a Map component (as was demonstrated at JavaOne) onto the page that is fully navigatable and is able to do tiny, specific component control interactions back with the initial document delcaration.

    In the much bigger picture, developers like Roger Kitain (Sun) and Jonas Jacobi (Oracle) have done things with rich clients and XUL (the same platform as Firefox/Mozilla is written in). Now combine XUL (desktop-looking) apps, delivered from your web browser, with partial component processing and you have yourself a very rich framework. Could JSF be lightened up a bit? Of course, but in progress, it would lose a lot of its uniqe capabilities.

    -- Jacob (JSF EG)
  28. Ajax here to stay[ Go to top ]

    I author points out some interesting things on how ajax can complicate the personality of existing page based frameworks with how controls and state is managed.

    Web UI rameworks will need to choose how they embrass ajax. Some will likely make superficial use of it while other may choose to embed it into the core of the framework.

    Take the echo framework as an example. The original framework was a page based now it has been rewritten from the ground up to take full advantage of ajax and browser side DOM manipulation of the content. So there is no longer the concept of pages anymore. Everything is part of the DOM. All client server interactions only manipulate the DOM not at the page level. This has made echo2 very powerful framework for building web "applications". AJAX has made the server side processing much more nimble by only sending changes to the browser when an event/action occurs, thus avoiding full page refreshes unless necessary. Check it out if interested:

    echo.sourceforge.net
  29. Ajax here to stay[ Go to top ]

    indeed, ajax feels so much better from a user perspective. The only thing we can ask ourselves is why now, why not 5 years earlier. It has always been possible.
  30. Ajax here to stay[ Go to top ]

    indeed, ajax feels so much better from a user perspective. The only thing we can ask ourselves is why now, why not 5 years earlier. It has always been possible.

    It all comes down the the scroll bar. People make pages longer than they did before. If everyone made pages that sat in a pop-up window and didn't need scrolling, than most browsers already handle delta-only rendering for a very desktop-feel.

    ;-)
  31. Another solution[ Go to top ]

    Good point.
    AjaxAnywhere project (announced on TTS the same day as this article) would probably appear interesting in this context. It corresponds to the author’s suggestions and addresses the same problem - to preserve existing request processing patterns.

    Despite this project is not purely JSF, the demo of MyFaces Example enhanced with AjaxAnywhere is available on the homepage. ajaxanywhere.sourceforge.net
  32. Third application class[ Go to top ]

    As I see it, AJAX can be used in two kinds of applications:1) Page-based applications 2) JavaScript clients

    I would like to point out third class of applications: Serverside component frameworks that mirror their state on client automatically using AJAX. Currently echo2 is the best example of this, but others are also coming. The most important advantage is that all programming can be done with Java: no time-consuming JavaScript debugging or knowledge on browser differences is required.

    Generally frameworks are either page-centric or "swing-like". Millstone framework implements interesting hynrid model, where the same application can be presented using Web-pages as well as "continuously updated" rendering model. Currently Millstone only provides Web Apdapter (page centric) rendering model, but upcoming Ajax Adapter provides full support for transparently mirroring all component updates from server to client and all events from client to server. Without any page updates. Interesting thing is that the same application can support both models without any code changes. Also the performance is excellent: it feels more like a client-srrver application than web-application.
  33. Third application class[ Go to top ]

    That's where I want JSF to go, where it can automatically handle all of that by setting up pre-conditions in the JSF tag markup in the JSP/Facelet page. There will always be opportunity for guys like ICEFaces though to push more unique solutions that extend the client-server relationship into directions beyond the reach of JSF specification, but something should be in place.

    -- Jacob
  34. Supporing non-ajax browsers is also an important consideration when building complex Ajax solutions. Here is an example on how this is done in Millstone

    Example on multiple rendering models:

    Source code of a trivial application (just few rows)

    Deployed with Web Adapter

    Deployed with Ajax Adapter prototype (outdated, firefox only)

    Deployed with Swing Adapter prototype (outdated, webstart)

    So, one serverside application. written in Java, can be seen with multiple terminals. Without any terminal specific programming. Of course in real world, some terminal specific knowledge is needed for layouting, but in Web and Ajax adapters that can be done with any HTML editor.
  35. It is interesting how a trendy technology can affect beliefs and patterns. Since early days of web development it was a good practice to use request-scoped data whenever possible, even if one needed the same data for the next request. Request scope was good, session scope was bad because large session caused excessive memory consumption and replication issues. People were inventing tons of techniques to make applications work with request-scoped data, from hidden fields to transaction tokens to browser-based viewstate.

    Turns out, request scope does not work well with composite ajaxified page. When page is normally updated in small portions, what do you do when a user hits "Reload"? Ooopsie, all your output data is gone and server does not know a thing about it.

    This is how Ajax finally forces developers to embrace stateful application and to realize that storing complete state on the server is the only way to recreate user interface when a user clicks "Reload" button.

    This discussion suggests that ajaxified applications can get tremendously complex. Nah, not really. As long as server keeps application state, and client does not create new controls or reformats the page without server knowing about it, there is absolutely no problem with Ajax. With each Ajax call the server state should be updated in the same manner as with regular call. The only difference is that client is not repainted as a whole. If a user refreshes a page, browser gets a full page from server, which reflects current application state.

    I know WM_PAINT message when I see it.
  36. I'm all with Micheal here. I loath the fact that for sake of scalability we've gone from OO programming back to procedural programming by seperating function and data in our 'service oriented architectures'. As if making all our layers 'stateless' is the only way to acchieve scalability. The web tier is no exception to this. For the sake of REST, we twist ourselves in impossible curves and make developing webapplications quite improductive. Or we serialize whole component trees and send it to our clients, regardless the fact that that's expensive in terms of bandwith and processor time.

    So, yes, ajax and component based frameworks are an excellent match because components are statefull. Exactly for the reasons Micheal gave. And a page-oriented development mode is still usefull as:
    * you want to degrade gracefully
    * pages are the end result anyway
    * it's quicker to work page-oriented and 'enhance' them by either putting in the ajax stuff later, or - like the components that are starting to pop up in Wicket - mix in ajax components without having to know they are ajaxian.
  37. JSF , on my things, VERY good solution for building AJAX applications.
    I have worked library ( see demo at http://smirnov.org.ru/myfaces-ajax/ajax.jsf ) based on simple idea:
    1) In JSF, we have component tree on server side. It rendered as HTML and send to client.
    2) On client side, HTML parsed to DOM tree.
    3) After submitting, input element's data send to server, apply to component tree, update tree and send rendered HTML to client ... And again...
    For non page navigation ( i'm beleeve, for this case we can send full page ) Ajax Library perform normal submit, but, on server side, rendered ONLY changed components. Client side part update affected nodes in dom tree, based on response information. As result, we have two-way communication between DOM and JSF Component's trees, what keep it same.
    Created with maximal JSF specifications support - since, work with any JSF realisations ( MyFaces, Sun RI, ADF ... )
    P.S. For non XMLHttpRequest browser support, data send as dinamic JavaScript :-)
  38. I wonder if it would not be better to either use AJAX very sparingly so it doesn't interfere with existing request processing patterns, or move the controller entirely to the client and forget server-side web frameworks as we know them today.

    If one fully embraces AJAX, then one need merely implement message driven beans on the server-side where the server-side is now 100% pure SOA.

    With an AJAX app the server-side need no longer be in the business of dynamically generating UI or processing user interactions with the UI, etc. The whole notion of server-side MVC web frameworks becomes rendered obsolete.

    This is really a good thing because what has made developing web applications so complex and bloated is all the MVC web framework non-sense going on over on the server-side. A pure SOA business logic middle-tier is not only a more flexible and longer lived architecture style, it is also an order of magnitude easier to develop than the MVC web framework stuff.

    Plus one as more options - the client side can be DHTML/JavaScript/XmlHttpRequest, or it can be a superior Java Swing app using something akin to JMS. The same message-driven SOA middle-tier can now easily support either or both style of client-side application.
  39. If one fully embraces AJAX, then one need merely implement message driven beans on the server-side where the server-side is now 100% pure SOA. A pure SOA business logic middle-tier is not only a more flexible and longer lived architecture style, it is also an order of magnitude easier to develop than the MVC web framework stuff.Plus one as more options - the client side can be DHTML/JavaScript/XmlHttpRequest, or it can be a superior Java Swing app using something akin to JMS. The same message-driven SOA middle-tier can now easily support either or both style of client-side application.

    First, there's more than web MVC frameworks. Some other frameworks /do/ make life easier.

    So everything has to be SOA now, right? For some things a SOA approach is good. Relatively simple (interface wise) non-/ light conversational services for instance. Stuff like iTunes. For a lot of things SAO-only isn't the answer though. You don't allways want to design your system as a bunch of procedural methods. You probably will need component interaction too. You might want to degrade gracefully (yes, there are people out there using old browsers of having javascript turned off by their maintenance departements). And JMS? Does that mean you propose to map a mostly synchroneous model (the user interface), to a asynchronous model (JMS)?

    At some point in time web browsers will evolve into something that allows for a better programming model. Until that time please don't give me your 'take technology X and apply that to every possible problem in the industry'. It's okay to have several approaches. Programmers are supposed to be integelligent, creative people, not monkies that learn one trick only.