David wrote both Graphic Java Swing and Core JavaServer Faces (with Cay Horstmann). Both of these were best sellers on Java component frameworks. Not only that, but he's fun to talk to and lives just south of me in Colorado.
Agenda: Ajaxian Faces Essentials, Roadmap, Form Completion, Realtime Validation, Ajaxian Components, Ajax with Shale and Prototype.
Enterprise Java and Ajax: you invoke a URL from the client (XHR), then handle the URL on the server. This handling is usually done by a servlet, filter or a JSF phase listener. These return HTML or XML to the client. Then the client merges the response into the DOM on the client.
JSF and Ajax: JSF is an excellent framework for Ajax. Why? Because of its component model: GET and POST requests are supported and it has custom components and renderers. Furthermore, JSF has lifecycle and event handlers - phase listeners and allows complete control over the lifecycle.
Common Ajaxian use cases: form completion, realtime validation, polling (progress indicators, realtime search, etc.), ajax components and frameworks. In this talk, we'll be covering JSF (POSTs and GETs), JSF and JavaScript, how to control the JSF lifecycle, JSF client ids vs. component ids, accessing view state, and many other things.
Arm yourself with tools: Firefox with the Web Developer Toolbar. Most helpful features: outlining block elements and DOM inspector. Debuggers on client and server: IDEA on the server, Venkman on the server.
Good Resources: Java EE Blueprints, Ajax Magazine and MSDN.
JSF and JavaScript: The HTML component tags have all the event handlers built-in: onclick, onblur, onfocus, etc.
<h:form id="form">
<h:inputText id="name"/>
...
</h:form>
In the above example, the component id is "name" and the client id is "form:name". To do minimal Ajax with JSF, you can use a non-Faces object to handle the Ajax requests with a servlet or filter. All you really need to know is how to reference client ids vs. the ids you code into your view templates.
Realtime validation: to do this, you need access to the view state. Ajax will fire a component's validators, invoke a phase listener (after the Restore View phase), POST a request with XHR and utilize client-side state handling. A typical component tree for a form consists of a UIViewRoot, an HtmlOuputText (instructions for form) an HtmlForm and an HtmlPanelGrid that contains all of the input components.
The JSF Lifecycle: Restore View -> Apply Request Values -> Process Validations -> Update Model -> Invoke Application -> Render Response. You have to do a post with JSF, otherwise the view state won't be available.
To register a phase listener, you merely declare it in your faces-config.xml file. There's a PhaseListener interface that defines 3 methods: getPhaseId(), beforePhase() and afterPhase(). In this example, getPhaseId() returns PhaseId.RESTORE_VIEW and beforePhase() isn't implemented; afterPhase() is used. David then checks for an "ajax" parameter. If it's sent in the request, he grabs the component to validate and invokes all its validators. One of the nice things about JSF is you can modify your client-side components on the server-side. You can also use JavaScript on the client-side to grab the hidden client-side state-saving field and send it with an Ajax request to maintain state.
JSF Ajax Components: To create JSF Ajax components, you'll want to put your JavaScript into a separate file. In the component's renderer, you'll write a <script> tag that uses a JSF page as its "src" element. Then you use a PhaseListener that looks for the URI invoked by "src" and handle it appropriately. Now David is showing us how you need to create a component, a Tag and a Renderer to create an Ajax component. The Tag and the Renderer write out JavaScript functions that do the magic stuff. Finally, you'll need to create a JavaScript file that contains the functions to be called. At this point, ragged on Geary a bit for creating a simple component with 3 Java classes + a .js file.
Rather than writing all this low-level JavaScript code yourself, you can simplify development with JSF and Ajax by using Struts Shale. Features of Shale include.
- Web flow
- Remote method calls
- Tiger extensions
- Integration with: Spring, Tiles, JNDI
- View controllers
- Testing framework
- HTML views (a.l.a. Tapestry and Facelets)
David gave a quick preview of Shale and showed how much easier it makes Ajax. Basically, you give a specialized URL on your client - and using a syntax of "dynamic/managedBeanName/method", it calls that method on the server. Pretty cool stuff, but doesn't seem a whole lot different from what DWR offers for JSF. "Shale is a proving ground for JSF 2.0, hopefully all its add-ons will make it into the next version of the spec." When David says stuff like this, I'm tempted to use Shale in AppFuse for its JSF support - especially since Shale can work with any JSF implementation (1.1 RI, MyFaces or 1.2 RI).
As usual, this was a good talk by David. He's always entertaining and fun to harass. 
There's a number of presentations I'd like to attend during this time slot. In particular, I'd like to attend Testing with Selenium and Simplified Ajax Development in Java with ICEfaces. However, Stuart Halloway is an excellent speaker and I'd rather hear him talk than learn something in another session. Hopefully other attendees blog about the aforementioned sessions so I can still learn something from them.
Agenda: Ajax, Libraries for Ajax (i.e. Prototype and Scriptaculous), Rails and Ruby.
There's probably 100 people in the room. Stuart did a survey of who is using Rails - I'd say the response was about 10%. He also asked who's considering it for future development. The response seemed to be around 25%. I'm sitting in the front of the room, so I probably didn't see the results as well as Stuart did. Regardless, it's interesting to see that most people in the room won't be using Rails, they're merely interested in it (or they wouldn't be in the room, right?).
The best way to play with Rails on Windows is called InstantRails. For OS X, there's Locomotive.
All the demos given during this session are available in the ajax_labs section at codecite.com.
Things we're going to look at: autocomplete, in-place Editing, searching, sorting, expando, drag and drop, sort, server-side validation, client-side validation, and prototype windows (Stuart prefers to call them divdows).
Stuart is talking a lot about how Rails works at this point, model objects, yml files, tests and sample data. One of the things that I find interesting about most CRUD-generation frameworks is they don't take tests into account. Ruby on Rails generates tests, so does AppFuse. If you work on a CRUD-generation project for web development, do you generate tests too? If not, don't be embarrassed, tell us. There has to be a good reason you're not doing this.
Now the audience is struggling with the concepts in Rails, how ActiveRecord works, etc. For example, one guy asked if it's possible to use JDBC with Rails. It's definitely a humorous question, but Stuart handled it quite well without ridiculing the guy. A couple of notes: Rails doesn't work well with stored procedures or composite keys.
Now we're looking at the view layer, in particular a show.rhtml template. It's pretty simple , but not very HTML-ish. Looks a lot like scriplets in JSPs. Autocomplete with Rails is mostly CSS-driven. To use it in a Rails view, you start with the following line of code at the top of your template.
<%= stylesheet_link_tag 'autocomplete' %>
In Rails, when you want to render an Ajax response in a controller, you use the following at the end of your method.
render :layout=>false
This turns off any page decoration. It'd be nice to have something like this in the Java world - so you could turn off page decoration from SiteMesh, Tiles, etc. It shouldn't be hard to implement this in SiteMesh, but it might take a bit of work for Tiles.
Partials are Rails' way of creating fragments that are designed to be populated and returned by Ajax calls. Their naming convention is to being the filenames with an underscore. For example <%= render :partial=>'search' %> looks for a _search.rhtml template.
For Ajax development with Rails, you're not tied to using Prototype or Scriptaculous. However, since Rails has helper methods that emit the JavaScript, it makes things much easier. If you'd like to use Dojo, you'd have to hand-code the JavaScript into your RHTML templates, or write helper methods for Dojo. Stuart would like to see a Rails plugin that allows you to switch the Ajax helpers from one library to the other.
The last thing Stuart showed was Prototype Windows. This looks similar to lightbox gone wild, except you get better styling around the modal window. If you haven't heard enough of what Stuart has to say, checkout blogs.relevancellc.com. One of the most interesting things lately is he's been posting reviews of the various Ajax books.
Max is the co-founder and Lean Runtime Architect for Laszlo Systems. Max doesn't look at all like I pictured him (do they ever?!). He looks like a heavy-duty engineer, long curly hair, a little rough around the edges. I respect him more already. ;-)
Laszlo Systems Background: company founded in 2000. Laszlo Presentation Server (LPS) released in 2002. Embraced open source; LPS became OpenLaszlo. 2005: it's been widely adopted (130,000 downloads to date). This year, they're extending OpenLaszlo to support multiple runtimes, including DHTML. The company makes money of training and support, as well as developing custom applications (i.e. Laszlo Mail) and modules.
On 2/1/2006, Laszlo Systems joined a select group of tech leaders in establishing the Open Ajax community. Jointly committed to "making it easier for an open source community to form and popularize Ajax."
Demo's: Laszlo Mail, Pandora, Barclay's and Gliffy.
Developing with OpenLaszlo:
XML-based, use your favorite XML editor. It's source-control friendly and has a library mechanism (for modularization). It's a familiar methodology for software engineers. It has standard OOP features: attributes and methods, class definitions with inheritance, familiar design patterns apply. There's an emphasis on declarative constructs. Finally, there's an open source Eclipse-based IDE4Laszlo. Originally developed by IBM, among the most popular downloads on alphaWorks. It now contains a WYSIWYG tool and is hosted at http://eclipse.org/laszlo.
LZX: Laszlo's XML Application Description Language:
Flash independent tags and APIs (no ActionScript, movieClips, etc.; no need for Flash development). This allowed them to easily port to a different runtime. With OpenLaszlo, you can interface with your server via XML over HTTP, SOAP, XML-RPC and Java RPC. It has a runtime constraint system, hierarchical data binding with XPath. It has media, streaming support (although the Flash runtime seems to load images real slow - see the DHTML vs. Flash demo on http://openlaszlo.org).
Now Max is going through the Laszlo in Ten Minutes tutorial. If you haven't seen this, you should definitely check it out. It's a good quick introduction to OpenLaszlo. One of the unique features of OpenLaszlo is its components are written in LXZ. Compare this to XUL (components written in C) and Flex (components written in Flash) and it seems a lot more open.
In order to solve the nested-for-loops problem with JavaScript and DOM-manipulation, OpenLaszlo uses XPath and turns for loops into simple URL-like expressions. For example:
<text datapath="dset:/employee/firstName/text()"/>
Noticed on Max's Firefox toolbar: a del.iciou.us menu.
For the last 1/2 hour, Max has been talking about LZX, how to handle events, etc. In other words, since I've already worked with OpenLaszlo a bit, I haven't learned anything new.
Now Max is talking about OOP and how you can declare classes with certain attributes and then re-use them. It's kinda like Spring's "abstract beans" where you can declare a template bean and override attributes in child beans. In addition to allowing classes to be declared with no parent, you can create classes that extend an existing class. A common usage is declaring default values and then overriding visual elements (i.e. border size, colors, etc.).
OpenLaszlo 4.0 (with Ajax support) is targeted for a release by the end of the year.
Personally, I think OpenLaszlo is a very cool technology. However, it definitely needs a better IDE IMO. The last time I tried IDE4Laszlo on my Mac, it wasn't even close to useable. From a development perspective, using OpenLaszlo was difficult to work with because I felt like such a moron. With HTML and CSS, I know how to program UIs and it's difficult to give up that knowledge and rely on something else to provide the look and feel of my UI. In reality, I'm simply frustrated with my OpenLaszlo skills and would likely feel different if I was paid to develop a real-world application with it. After all, getting paid to work with a particular technology is almost always the best way to learn it.
Max is a great speaker and did a good job of introducing OpenLaszlo. Furthermore, this was one of the most interactive sessions I've seen at this conference. There's definitely a lot of folks interested in this technology.
