Discussion

Ed Burns: So, presentation goals. I would like to show that the combination of AJAX and JSF, whatever vendor you are choosing, is a great way to go for building enterprise applications. I want to show one concrete way of using those two things together and some new content that I just added because I have given this presentation before is one concrete way of testing AJAX plus JSF applications, but as it turns out, this testing methodology that I am going to show does not apply just to JSF, it is any old AJAX application at all. Finally, I would like you to leave the presentation having some understanding of how to evaluate an AJAX plus JSF solution for yourself. We find ourselves in a similar position to what we were in before JSF was started in 2001, and that is at that time we had a lot of different web frameworks out there. They were competing for being the web framework of the day and the idea with JSF was to get the best ideas of all those frameworks and put them into the JCP standard. Now, as it turns out, we are six years down the line here and there are still a lot of other web frameworks out there, but JSF has gained and grown market traction both in terms of number of sites using it, in terms of vendors providing tools and components for it, and so with AJAX there are a lot of different vendors providing JSF and AJAX solutions. The panel discussion this afternoon at 2:30, we are going to have Steve Maryka from ICEsoft, and he has a very nice JSF and AJAX solution. I will be representing Sun, we have the one that I am going to talk about today, and there are a number of others, and I will list them on a slide, but anyhow I want to give you some knowledge so that you can look at these different solutions and say which one is right for me? What are the attributes that it has? Do they match to my requirements for my enterprise?

Now “Enterprise Grade,” that is a loaded term, so let me define what I mean by it- something that is robust, scalable, well tested, and industry proven. It has been around and it has been proven by deployed use. JSF has fit that bill because it is deployed in a lot of production sites and there is a lot of support for it as I mentioned. Another dimension of Enterprise Grade is that it has to be easy to use, easy to develop, and also easy to test. The importance of test-driven development is something that I really am fond of, and when I was leading the team that developed a reference implementation for JSF, we did everything with the test-driven development approach and that has been really valuable going forward. Also, the Enterprise Grade tools must be appropriate to the developer skill set you have. That plays to the hiring market. What kind of talent are you able to hire? Are they skilled enough to use this tool? Are there tools available that fit their skill set, and also the last point that I want to make is this: good concept scalability. As your problem space grows, you need to have sufficient abstractions so that your solutions that are addressing those problems can also grow, and JSF being a component-based solution with a lot of extension points, a lot of support for abstraction and componentization is good for that concept scalability. That is what I mean by Enterprise Grade.

What I mean by AJAX, I will just read it out here, in a web application using asynchronous transactions to the server to dynamically update the appearance and behavior of the view shown in the browser. This is a somewhat constrained definition of AJAX. If you talk to ICEsoft, they have this AJAX push thing which uses various techniques to send content from the browser asynchronously as well and there is this programming practice known as Comet, which also is very useful when combined with AJAX and I do not have any of that in these slides, but Comet is a technology to definitely watch, in combination with AJAX and also with JSF.

Okay. So, after the goals, this is our agenda. Why use JSF and AJAX together? Why I want to put up there my notion of web application musts? These are things you just have to have in the application regardless of using AJAX or not. Different approaches for using the two together. There is some content on the design heritage of JSF that makes it appropriate for doing AJAX development and also the features that make it appropriate, and then a survey of some problems and solutions.

One solution to those problems is at Project Dynamic Faces and MCP, which is a very early access, sort of alpha-grade technology that I have worked on at www.mozilla.org to do automated testing of AJAX applications, and I have a little demo of that, and there is a screen test on TheServerSide.com today that I just want you to know about it. Oh I see. Yeah there is an extra button. I did not know about that.

All web applications must have, this is just to be a member of the crowd you have to have these things. Motherhood and apple pie, you need to have data conversion and validation. You need to have a mechanism for specifying page flow. You need to have database integration. Also, you can put in that category a persistence story, preferably one that leverages off-the-shelf persistence technologies like JPA or Hibernate. You need to have the alphabet soup, internationalization, localization, and accessibility. This last one has been a thorn in the side of AJAX applications since they first started. AJAX naysayers were saying, ‘Oh well, you know, you will not be able to sell any AJAX application to the Government because of Section 508’, and there is a lot of truth to that, but be that as it may, web applications have to have accessibility. Even when you are authoring the pages, you need to support the lingua franca of web development, CSS and markup-based layout. It needs to be testable both at a unit and system and application level, and lastly user friendliness, all up and down the chain from the developer to the tester to the end user.

Now, different approaches for using JSF and AJAX together listed in order of decreasing complexity, and I have put the red traffic light signal, laser pointer needs a new battery, right there to indicate caution. These are pros and cons and the traffic red light says this is the con. So, the first way to do it is just Naked AJAX. You are going to do it all yourself. There is a book by Frank Zammetti that he coined the term Naked AJAX and that means you are not using any framework, you are writing it all yourself, and if you do this the pro is you will gain a very deep understanding of AJAX techniques. You will probably be so employable that you will be hired by someone, and if that is what you are looking for, great.

You also have to handle all of the XMLHttpRequest interactions yourself and that requires the basics of JavaScript closures, the SetTimeout function, a lot of arcana that most people do not want to deal with. Then you will have to handle the cross-browser quirks, which brings legendary pain to the web developers for years, and by the time you are done, you will end up writing a framework anyway.

The next level up, you can use a JavaScript framework, there are many of such things, Dojo, DWR, Prototype, which there is a talk being given today, might even be right now, but using those frameworks, you still have to handle the web app musts, and you have to if you are using one of those frameworks such as Dojo with JSF, you have got to write the intervening layer yourself.

Now, another level down the step, actually towards an easier-to-use solution is to use JSF with an AJAX extension project. As I mentioned, there are many. One of them I will talk about today is this Project Dynamic Faces, and with these solutions generally, you do not have to have any JavaScript knowledge to use it. They oftentimes hide the JavaScript programming for you so you can just use the solution and program to the regular JSF API and it does the AJAX for you. The Dynamic Faces version also allows you to…it exposes the JavaScript layer if you want to use it, so you can do more powerful stuff, and currently as far as I know, this is the only JSF plus AJAX solution that correctly handles what I call context sensitive AJAX component interaction because it takes advantage of JSF 1.2. We will see one of the demos where if you have tabular data, you want AJAX transactions to happen on an individual cell of that table and when you are doing those AJAX transactions, there is a whole bunch of state that is present when the page is rendering that must be restored in order for that cell to be modified because a data table really is just a window on a dataset and a data table is really a single row stamp that is repeated for the number of rows that you want to display, and that iteration context is only existing during the rendering phase, while you need to have some way when you are posting back if you want to update just this cell and just this row. You need to have the data table set itself so that the row is as expected and JSF 1.2 has some new features to enable that thanks to one of our expert group members, Jacob Hookom who is also the author of ‘Facelets’.

The red flag for the Dynamic Faces thing is, currently it is only implemented with JSF 1.2 because of that feature I just mentioned, and it is very immature. It is bundled in this new Sun Web Developer Pack, but it is still a 0.1 version and it is not as widely tested as the other AJAX solutions that are out there that you probably heard about at the conference.

The next level down in ease of development is using AJAX-enabled JSF components. With this one, it is a regular JSF component. The fact that it does AJAX is hidden from you. The component may have phase listeners or filters or other kinds of configuration schemes to handle the AJAX transactions, but you do not have to deal with it at all. There are some nice components available. There are quite a few that are available for JSF 1.1. Some are Open Source, some are for pay. There is a very good-sized market for that. There is a website, www.jsfcentral.com run by another expert group member Kito Mann that has a very good component gallery where you can go to find the state of the market for JSF components.

The downside is if you cannot find a JSF component off the shelf that does what you need, then you will have to write one for yourself and one option is to use this DynaFaces project.

So, the big question that comes up in my mind when I started to think about AJAX was, is this really different from any of the common web application UI practices, enough that it warrants a completely different approach for doing things. Well, in my opinion, no, it does not. This will come up in the panel discussion. There is the Dojo way where you have a lot of ViewLogic residing in the client and you are just making lightweight perhaps restful calls to the server-side and that is where your AJAX is, and then there is the GWT approach where you are compiling all your stuff, the JavaScript and it also runs in the client, and there is some kind of RMI-like mechanism to call back and forth through the server that is what GWT provides. So, that is one side of the fence. The other side is, you still are authoring your components using server-side markup, using server-side-based authoring tools and that markup is rendered in the server and then sent to the client at the rendered markup, and there is some UI state that is kept on the server in those solutions, and I still think there is a lot of currency to those approaches both in terms of the maturity of that approach, its widespread tool support, and also the maintainability. By keeping a lot of the UI logic on the server you gain, in my opinion, a leg up on maintainability.

So, one possible answer to that question is, JSF to provide the web app musts and then you provide some extra usage contract on top of it to enable AJAX support. This is what a JSF AJAX extension does, and here is a list of some of them: Dynamic Faces, ICEfaces, AJAX for JSF, which now is partnering with JBoss to be RichFaces. There is AJAX anywhere, BackBase. JackBe also has one. Anyhow, www.jsfmatrix.net is a website I found that has a comparison of these and other solutions. The good answer is we have the JCP process and all of these ideas, many of the principles of these technologies are on the JSF Expert Group and we are going to be kicking that effort off, cannot say too much about it now, but we have the expert group working on the proposals and that is what is happening there.

So, why combine these two from a design perspective? JSF has a heritage from Swing, and if you like that way of doing things, component-based object-oriented way of doing things, then you could say that the design of JSF was ready for AJAX before AJAX really started to take off. Some of the features that make an AJAX friendly is a well defined and an extensible UI component model, a well defined request processing life cycle, which I feel is something that is useful even outside of JSF, to be able to have a layer on top of servlet that manages the different phases of the life cycle of a WebRequest, something more than just request response. That is something that I think we are going to look at for JSF 2.0 enabling applications that use a more client-centric approach to still have requests that go through the JSF life cycle, perhaps without having JSF components present, but there is still the need for validation and conversion that sort of thing.

Another feature is the flexible and extensible rendering model. By having this rendering concept separate from the semantics of a component, you can handle having render kits that are rich for JavaScript-based applications and render kits that are not. They are more HTML 4.01 and they can just sort of hide the complexity and enable you to have different versions of your website by swapping in different render kits. Another concept is the encapsulation, the ability to hide JavaScript from the page author, but show it to the component author, and finally a lot of the machinery in JSF is around state management, making it easy and transparent to keep the client and server state in sync.

So, these are some of the typical problems, cross-browser differences, handle that by wrapping a JavaScript framework that already handles them, the localization and internationalization that works for JSF and AJAX just as it does for a JSF without AJAX. Shell remoting has a mechanism for doing script management and versioning, so you can have your JavaScripts that go along with your components be served up out of the class path in a secure manner. If you find that you are in a situation where you are having too much XMLHttpRequest traffic back and forth to the server then you can batch events with Dynamic Faces or look for the ability to batch events and send them all at once. Using XML as the data transport requires extra finesse for some common HTML elements. For example, the entities &nbsp that is an HTML entity. It is not an XML. So, I do not know if this...you can consider this a Mozilla bug or not, but if the XMLHttpRequest has a response XML that contains nbsp, the Mozilla browser, XML parser will crack. It will not work. It will say this is not a valid entity. So, you have to define that in some way and make sure that sort of thing is handled by your AJAX plus JSF solution.

These are just a few things to look for in a solution. So, here is what, in my opinion, is a very good application of those techniques. Brings the power of AJAX to existing and future JSF developed applications. We want to be able to AJAXify an application that was written already and we want to be able to build new applications that go further. It is based on this avatar idea again from Jacob Hookom and we demoed that with a Java 1. I would like to think that the Project Dynamic Faces has a small footprint developer usage contract. Essentially, there are two JSP tags you need to know about and two JavaScript function calls that you need to know about. With that small footprint, you gain a big increase in AJAX capability. So, here is the basic idea. Expose the JSF life cycle to the browser via AJAX and you want to allow operating on the entire view via AJAX or even just a part of it, updating just a single zone or component within that view over AJAX or just refreshing the whole page over AJAX. You want to allow some level of control over the life cycle via AJAX and you want to allow the server to change appearance and behavior in the current page bringing the concept to a dirty region, which is common to Swing or other native UI toolkit developers that notion of, okay, this is a dirty region of the page. It needs to be repainted, bringing that notion to a web application where you do not have to…you can just ask the server, “Okay, update the UI and send down only those elements that have changed due to some server-side event’.

So, the importance of the life cycle here, very simple, sequence diagram, you have the browser and the server, you make the initial request, comes back with the full page render and then you have a number of partial responses to that page, and the first one we are saying, ‘I want you to re-render the price panel and the options panel’, and then the response with just those two markup segments and then there is JavaScript in the client that knows how to do the DOM replacement or you could ask the server, ‘Just tell me what changed’, and it will send back whatever things have changed.

So, views and partial views: This is a little screen shot from the demo I am going to show. I have two zones in this application. One is the price panel and one is the options panel, and the UI component view of these things looks this. You have the price panel and the options panel, and each one has its own set of component children. To address that partial update used case, there are a number of different approaches. Again, I am listing them in increasing complexity. The page author can just use AJAX-enabled components or they can use this AJAX ZoneTag to AJAXify regions of the page. You basically put them around the markup you want to be AJAXified and then there are some attributes that you can specify if you want and then updates in that zone will happen over AJAX, and you can say, ‘Well, if I update this zone, I want these other two zones to update and so forth.’ There are ways of wiring up the zones in the page so that they know about each other.

From the component author’s perspective, if you are writing a JSF component, you can use this to provide a JavaScript library in your custom components rendering or you could even…this is a real advanced use case that writes your own JavaScript that talks directly to the HTTP protocol and the XML application defined by Dynamic Faces. That approach I think is pretty far out.

So, the zones: The easiest way to AJAXify an existing app demarcate the zones, and action in one zone will cause a reaction in another zone. So, let us take a look at that demo. So here it is. This is the very old, I think it really is the navigation toolbar, because they maybe put the resolution down to 1024/768, that is a little better. So, this is a localized JSF app and we just reload it to make sure my session has an expiry, and we are going to choose this roadster and here we have the options panel, and whenever we make a change to any of the components, there is an AJAX transaction that is happening to the server and I am asking it to recalculate the page. So, any of these components regardless of what kind of widget they are, when you interact with them they are going to make updates.

Okay. These are some code snippets of what that looks like. These are you define ‘your zone 1’, and ‘your zone 2’ and one of the optional attributes on AJAX zone is the action attribute. So, in this case the action there is essentially causing the zone to act like a button. So, the default is to click, whenever there is a click event for any of the components inside, it will act like a JSF button was pressed and it will call the update pricing action. If you have been following JSF for a long time, the sample app used to have a recalculate button, and what we have done here is show how you can take away the recalculate button and essentially this does the same thing as the recalculate. It is a pretty simple example, but I think it gets the point across.

These are some of the attributes, the action attribute. The inspect element is a function you can define that will be called and it will get passed in the element and you can tell return ‘true or false’ whether or not you want to AJAXify that. So, if you have a zone, but there is a little part in the middle or there is some kind of components in there that you do not want to AJAXify, you can write some JavaScript to do that. The event type tells you what kind of JavaScript event will cause the AJAX request to happen. By default, it is click, but you could have MouseHover, MouseUp, Blur or whatever, anyone you want.

The next level down is this fire AJAX transaction, JavaScript function. This is one of those three defined in that built-in JavaScript library and when called it will cause this AJAX transaction to the Faces server and it has many options for customizing the transaction. So, the demo here, which I am not going to show, I am going to show a different demo instead, has a data table and on the data table you have a regular old JSF command button and in the markup you have onclick=DynaFaces.fireAJAXtransaction(this, and that is all you need, and so when you click that button, this function will automatically return false preventing the form from being submitted normally and it will submit the form over AJAX and update the values accordingly.

There are live demos of this on the website, and I will show you at the end if you want to see it running. So, let us take a look at something, a similar demo to that. There is another Sun technology that is in the Sun Web Developer Pack called jMaki. Who here has heard of jMaki? Okay, good. The jMaki value proposition is it will wrap pretty much whatever JavaScript component library you have out there. There are bindings provided for Dojo and script.aculo.us, and the major ones Yahoo UI, and it exposes them as a JSP tag, and also exposes them as a JSF component, and that is kind of nice because it is essentially making a JSF component library of an arbitrary JavaScript library by wrapping it. So, I am going to show two examples here with that. This is a scrollable result set with that per so editing I was talking about. This is also available on the live demo. You can move back and forth and these scrolling through results that happen via AJAX, and then within each cell, using the script.aculo.us InPlaceEditor, then you can click on it and change things. Oops! I forgot my keyboard is set to devour access on those types of numbers, and then it updates it via AJAX.

So, let us take a look at the source of this, and I hope this works. Here we go. All right. So, this is a regular data table with a bunch of columns and in that the customer name column, this is the jMaki tag, ‘A: AJAX’. Now, it has a name attribute, which is kind of funny because normally in HTML name is used for name anchor or it is kind of similar to the ID attribute, but in jMaki, it means this is the name of the widget that I am using. So, from the script.aculo.us library use the InPlace widget and use this JSF EL expression, unified EL expression as the value of that thing. So, that is all that I needed to do. I need it to include the tag lib that is right there, to do that AJAXification.

Then the scrolling business, we have a panel group, which contains this Scroller. This is the BluePrint Scroller component. It has been around for a long time, and I have a script, a page scope script that executes and it is using a prototype library just as an incidental convenience, get all of the elements inside of this element that I have, a tag name=a, so give me all the hyperlinks and for each one call this,install a deferred AJAX transaction on it saying, ‘when MouseDown happens, fire the AJAX transaction and when you are done, call this post-replaced function that I have defined elsewhere in the script, and I want you to re-render just the table and the subview that contains the scroller because they both have changed’. So, these are again some of the options you can pass through the AJAX transaction. One that says, ‘I want you to execute the life cycle on these components’, one that says, ‘I want you to render the life cycle on these components’ and that set can be completely disjoint if you like. All right.

And this is what it looks like there. Pretty simple, and the general form is you have this. This is the JavaScript. It is actually the HTML DOM element for the markup. That is the actual JavaScript DOM element and options is an optional argument if present, it is a JavaScript associate of array containing any options that are desired for this transaction. So, these are some of the options there. Execute, as I said is this comma separated list of IDs to be traversed on the execute portion of JSF life cycle. Render is the same thing for the render portion of the life cycle. Inputs is the list of client IDs for which a value should be sent in the AJAX request if not specified. All the input components in the current form are submitted. So, that enables you to customize and prune what form values you are going to submit.

So, getting around to testing these things. The need for testing AJAX applications has been around for a while, and I first felt it really acutely when we were doing the development for Sun Web Developer Pack. When trying to concurrently develop jMaki, which Greg Murray was working on and Dynamic Faces, which I was working on, I had some samples that were showing the two things working together and it was very difficult to keep those samples running because jMaki was making continual changes and there was no automated regression test mechanism. So, I really needed that, and these were some of the requirements I thought such a solution should implement. It needs to be for us. It needs to be usable from the existing popular automated testing packages such as JUnit or TestNG. It needs to have a small and simple API, again in the spirit of JUnit. It needs to allow writing test to make assertions about the page content. It needs to allow writing test to make assertions about the AJAX transactions, and it needs to allow testing apps to make extensive use of JavaScript, that right there, that bullet point is the first one that you hit where really the existing solutions except for Selenium fall down. HTML unit and HTTP unit, which are two tests that fit the bill in some regard for these previous requirements, their JavaScript support at least in the versions that I have tested and used, fall down pretty rapidly when your application uses a lot of JavaScript.

Finally, the solution needs to run on all of the major platforms because this being the web, we have a wide range of deployment options for the server and for the client and we have to test all of that. So, that is tough. One solution is this Mozilla Control Program and it fits the bill for all of those things except for one and that one can be fixed with your help since it is Open Source. It currently works on Win 32. It is built on top of the Mozilla XUL Runner that corresponds to Firefox 1509 and there is a fair amount of native code involved, but all of that is built on top of XPCOM and the Netscape Portable Runtime library. So, the amount of platform-specific code to satisfy the final bullet on the previous page is actually pretty small. It is just a matter of getting some time or resources to do it.

What MCP does is, it exposes the Java API, but it wraps the native browser, and it is built on top of Web Client, which is kind of an older project that embeds Mozilla and it was intended to embed an arbitrary Java browser. At one time, it worked with Internet Explorer. It used the Internet Explorer ActiveX Control underneath this Java API, but a lot of that code has suffered bit-rot and has not been maintained, so right now it is just built on top of Firefox.

So, here is the demonstration of the MCP solution. You go over to NetBeans here. Is the font big enough for people to read in the back, to read the code? Yes, okay good. Okay, again, actually this is the project that we do not even need to open right now, close project. All right. Recent Web Client. All right.

So, I will just run the automated test first to see what it looks when you run it. Example sources. This is a test that goes through the card demo application, those steps that I showed you before on test card demo. So, it is just going to pop-up the browser window and because of the resolution, I have to scroll it around. Hope it works. I have not tested it at this resolution. Okay, so that is the test. The test passed. What did it do? We saw that it brought up a window without any chrome, that is the surrounding stuff around it. It stepped through the application and did a bunch of stuff. Well, let us take a look at the source for that test case. Test packages, card demo, card demo tests. All right. So, this is the a JUnit test. I will make this big so you can see what is going on. The binary distribution for Web Client has JUnit test case subclass called Web Client Test Case, but that is separate from the MCP, and in the setup method, we create a new instance of this thing. We need to tell it what is the browser bin directory. Given that this is native code there is JNI involved, and I am aware of the very excellent Java to XPCOM bridge done by Javier Pedemonte and used in the AJAX toolkit framework for doing their AJAX transaction support. Given that this code is based on the Web Client code that was written in 1999, it started out then way before the JavaXPCOM project existed, it has not migrated to that yet. In a future version, I would like to replace as much as possible of my JNI code with the usage of the JavaXPCOM bridge, but for now, in any case, you do need to tell the system where the browser bin directory is and you need to put that browser bin directory on your path so that the System.loadLibrary calls that load the native libraries can happen successfully. All this is done for you in terms of the built files that are in the distribution.

So, in the regular test card demo, we will go ahead and set a breakpoint and come back to this, and I will go run one file debug card demo test, I think this is the right one. Okay, so the breakpoint has been hit. Here we have this call stack, and I will make this large so you can see what is going on, lot of stuff to close here. All right. So, let us step over this line. You will see that the browser pops up. Then we have this BitSet. It is a final BitSet. I just use this as an easy way to have something that happens asynchronously such as AJAX transactions be tested after those transactions are completed. So, I just have this BitSet and then I flip the various bits from inside the Listener, and I have an enum for each of the different things I want to test. Did you get the end AJAX event? Did you get the map that has the metadata for the request? Do you have valid response text, valid response XML? Is your ReadyState valid? Stop waiting, you can see what that is. So, in the Listener here, the first thing we are doing is assert that we have an event map passed to us. So, there is this AJAX Listener interface that is part of MCP. It has methods called End AJAX, Start AJAX and Error AJAX, and those are called at the appropriate time for the AJAX transaction, and you are passed a map that has a bunch of entries. So, you want to see that the map is not null. You want to look at the response text element of the map, and because this is a white-box test necessarily so, you know what the XML response is going to be. So, you want to make some assertions about that. You can either do it via response text or you can also get the response XML as a DOM and you can make assertions about that as well, get the tag name, make sure that the tag name is as expected, make sure that it has the proper children that you are looking for. If you want you can even use XPath or whatever you have to query through the document. Then at the end, I have this other test to make sure that the ReadyState is as expected and now I flip this stop-waiting bit. It turns out there is a loop that is waiting for that bit to be flipped because this has happened on multiple threads.

All right, so let me go back and continue. I will show you the rest of the test case before we continue. All right, good. So, we have the MCP. We popped up the browser window. We add the AJAX Listener. We tell it to do a blocking load on this URL, which is the local URL running. Each element in the markup has an ID or a name as I mentioned earlier and those IDs are specific to the application. This is another thing that makes it a white-box test. So, this j_id thing here that is just a JSF artifact. It came from the fact that I did not give a name to a component. You can change that if you like. You can manually give a name or in JSF 1.2 you can say, form prependid=false and it will not prepend any IDs to the components that are inside the form.

So, what this does, it loads the page, it clicks the German language button. Because it is blocking click element, it will wait for the request to complete. Finally, all of the images and scripts and whatever is in the page will load and be done and then it will continue and then you can just really easily traverse the application that way. It has a find element method, so I want to find zone 1, and inside of zone 1 I want to call the DOM method on the price panel, get the text content, do some regular expression matching, say, okay before I take any action on the thing, the base price is 15/7, the current price is 15/7, then I am gong to clear the BitSet ahead of clicking this check box, again another white-box thing. I happen to know that clicking this check box, clicking this element rather is an AJAX transaction. It will cause an AJAX transaction to happen. So therefore, I do not want to do blocking because that is the whole point, but I do need to wait for the transaction to complete, so that is why I go into this sleep loop here waiting for the BitSet to be hit. So, when the AJAX Listener and AJAX is called to flip that bit, the test continues and then we test the assertions that were inside the BitSet and then I resample the price panel to see that it has changed after clicking the check box, and that would be the end of the test case. I delete the browser control. So, I will just set the next break point to here, near to all these, and then we will continue running. Click ‘Assertion’, okay, and then we hit the hand and we delete the browser control and we exit the test, and everything worked okay. So, that is the demo of that and that is currently like an alpha-level release. There is a screen test that I recorded that goes through this on the www.serverside.com site, it just went up. Thanks to Joseph and his team’s Herculean efforts. So, I want to go back to the slides.

All right, so we are finishing up the important links here. The Sun Web Developer Pack can be had. That is the runtime that these demos are running in from this URL. The Dynamic Faces Project, which is bundled in the pack if you want to go to their core website for the technology which has Javadocs and documentation for all the JavaScript functions that is there, and also live screen casts and slides. These slides will be on the presentation Wiki from the conference actually.

Project jMaki has its own Java.net project page. The BluePrints AJAX components that is one of the components libraries I mentioned and then the Mozilla Control Program there, you can see from www.mozilla.org. So, we have future directions here. The DynaFaces Project is Open Source under CDDL and the work that we are doing in this project as well as the other JSF AJAX-Extension efforts are being harvested for JSF 2.0 and that is actually not true. JSF 2.0 JSR has not yet been filed, but it will be very soon.

Here is our summary. There is 15 minutes to go, very good. JSF plus AJAX makes perfect sense. If anyone tries to tell to otherwise, question them at least. The questions you need to ask yourself about this, how steep is the learning curve? Does it fit my existing model of doing things? Do I need to know JavaScript to be productive? How easy is it to do partial page update? That is kind of the bread and butter of AJAX and JSF.

All right, so we have a lot of time for questions. Who has questions? Do we have microphones for the question people? Okay. Do we have any questions?

PRINTER FRIENDLY VERSION