Pierce T. Wetter III
Myth: Rails is a better framework for Ajax than WO.
Reality: WebObjects is actually a better framework for use with Ajax libraries than Rails because it has a better component system than Rails. You spend a lot of time coding little tiny XML and HTML generators when doing Ajax and WO's component system makes that very DRY (Don't Repeat Yourself).
Myth: WebObjects is hard to use with Ajax.
Reality: WebObjects is easy to use with Ajax, it's just that there is only one known library for Ajax-WO support, and its not well documented. Even then the library only goes so far in that it just provides new components to wrap a few script.aculo.us tags. I think its more of a documentation gap, not a code gap.
Additionally, the WO documentation has always pushed people erroneously towards component actions and away from direct actions. If you use 90% direct actions like I do in my application, (See my "WebObjects on Rails" post), you'll find that direct actions are simple to code in reality, and very much like Rails which basically doesn't have component actions at all.
Which is to say, if you avoid much of the power of WO, and don't use component actions, ajax will be easier. If you do use component actions - and I have yet to work on a project that doesn't - then ajax use seems like it will blow your page cache, as described below. So it really is easy to use AJAX in WO. Really easy. It's just that it doesn't work.
[mschrag: While I agree with the above commenter that component actions provide a huge amount of power in WO, it is NOT true that Ajax and component actions are incompatible. Project Wonder's Ajax components directly addresses the use of component actions with Ajax in a way that does NOT blow the page cache. While it is true that the implementation of these capabilities inside of Wonder was non-trivial, it demonstrates that it is, in fact, possible, and if you use the PW components along with ERXSession, you will get this capability for free.]
Myth: You can't assign the name or id value of tags in WebObjects.
Myth: WebObjects generates HTML
Since someone invented that cool acronym though, that's changing. You would think it shouldn't matter that something has a name, but it does. I remember when the GoF Design Patterns book came out. There was nothing in there I hadn't figured out on my own, but now they had a name! I could say "Singleton" to my co-workers and they would know what I was talking about. I could buy a junior engineer the book, and he would soon be programming at a much higher level.
Which means I can make the site much easier to use and more interactive. Huzzah!
So the first thing I did was that I'd heard that Rails was cool and made Ajax easy. I'd heard that before, but that was when the version number was 0.13... So I went out and bought the Rails books and you know what I found?
Ok, so lets break it down. The way Ajax.Updater works from the Prototype library is you give it the id of a DOM object and a URL, and it replaces the DOM object with that id with the contents of the URL. Usually, you specify the area to update with a div tag which I've shown for completeness. For ratings I would need 1 div tag to enclose all 5 rating stars: <div><a></a><a></a><a></a><a></a><a></a></div>. I would also use a WOGenericContainer to generate the div tag with the right id rather than using the id='<WEBOBJECT name=postingID></WEBBOBJECT>' line, but I wanted it to be obvious it was div tag.
So the Ajaxy part is the <a> tag, not the div tag.
It does something very simple: It pulls the HTML from the specified URL, and replaces the element with the specified id with the downloaded HTML.
The two WebObjects tags specify the element ID and the link, they're just a WOString and a WOActionURL:
Now in my case, I'm a direct action snob. So my WOActionURL would look like the following:
This produces a result similar to Rails, because in rails you have to define an action for each class of link. In my case I tie directactions to pages/components, so my "PostingRater" page would return component-level HTML (minus any HEAD/BODY tags) that matched the existing <div> definition. Since we're using WebObjects, that turns out to be trivially easy if we build the enclosing <div> tag with a component PostingRater can just look like:
Using component actions, it could be even simpler:
Because WebObjects, unlike Rails can have stateful components, the RatingDiv component could actually have all the logic and return self as the result of the action:
So where Rails has one line, I have two WOTags, but those could (and should) be easily combined by creating a WODynamicElement to generate the link directly. In essence, it would be pretty easy to create a "RemoteLink" WODynamicElement that did everything the Rails "link_to_remote" call did, namely take an id to update along with all the options WOActionURL takes.
But additionally the WebObjects solution is superior in a number of ways to the Rails solution. Rails has support for both "partial pages" and "components" but the reality is that components are pretty heavyweight/slow and partials don't quite do what you think. So the WebObjects solution, by wrapping both the logic and state into a component ends up being more DRY (Don't Repeat Yourself) and better encapsulated than the typical Rails solution. In the page where you want the Ajax bit, you specify the component, and you put the ajax handling logic in the component itself.
I have yet to see anything in the Rails Ajax support that couldn't be just as easily done in WO via a combination of WOComponents and WODynamicElements. Pretty much everything in the Rail "Ajax support" are one-liners in Prototype. In fact, because pages/components can have state, its probably easier to do it in WO than in other systems. Also, I think you could build a set of WOComponents that provided superior Ajax support than Rails. It's just that no one has written the supporting WODynamicElements or WOComponents.
The whole "Dialog" thing in yui is cool:
And would lend itself quite readily to the model WO has of building pages out of pieces.
Then again, dojo is only at version 0.3. The WYSIWYG editor is nice, but I really don't want to have to define my dialog boxes in yet another tag language. HTML is good enough for me.
So exactly what problems are you having with dojo/wo? Consider that the problem may be dojo, not WO in particular. You could easily create a WODynamicElement for every new dojo tag, collect them in components, and have something much easier to use than straight dojo.