Ajax Experience 2008 - More Ted, 'nuff said

I'll be giving three -- count 'em three -- presentations at the Ajax Experience at the end of September. Two talks are Struts-related reprisals form last year, and the third talk, new this year!, dives into popular tools for testing Ajax applications.

Hope to see you there!

Ajax Testing Tool Review

Not long ago, testing Ajax components meant play-testing a page by hand. Today, there are a growing number of tools we can use to simplify and automate Ajax testing.

In this session we will cover when to test, what to test and how to test Ajax components. You learn how to create automatic tests with various tools, including YUI Test, OpenQA Selenium and TIBCO Test Automation Kit, and how to use Ajax testing tools with IDEs and Continuous Integration systems.

In this session, you will learn:

Struts on Ajax: Retrofitting Struts with Ajax Taglibs

Struts is Java's most popular web framework. Ajax is the web's hottest user interface. What happens when we put Struts on Ajax?

In this session, we stir some Ajax wizardry into a conventional Struts application, without all the sweat and bother of writing our own JavaScript. Struts 1 and Struts 2 both support Ajax taglibs that look and feel just like ordinary JSP tags. If it's just a little bit of Ajax that you want, these tags will get you around the learning curve in record time.

During the session, we will cover

Who should attend: Struts developers who would like to utilize Ajax with existing applications, and Ajax developers who would like to utilize Struts as a backend.

To get the most from this session, some familiarity with Struts or a similar framework is helpful.

To register, visit Ajax Experience site.

Ajax on Struts: Coding an Ajax Application with Struts 2

Ajax is the web's hottest user interface. Struts is Java's most popular web framework. What happens when we put Ajax on Struts?

In this session, , we look at writing a new Struts 2 application from square one, using the Yahoo User Interface (YUI) Library on the front end, and Struts 2 on the backend. YUI provides the glitz and the glamour, and Struts 2 provides the dreary business logic, input validation, and text formatting.

During the session, we will cover

Who should attend: Ajax developers who would like to utilize Struts as a back-end, and Struts developers who would like to utilize Ajax as a front-end.

To get the most from this session, some familiarity with an Ajax library, like YUI or Dojo, is helpful.

Visit the Ajax Experience site to register.

Posted by TedHusted [Ajax] ( July 22, 2008 07:37 PM ) Permalink

YUI Version 2.2.2: Bug-Fix Release

Version 2.2.2 of the Yahoo! User Interface (YUI) Library is now available.

Usually this kind of update means downloading the new scripts, dropping them into your development folder, and ultimately updating the server. But since YUI is also serving the minified scripts from Yahoo! servers, downloading the release is optional, all you may have to do is replace references to "http://yui.yahooapis.com/2.2.0/" with a reference to "http://yui.yahooapis.com/2.2.2/".

Of course, any decent IDE will do the search and replace for you, so it's not any more work. We simply trade updating our local copies of the scripts with touching all the files that use the script. Since my team wasn't checking in the YUI scripts, it's actually less work, since only one of us has to do it once, and we don't have to touch the server at all.

One handy result of the trade-off is the potential for mixing and matching versions. The 2.2.2 release is suppose to be a bug-fix, though the beta (repeat beta) DataTable saw some significant internal changes. In fact, my DataForm widget can't use the new version (yet). But, no worries, I changed that reference back to 2.2.0 and its running, giving me breathing-space to sort out the problem. (Which I'm sure will be yet-another case of me pushing the envelope, and the envelope pushing back!)

Meanwhile ... the YUI release notes are helpful but high-level. That's not a bad thing, but if you are working closely with the library, and perhaps building your own widgets on top of YUI's, then it can also be helpful to have a line-by-line change log. Towards that end, I've checked in the last two YUI releases to the Yazaar project. Having the releases under SVN means that we can obtain DIFFs between versions, and review the line by line changes. To keep the YUI archive out of the way, I tucked it under the branches folder. (Gotta love Subversion!)

Of course, I'll be resolving my DataTable glitch today, and looking to see if Jenny Han Donnelly and company slipped in any new goodies.

Posted by TedHusted [Ajax] ( April 19, 2007 09:00 AM ) Permalink

Unobstrusive JavaScript Validation with YUI

A very cool approach to validation that plugs right into the YUI library.

I'm using this to provide validation to the DataForm Widget, which is a stepping stone toward the FLEV Widget.

Meanwhile, on the Java front:

Posted by TedHusted [Ajax] ( April 11, 2007 09:00 AM ) Permalink

Fortifying Ajax

Last month, Fortify Software posted a white paper describing a security exploit dubbed JavaScript Hijacking. Being a slow news month, a number of online journals trotted out "the end is near" headlines.

Of course, Ajax development groups have been quick to post responses to the "advisory". Despite the hyperbole, engines like Dojo, GWT, and YUI are not "vulnerable". Certain applications using Ajax engines may fit a "vulnerability profile", and if so, there are simple and concrete steps that developers can take.

If your Ajax application exposes sensitive data via raw JSON, do this:

Click. Done.

Like many security issues, the "vulnerability" is mainly a developer education issue.

The Dojo Toolkit is providing patches in version 0.4.3 "to inform developers of the potential risks their server-side components may be exposing them to and making it even easier to do the right thing on the client side".

The Yahoo! User Interface (YUI) Library is now adding a specific header to each request. The server side code looks for the header and refuses to service the request if the header is absent or not valid.

For more about security Ajax applications, see

Since many developers were not aware of this exploit, it is a Good Thing that a White Hat brought it to our attention before the Black Hats did. Though, I hope the next White Hat takes the high road and alerts the development group first. That way, we can have a response out the day the alert is posted, rather than a week or two later.

But, of course, if you happen to be a security consultant, a blindside brouhaha is not bad for business!

Posted by TedHusted [Ajax] ( April 10, 2007 09:00 AM ) Permalink

Ajax Smackdown: Dojo versus YUI!

Here's a description of a presentation scheduled for Tuesday, April 10, here in Rochester NY:

Since Jesse James Garrett coined the term Ajax in February 2005, the development landscape has exploded with Ajax frameworks, toolkits, and libraries. Although there are literally hundreds of libraries available today, two of the top contenders are the Dojo JavaScript Toolkit and the Yahoo! User Interface (YUI) Library.

On a recent Ajax spike, my team created the same example application in both Dojo and YUI. Let's compare the implementations, and see how the underlying Ajax products differ. Both Dojo and YUI are excellent products in their own way. But, which is the best fit for you, your application, and your organization?

Bio: Ted Husted is a software engineer and team mentor. His specialty is building agile web applications with open source products like Yahoo! User Interface Library, Struts, Spring, iBATIS, and MySQL, for either Java or Microsoft .NET, and helping others do the same.

Ted is a member of the Apache Software Foundation, an active member of the Apache Struts and Apache iBATIS projects, and co-founder of the Jakarta Commons. His books include JUnit in Action, Struts in Action, and Professional JSP Site Design. Ted has consulted with teams throughout the United States, including CitiGroup, Nationwide Insurance, and Pepsi Bottling Group. He is currently working with the Oklahoma State Department of Environmental Services to improve their permitting system.

* Meetings start at 6:00 pm and end around 8:00 pm & Meetings are held on the Third floor of the Golisano building, at RIT, room 70-3000 - CS conference room. * Directions to RIT can be found at [url=http://www.rjug.org]www.rjug.org[/url] * Members of RJUG are now entitled to discounts on O'Reilly books. Details will be available at the meeting.

Posted by TedHusted [Ajax] ( April 07, 2007 09:00 AM ) Permalink Comments [1]

Can you spell FLEV?

The most common workflow in any business application I've every written or used is Find / List / Edit / View -- or "FLEV".

At work, our last two point applications used this workflow over and over again, and the third will be no different. Often we start with Finding and Listing one entity, which is then used to Find and List related entities, which have related entities of their own to List and Edit. And, of course, we also need to Edit and View any of these entities along the way.

For example in a mail reader, the software starts by finding the new posts for us and presenting a list. We then view the thread, and maybe call an editor to post another article. When posting, we might want to find and list entries from our address book, and either select or likely suspect, or view his or her details, and maybe make some changes.

So on and so forth.

One would think that a FLEV widget would be standard fare in any widget library. But, strangely not. Looking about, I find several types of tables and grids, many with inline editing and filtering. But, in real life, inline editing and filtering via a grid isn't enough. We do need to rotate the axis and present a single entry on a form, often including fields not expressed on the grid.

Recently, I've been working with spanking-new DataTable from the Yahoo! User Interface (YUI) Library. Under the hood, DataTable use a RecordSet to represent the raw set of entries, and a ColumnSet to describe the schema for an entry (data type, editor, formatter, short label, long label).

All that's needed is a companion widget that can use the same Recordet and ColumnSet to present and edit one entry at a time.

Essentially, we're talking about a widget can present the same data in four different ways. To get started, I created an issue ticket that described the widget in terms of these four views.

I got a good start on FLEV this week, and we are about ready to drop it into our application. Of course, the widget will be available as open source under the BSD license as the first installment of the Yazaar project. Tomorrow is Struts 2 tip day, but I'll be blogging more about FLEV over the weekend, including how it uses the YUI LogReader as a development tool. Stay turned!

Posted by TedHusted [Ajax] ( April 05, 2007 09:00 AM ) Permalink | Comments [1]

Log Me, Log YUI

I've never been a logging enthusiast. Many of the frameworks I use put logging to good use, but it not something I've felt compelled to inject into my own applications.

Many coders use logging as a development aid. One of my earliest Turbo Pascal programs wrote a character to the menu bar as a "tell". As the application moved through a workflow, the tell would change. If it hung up, I knew where to start looking. It started as a development aid, but I left it in the production code because, well, it looked cool!

For most developers, our desire to log takes seed with a quick write to standard out, and blossoms as world-class products like Log4J, Log4Net, Log4PHP, and the other flowers in the Apache Logging bouquet.

Rather use loggers as a development aid, these days I tend to set a lot of breakpoints as I develop. I like to follow brother Steve McConnell's advice from Code Complete. Every time I write a new swatch of code, first, I set a breakpoint and watch it run.

Unsurprisingly, Joe Hewitt's brilliant FireBug plugin is one of my new best friends these days. Running a close second is the Yahoo! User Interface (YUI) Library's Logger.

Like other implementations, the YUI Logger works as a singleton, so it's very easy to write a logging message from anywhere in the application.

// Assigns default category "info" and default source "global" 
YAHOO.log("My log message"); 

As implied by the comment, we can add categories and source parameters to the method call, which are also standard fare for logging systems.

The trick with JavaScript logging is viewing the messages. Most of the Apache Logging bunch rely on logging to console or to a shared file for the application. Some browsers do support a JavaScript console window, but it's not a standard feature. For JavaScript, we need to shift the paradigm.

But it's not such a big shift. Since YUI is a widget library, it would make sense to express the Logger Control (or LogReader) as a widget. To view the messages as they are logged, just add the LogReader widget to an application, again with one whole line of code.

var myLogReader = new YAHOO.widget.LogReader(); 

By default, the LogReader widget plants itself in the top right corner of the browser window. If that arrangement doesn't work for you, the widget can also be attached to a div or dragged around the screen. If the window box still feels cluttered, there a builtin "Collapse" button. To be even more unobtrusive, you can add your own button to show or hide the widget.

An especially good use of logging in a JavaScript application is to document when events fire. Widgets raise primitive events like "click". A well-designed application will handle those events and raise an "idiomatic" event of its own. We can rely on the widget to raise its event, the interesting bit is when we raise our own.

Case in point, we're working on a DataForm widget that can share a RecordSet and ColumnSet with a YUI DataTable. The form widget raises "update" and "insert" events for the benefit of a client controller application. In early testing of the widget, we can't see those events happen, because they haven't been wired to a client yet. But, we can use a logger to view the events as they are raised.

oSelf.fireEvent("updateEvent",context);
oSelf.logRecordEvent("updateEvent", oRecord, oOldRecord); // debug

Where logRecordEvent is a helper method that expresses the oRecord and oOldRecord data in human-readable JSON.

We could also set breakpoints to check that the events fire, and the first time around, we still do. But, the logging statements are also a rudimentary unit test. In fact, the next step might be to create Selenium tests that look for logging statements on our example pages.

The YUI library distribution includes *-debug version of all the modules that include this kind of logging statement. The production version has the logging statement extracted. (Leaving a few strange lines of code behind, like empty else statements.)

Of course, there would be a few ways to filter production code for logging statements. I don't know what YUI does, but for my own projects, I might try an Aptana action to do the dirty work.

Though, since the LogReader can be flipped on and off, it's not hard to imagine leaving some statements embedded, for the sake of technical support. So, for now, we're marking the logging lines "// debug" in case we decide to leave some in later.

I may never love logging quite as much as Ceki, but the YUI LogReader is at least a friend with benefits!

Posted by TedHusted [Ajax] ( April 03, 2007 09:00 AM ) Permalink |

Aptana: Another brilliant IDEA

I've always been a die-hard IDEA fan. Jetbrains says "Develop with pleasure," and they mean it! Even with Eclipse and NetBeans nipping at their heels, Jetbrains has managed to stay ahead of the pack.

But, for Ajax applications, Aptana is poised to give Jetbrains a run for its money.

Being an Eclipse application, Aptana already has a huge headstart. The JavaScript editor is augmented with all the features you would expect: code assist on CSS, HTML, and JavaScript, FTP support, and a JavaScript debugger to troubleshoot your code. The Aptana IDE also includes features you might not expect, like being extensible via macros ad actions writtnen in (yes!) JavaScript. There's also a very cool outline perspective (which I wished I had found sooner!). (Hint: Dock the Project and Outline perspectives with FastView.)

For a quick tour of key features, scope the screenshots page.

Out of the box, Aptana is all about Ajax. For example, the project wizard will setup the Ajax libraries of your choice (or at least any of the top nine: AFLAX, Dojo, jQuery, MochKit, Prototype, Rico, Scriptaculous, YUI, and/or yui-ext). Being a good open source citizen, Aptana uses other OS products under the covers, including JS Lint and FireBug. A special bonus is that the project documentation includes a most excellent CSS/HTML/JavaScript reference useful to anyone developing AJax with any editor on any platform.

Quirks? There are a few. After three days, the debugging still isn't working for me. Just to be a tease, it did work once, and it worked brilliantly, but then stopped as suddenly as it started. With two monitors, Aptana and standalone FireBug work well together. (But standalone FireBug works well with anything!)

There is also an "Open Declaration" feature that works only sometimes for me too. But Aptana is young, and open source, and these things are sure to sort themselves out.

For straight-up Java/Ajax development, I expect that IDEA still has the edge. But, for anything else, IDEA's predilection for Java shows, and you're developing against the grain.

Although Aptana is based on Eclipse, and uses an embeded Jetty server for native debugging, it shows no favoritism to Java. Developers working in Ruby, PHP, C#, et cetera, are made to feel right at home.

In fact, a Ruby RAD environment seems to be an Aptana endgame. The RadRails IDE is being built over Aptana. Once Rails.net is ready for primetime, I expect that RadRails is going to draw me towards the light :)

I've only been using Aptana for a week. I haven't spent much time in the forum, and I'm still not sure of the project's motivation. The site mentions that Aptana is funded by venture capital, but I don't know what revenue stream is projected. I expect they could turn around and sell it, which is fine with me. People pay me, and I don't mind paying other people. Or, it may all be to promote a consulting business that will put the IDEs to good use. I really don't know yet.

But for the code I'm developing now, it's saving me time over using Visual Studio with Resharper. The code/test cycle is very quick, and I don't have to worry about running JS Lint. Aptana handles those types of syntax errors as we edit. I filed a ticket about improving the Resharper JavaScript support, but, evidentially, that's not going to happen any time soon. Resharper is focussed on C# 3.0 support, and JavaScript is on the back burner.

A key Aptana edge is that it's based on Eclipse, opening the door to other Eclipse plugins. There is a C# plugin for Eclipse, and between iterations, I'll have to give it a try. If the C# plugin works well enough, or we can make it so, we might be able to sideline Visual Studio all together.

I enjoy using VS with Resharper, but we often code against the Visual Studio grain. If Resharper is not going to improve JavaScript editing, I might finally be lured away from Jetbrains.

In the end, I think Aptana might just become the "Ajax IDE for the rest of us". :)

Posted by TedHusted [Ajax] ( March 31, 2007 09:00 AM ) Permalink

Hacking the Cathedral

A key reason we were able to use the Yahoo User Interface (YUI) Library is that the latest release includes a DataTable widget. Our application design uses lots of grids. Of course, there are grids from other toolkits and libraries that we could have used. But, honestly, we would have standardized on that toolkit instead.

Of course, the YUI DataTable is new and beta and not without its shortcomings. But, every time I found a flaw, I also cobbled a patch (and filed a ticket).

Looking at our design, what we do over and over again is Find, List, Edit, and View. The entity we want to Find/List/Edit/View changes, but the core workflow holds.

We did the last application module in ASP.NET. Most workflows were represented as pages that exposed one or more composite controls. Much of the page logic involved deciding which controls needed to be exposed.

For the YUI module, I'd like to have a single "chimera" widget that can reveal itself four or five different ways. As a Finder (QBE Dialog), as a Lister (DataGrid), as an Editor (Data Entry Form), as a Lister (View Only Panel), and as both a Lister and Finder in the same view. Behind the scense, the DataTable (Lister) is powered by ColumnSet and RecordSet objects, which could also power a Finder, Editor, and Viewer.

For now, I'm referring to this as a FLEV Widget, and I've started coding it through the Anvil site.

Meanwhile, another earnest YUI user posted a DataTable subclass that adds filtering on a column and hiding columns. Nice work, and a fine demonstrate of how easy it is to extend YUI widgets.

Since YUI doesn't accept contributions from the user community, I wonder if we should setup a community site on SourceForge or GoogleCode, where we could contribute and jointly maintain extensions like FLEV and RowFilterDataTable.

The idea would be that anyone with code to contribute would be welcome to join the site. Since widgets are granular, we could each retain our own copyrights to the original widgets, and just use the site as a one-stop shop for YUI extensions.

Of course, there is already a YUI-Ext project, but that has evolved into a distinct library that supports both YUI and JQuery, and I expect other libraries one day. And YUI Ext was never a full-throttle open source project, it was always Jack Slocum's baby.

The Yahoo! team has built a cathedral. Perhaps it's time to open a companion bazaar -- a yazaar! :)

Posted by TedHusted [Ajax] ( March 29, 2007 09:00 AM ) Permalink

Ajax: The usual suspects

Blogger Cheng Chun Kit seems to building a survey of Ajax Toolkits, Frameworks, and Libraries. He has a good start, with twenty detailed listings. Though, he still has miles to go, since Douglas Crockford believes that there are at least two hundred Ajax library available today. But, I think Cheng has at least covered the top contenders.

Of the top contenders, the top-top four libraries seem to be Prototype, script.aculo.us, Dojo, and Yahoo! User Interface (YUI) Library. Happily, it's not an election of remedies. If need be, it's possible to mix and match libraries on the same page.

For example, during our Ajax spike, we coded the same test application in Dojo and YUI. At one point, we had a mix of Dojo and YUI controls in the same application, and it all worked just fine. We even had the Dojo widgets going through YUI Connection Manager to talk to the server.

You can do the same kind of mash-ups with Java web frameworks too. There's nothing stopping us from having Tapestry answer some requests and Struts 2 answer some others. In fact, running Struts 1 and Struts 2 side-by-side is one of the recommended migration paths.

But, I digress ... Ajax widgets aside, there are a number of Ajax helpers that can work with any library. The DesignCreatology Ajax Tools roundup includes a few Ajax extensions, like Behavior and Event-Selectors. With Behaviour, you can add a JavaScript event to an element using a CSS selectors. Likewise, Event-Selector binds events to elements using CSS style syntax.

Two other nifty Ajax helpers are DWR (for Java) and Jayock for .NET). DWR stands for Direct Web Remoting. DWR allows code in a browser to use Java functions running on a web server just as if it was in the browser. On the .NET side, Jayrock is able to call into server-side methods using JSON as the wire format and JSON-RPC as the procedure invocation protocol.

With DWR or Jayrock, it starts to feel like we are working with a full JavaScript stack. We can call server-side methods as if they were JavaScript functions. Meanwhile, with the scripting support in Java 6, we could actually be calling server-side JavaScript methods!

Can you say convergence? ... I knew you could :)

Posted by TedHusted [Ajax] ( March 19, 2007 12:09 AM ) Permalink

But can Ajax make popcorn?

If you're a Struts developer dabbling with Ajax, the new Ajax tags in Struts 2 can make it easy to get started. Both Struts 1 and Struts 2 are excellent Ajax environments for Java web developers. A S1 action can return whatever text stream your Ajax widgets might need. For S2, pop in the JSON plugin, and, bingo, instant Ajax computability! Better yet, just fire up DWR.

If the Ajax bug bites, and you go beyond dabbling, it's likely that you will want to add an Ajax library to the mix. After peeking at the source for an Ajax library, it may begin to dawn that you don't know so much about JavaScript after all. YUI and Dojo are not the tinkertoy scripts we cut and paste into our markup for the odd special effect.

An excellent way for a Java developer to lean more about Ajax is the YUI Theater site. It's a virtual convention, featuring sessions with Douglas Crockford (JSON), Joe Hewitt (Firebug), and Chris Wilson (IE). You can't pop out a question, but you can pause the action, and view the material at your own pace.

For starters, I heartily recommend the "Browser Wars Episode II" clip. It's an absolute must-see for anyone doing web development, whether it be bleeding edge or trailing edge. You won't learn many stupid browser tricks, but you will get a look around the bend at what's happening with browser development

For frontline JavaScript development, Doug crockford's video trilogy is another must-see. For more about that, see my prior blog.

Featured this week is a brief but rich session with Gopal Venkatesan: "Writing Efficient JavaScript". Some of the material overlaps with the Crockford Clips, but there's are new goodies too. At 22 minutes, it's well worth the time.

Sadly, the slides aren't posted with the video clip, though I'm told that they will be posted eventually. [Evidentially, the laptop with the presentation and Venkaesanis are now in different zip codes :)] In the meantime, here's a set of summary bullets:

Next in line for me is Joe Hewitt's Firebug video. I truly enjoyed Firebug 1, but the latest version is so featureful, I feel a bit lost. Hopefully, Joe can machete me a path through the new interface.

Or, maybe I should just use Aptiva, which embeds Firebug into a very slick-looking Ajax IDE.

You know, sometimes, I do feel like the machine is us/ing us! Posted by TedHusted [Ajax] ( March 17, 2007 06:00 AM ) Permalink

Happy Trails to YUI

Dojo has cachet, but the Yahoo! User Interface (YUI) Library has got the goods. YUI is fast, well-designed, and well-documented. Yes, documented. Not just API docs, but tutorial-style documentation with honest-to-goodness examples.

Here's the catch: the YUI site is organized like an encyclopedia. Everything is in arbitrary, alphabetic order. Great for looking stuff up later. Bad for getting started now.

If you're ready for Ajax, but your JavaScript skills are not, first spend a quality day with the Crockford Clips, courtesy of YUI Theatre. It's just enough knowledge to make an object-orientated programmer dangerous.

Once you are over the OO JavaScript hurdle, the remaining challenge is ramping up with YUI itself.

To get started with YUI, I recommend reviewing the slide overview from XTech Developers Day, and and then following the "Happy Trails" through the documentation. If you take your time and try some of the exercises on your own machine, it could take a day or three to get through it all. (Though, if you're like me, about half-way through, you'll be off coding your own application, and leaving the rest for later!)

Read Me First

The Happy Trails

After browsing the XTech slides, I suggest reviewing the YUI documentation in a step-by-step order. I've divided the trail into three legs.

First Leg - YUI builds on several "backbone" packages that hold the library together.

Second Leg - The library provides several workhorse packages that manage and display data.

Home Stretch - Other library controls provides special effects, like sliders, buttons, and calendars, along with browser history management, and grid-based layouts.

The mass of YUI documentation can seem imposing at first, but if you break it down, and follow the trail, you'll be up and running in a New York minute. :)

Posted by TedHusted [Ajax] ( March 10, 2007 06:00 AM ) Permalink Comments [1]

View Me First: The Crockford Clips

Sure, "The JavaScript Programming Language" and "Advanced JavaScript" are dull titles, but the videos clips are anything but. Speaking with an insider's perspective, Yahoo! JavaScript Architect Douglas Crockford first explains why "Javascript is the world's most misunderstood language" and then steps quickly through the whys, wherefores, and howtos of the web's best friend. Crockford invented the notion of using JSON as an Ajax payload, and the videos reflect his innovative and pragmatic view of JavaScript as a strange but powerful programming language.

If you are just learning JavaScript, view these clips first. If you think you know JavaScript, view these clips now, and find out what the language really can do.

The "Crockford Clips" are from three live teaching sessions covering JavaScript, the DOM, and Advanced JavaScript. Viewing all three sets (in that order) is well worth the time, if only for Crockford's insider asides on the politics-err-process of language and browser development.

Some key takeaways from all three sessions:

Hint: Save yourself some pausing. Download the slides first, and click along on a second monitor or laptop. And before commenting on slide 63, read the other reviews :)

Posted by TedHusted [Ajax] ( March 06, 2007 06:00 AM ) Permalink | Comments [1]

Getting Started with Professional Ajax

Like most developers of a certain age, I'm a latecomer to Ajax. We've adopted it whole-heartedly for my current project, so I'll be passing along my own spin on the learning curve.

In the beginning, I snagged a copy of "Teach Yourself AJAX in 10 minutes", which is actually quite good. But the notion that you can do the "chapters" in 10 minutes is a bit far fetched. (Ditto for the "24-hour" books. Most chapters seem to take me 90 minutes to two hours. Maybe I'm slow.)

Last week, I stumbled on a PDF of the first edition of Ajax Professional. The second edition is hot-off-the-presses, but I haven't had a chance to pick it up yet.

In the first edition, I was hoping the example application (Chapter 9) would contrast conventional versus event-driven programming, but it seemed to spend more time with the routine guts of the application, rather than the interesting Ajax bits.

Chapter 1 lays a good foundation for Ajax development. Most of Chapter 2, we are handling with frameworks, but it does make one appreciate how much YUI/Dojo and Jayrock do for us, given that with Jayrock we are boiling the Ajax calls down to

   PhoneBook.rpc.entry_list(entryTableLoad).call(channel);

Chapter 3 describes several patterns, most or all of which will apply to my current project.

Another chapter provides a gentle introduction to JSON, though I think we have a handle on that now. Since JSON is the constant notation for JavaScript, I'm finding that it's also handy for creating test data. We could even create an mock RPC script for database-free testing (see Anvil Issue 16).

An excerpt from the second edition is online now. It's a section from Chapter 4, "Ajax Libraries" that covers the YUI Connection Manager. The second edition adds chapters on Ajax Libraries, Request Management, Mpas and Mashups, Ajax Debugging Tools, Ajax Frameworks (including Atlas), and a .NET case study. So, I'll probably have to get it.

Meanwhile, Douglas Crockford's Wrrrld Wide Web" site is a menagerie of groovy links. (Crockford being responsible for the notion of JSON and JSON-RPC.) I've only pursued a few, but I'm sure to be back.

JavaScript Lint is a "must-have". It saved me several minutes of debugging the first time I used it.

So as to not let the tools have all the fun, I ordered a copy of "JavaScript: The Definitive Guide" through the link on Crockford's site. (My pidgin JS is beginning to show!)

Speaking of tools, I wasn't thrilled with what HMTL Tidy does with the JS script elements. It wraps the script element but doesn't indent the closing tag, leaving the markup looking like a awkward hanging indent. Since our HTML files are heavy with script includes, I'd rather not use Tidy as a formatter. But, it still works well for validation. (As does The HTML Validator for FireFox.)

OTOH, I am thrilled to be back in a place where we can expect the pages to validate with HTML Tidy!

I'm sure Ajax will be another long strange trip, but at least the path is well-traveled. I'm looking forward to sharing the ride.

Posted by TedHusted [Ajax] ( March 05, 2007 06:00 AM ) Permalink |

Make Mine YUI

After two years of bashing our brains against ASP.NET at my day job, we're diving into Ajax for our next frontend.

We looked at Microsoft's AJAX.NET, and at Anthem, and GWT, and Dojo, and we settled on the Yahoo User Interface Library. Out of the box, the widgets aren't as sexy as some others, but the library is well documented, easy enough to use, and Yahoo seems committed to supporting YUI over the long haul. (I haven't run any benchmarks, but it also seems like its the fastest.)

Of course, I'm also liking that Yahoo eats their own dog food ... "the YUI you can download here is exactly the same YUI Library used all across Yahoo!".

Though, it's not YUI that's really making the move from ASPX to HTML-and-Ajax possible for us. The "reality check" kudos go to a .NET JSON-RPC libary named "Jayrock". Using Jayrock, we are able to create a paper-thin ASHX handler ("servlet") that calls our business logic framework (Anvil).

From a coding perspective, the handler is a "plain-old" C# class with some annotations to enable the JSON-RPC voodoo.

[JsonRpcMethod]
   public AppEntry entry(string key)
   {
      // ... arbitrary business logic to obtain a value object (JavaBean)
      return appEntry;
  }

On the JavaScript side, Jayrock bundles a utility script that generates the JSON API gluecode for us. In the end, we can just call a method on the handler and pass in our parameters and a callback function. Click. Done. Sweet.

  PhoneBook.rpc.entry(entry_key,onEdit_load).call(av_channel);

If anything does go sour, the handler can throw an exception, which, on the JavaScript side, is automatically routed to a separate error callback. Once there, it's trivial to display the message, and even the stack trace, if we want it.

Happily, we are already doing all the data conversion and formatting on the business logic layer, so for Ajax, we are good to go.

We did an initial "spike" using Dojo and our canonical example application (a simple PhoneBook). We then did the same thing with YUI. A keen happenstance was that we were able to use Jayrock to switch "channels" behind the scenes, so that the application could connect to the server using Dojo or using YUI, just by changing one line of code.

Along with the clear separation of concerns, I think what we like most about Ajax is that it plays well with others. We can start with YUI as a foundation, but if we want to toss in some Dojo or Ext widgets, we can. No sweat.

I'm thinking this feeling is what JetBrains means by "Develop with pleasure!" :)

Posted by TedHusted [Ajax] ( March 04, 2007 06:00 AM ) Permalink