Ajax applications can contain much more client-side code than a standard web application, and hence benefit much more from the order that patterns and refactoring bring. Chapter 4 of Manning's Ajax in Action is the first of three chapters that apply refactoring and patterns to the client-side codebase. You won't see much of the asynchronous requests that give Ajax its name in this chapter, but the style of programming that we're discussing here is a direct consequence of being able to make asynchronous requests.

This chapter is about structuring Ajax applications. It provides examples of how the well-established Model-View-Controller pattern can be used to provide that structure. This first installment of Chapter 4 covers the display aspects of the application, and shows how normal JavaScript code can be refactored into a robust view component.

Check out Chapter 4, Part 1

Thank you, Joe and Manning.

It will be interesting to review this book before it goes out to press. AJAX is a new technology (or being newly used with this new name, whatever!) - no book can be complete without reaching out to >many< real people working on real projects.

Public reviews were started on TSS by Ed Roman. His "Mastering EJB" got more famous that way.

Joe, can you request Manning for a public review of this book?

It was thin (dumb) clients in 70's(mainframe), then the thick clients in 80's to late 90's (c++, VB, powerbuilder) and then the thin browsers in 90's till date and now back to thick browser clients with ajax :)

Sometimes I feel we are doomed to re-impliment 3270/5250 protocol forever...

Applets, Swing, Java Web Start - I guess it's just too hard for some people to master.

I mean look at IBM, they had to develop SWT because Swing was too hard to learn, and of course we all know that the performance of Swing is disasterous ;-)

swing isn't too hard, and gives a much better look-n-feel than the web controls provide. the major problem is if the user can run swing applications from their browser.

from what i hear, there are version of windows released that may not even have java capabilities from ie. and i also hear that many (all?) windows version have only legacy java capabilities (awt).

out of the box swing is not available on the most common operating system deployed to the desktop. thus, if your target audience is at all outside of your technical support's control, you can fairly safely assume the user has modern IE 5.x+, and has javascript/cookies turned on.

would/has sun given microsoft the rights to deploy sun's jvm on their desktop? what java is expected to ship with vista? it would be interesting to see the comparision of number of users who have flash installed compared to those who can run swing applets in the browser.

you can fairly safely assume the user has modern IE 5.x+

Ahem. I wouldn't say that IE 5 is all that modern -- the state of the art has moved along quite a bit since 1998, after all. I mean, it doesn't even do tabbed browsing, a feature I've been using in one form or fashion for six years or so.

Hopefully, MS will do some innovating (or at least catching-up) with IE7. We shall see.

-Patrick

--
Patrick Linskey
http://solarmetric.com

opefully, MS will do some innovating (or at least catching-up) with IE7. We shall see.

Like maybe remove it? :)

Honestly (as I have speculated in the past), I can see them "dumbing down" the traditional browser aspect of IE (ie. removing JavaScript support) due to all the viruses, etc making it just an html viewer - And replacing it with their own, better, safer technology (some sort of XHTML) that integrates better with Windows. This all will provide a better user and developer experience. ;)

opefully, MS will do some innovating (or at least catching-up) with IE7. We shall see.

Like maybe remove it? :)Honestly (as I have speculated in the past), I can see them "dumbing down" the traditional browser aspect of IE (ie. removing JavaScript support) due to all the viruses, etc making it just an html viewer - And replacing it with their own, better, safer technology (some sort of XHTML) that integrates better with Windows. This all will provide a better user and developer experience. ;)

Just saw this - http://www.crn.com/sections/breakingnews/dailyarchives.jhtml?articleId=170101800

Yes it is! Swing is too hard, too confusing.

But people that master it don't see any problem with it (thus it will stay like it is forever).

Great power, good performance they say.
That doesn't help people like me who think swing is too hard but have no problem understanding the simpler model which is css+dom+javascript.

Relativly few people write swing code. It doesn't matter how good Swing is if it is too hard.

css+dom+javascript is not the panacea. The browsers are not the panacea because of varying support of different things on different browser (not WORA).

I'm just waiting for the next thing that will take the best of all.

Applets, Swing, Java Web Start - I guess it's just too hard for some people to master.I mean look at IBM, they had to develop SWT because Swing was too hard to learn, and of course we all know that the performance of Swing is disasterous ;-)

The problem with thick Java clients, even deployed through Web Start, is that a JVM must be (usually manually) installed to each and every client machine before any of the Web Start magic can happen. This can be a big, big, pain in an enterprise. Throwing in different Web Started applications requiring different JVM versions, you have some ready-to-serve nightmare. To avoid the nightmare, enterprise architects have been taking the obvious alternate - keep the client thin, i.e., in a browser.

Well now we have AJAX - or more accurately, we have most major browsers allowing AJAX in a compatible way. We don't necessarily have to stick to the thin client approach any more. After all, the usability with thin clients simply sucks.

P.S., I don't think IBM invented SWT because Swing was hard to learn, but rather because of Swing's disastrous performance _back then_.

The problem with thick Java clients, even deployed through Web Start, is that a JVM must be (usually manually) installed to each and every client machine before any of the Web Start magic can happen. This can be a big, big, pain in an enterprise. Throwing in different Web Started applications requiring different JVM versions, you have some ready-to-serve nightmare.

I guess you could substitute "Browser" for "JVM", and make the same arguments. FYI, you can deliver a JRE with JWS, and in an Enterprise, and install a compliant JRE with an Applet. There's also this concept of backwards-compatibility that for the most part exists in Swing.

Like I sarcastically pointed out in my original post, it's "too hard" - for people to switch paradigms.

I don't think IBM invented SWT because Swing was hard to learn, but rather because of Swing's disastrous performance _back then_.

One could speculate about a NIH mindset at IBM, but as I recall IBM had a jdk1.1.8 compatible GUI development library that <conjecture>probably served as the basis for SWT</conjecture>.

AJAX is pushing HTML to the limits, and not starting to scratch the surface of what a Swing client can achieve.

I guess you could substitute "Browser" for "JVM", and make the same arguments.

Of course not. How about this - I give you one buck for each computer still in use that does not have any browser installed, and you give me one buck for each one that doesn't have any JVM installed?

FYI, you can deliver a JRE with JWS, and in an Enterprise, and install a compliant JRE with an Applet.

If you are referring to the download link generation, it's not exactly the same as "deliver a JRE with JWS". The auto-install part is close, but officially it only works in Windows. You can probably work around to do it in an applet, but then the user would still have to accept the scary perspective of letting a web page initiating a local software installation.

Like I sarcastically pointed out in my original post, it's "too hard" - for people to switch paradigms.
...
AJAX is pushing HTML to the limits, and not starting to scratch the surface of what a Swing client can achieve.

Don't get me wrong. I just got off from a Swing project, and am working on one that still involves Swing. So this isn't a religious war. Nobody is saying AJAX can do what Swing does. It's all about trade-offs and the right tool for the right user.

Then add a few Smart Clients and maybe a few Rich ones,in fact I want to be a Smart Rich Client :-)

Seriously, is the effort to support and maintain this level of code in the client going to be worth the effort to develop. I accept that Google Maps etc is doing a great job at extending the browser. DHTML and CSS was always designed to do this stuff even back in the late 90's. Apps with a lot of usage can justify the effort to make them perform. Not so sure the apps for the smaller user base will and can afford the developer skills needed to build them.We need to be working towards simplication will AJAX do this ?

Matt Perrins
IBM

Seriously, is the effort to support and maintain this level of code in the client going to be worth the effort to develop. I accept that Google Maps etc is doing a great job at extending the browser. DHTML and CSS was always designed to do this stuff even back in the late 90's. ... Not so sure the apps for the smaller user base will and can afford the developer skills needed to build them.We need to be working towards simplication will AJAX do this ?

This is where third-party/opensource tools can fill the gap and provide 'easy to use' ways to implement ajax so even 'smaller user base apps' can take advantage of it.

Seriously, is the effort to support and maintain this level of code in the client going to be worth the effort to develop. I accept that Google Maps etc is doing a great job at extending the browser. DHTML and CSS was always designed to do this stuff even back in the late 90's. ... Not so sure the apps for the smaller user base will and can afford the developer skills needed to build them.We need to be working towards simplication will AJAX do this ?

This is where third-party/opensource tools can fill the gap and provide 'easy to use' ways to implement ajax so even 'smaller user base apps' can take advantage of it.

Exactly, Jay,

Ajax toolkits are emerging, that will simplify the development of Ajax. There seem to be two main types at present - those that generate Ajax front-ends automatically from server-side models (e.g. Echo2, JSF), and client-side frameworks providing a higher level of abstraction for hand-coded javascript (e.g. Prototype, Scriptaculous, Rico, qooxdoo).

We cover a few of these in the book, but also spend a lot of time on the underlying technologies, because we're still in the early adopter stage where most Ajax projects will still need some hand-coding to complement the gaps in the current round of frameworks.

Regards,

Dave Crane

There seem to be two main types at present - those that generate Ajax front-ends automatically from server-side models (e.g. Echo2, JSF), and client-side frameworks providing a higher level of abstraction for hand-coded javascript (e.g. Prototype, Scriptaculous, Rico, qooxdoo).

AFAIK, some projects are trying to bridge both types, for example I know some wicket framework (which is component oriented a la Echo2 & JSF) developers are playing with Scriptaculous & DOJO right now. My hope is that there is going to be just a minimum or even none handwritten Javascript code in such situation (component oriented server-side framework + high-level abstraction AJAX framework at the client-side), plus all the known benefits we get from each approach.

Regards,
Henrique Steckelberg

AFAIK, some projects are trying to bridge both types, for example I know some wicket framework (which is component oriented a la Echo2 &amp; JSF) developers are playing with Scriptaculous &amp; DOJO right now.

Thanksd for the link. I knew about Wicket, but not the ajax integration. Interesting stuff, I'll keep an eye out.

My hope is that there is going to be just a minimum or even none handwritten Javascript code in such situation (component oriented server-side framework + high-level abstraction AJAX framework at the client-side), plus all the known benefits we get from each approach.

I don't agree with you here. Server-side solutions are essentially code generation, and therefore add complexity and limit the type opf code that can be created. (Not that I'm against code generation per se, I think it's a fine thing if its done properly, in the right context.) In many cases, auto-generating a smart form is good enough, but sometimes one needs a bespoke component (e.g. Google Maps). Moving solely towards server-generated JS would stifle inovation IMO.

I suppose that's a challenge for server-based frameworks - how easily can one create a new component type?

Regards,

Dave Crane

From what I know, once one creates a new component with all its server-side code + client-side code + template, it is just a matter of developers dropping it in the UI, set some parameters and code its server-side behaviour, the rest should be automated, or so I wish ;).
Further more, in my (limited) understanding this is the only way for this mix to work, since component-oriented web frameworks must keep UI state control all the time, and having handwritten client-side JS code messing up with UI state without server-side knowledge would mean things breaking up. One option would be for component developer to create some specific hooks where client-side code should interact with the component, anything else should remain under server-side framework control. But all this can be better addressed by actual AJAX component developers, which I am not. ;)

Regards,
Henrique Steckelberg

Here's a blog entry regarding Wicket + Scriptaculous autocomplete text component at work:
http://jroller.com/trackback/wireframe/Weblog/autocomplete_more_than_just_text. If you look at the example code, there's nothing besides the inclusion of the ajax component, setting its parameters and coding its server-side behaviour for it to work. No handwritten client-side JS at all. I expect most ajax components to behave like this when being used. Of course some clint-side JS code may be needed when _creating_ new AJAX components, but already existing component usage shouldn't depend on component user coding JS, or at least that should be minimal.
I am aware that right now all this is highly experimental in Wicket, but in case this approach proves feasible, IMO this would mean we'll get the best of both worlds.

Regards,
Henrique Steckelberg

Henrique,

The link sounds interesting, but it sems to be broken. Could you check it out pleae?

Many thanks,

Dave Crane

Oops, sorry, there it goes:
http://jroller.com/page/wireframe/?anchor=autocomplete_more_than_just_text

Regards,
Henrique Steckelberg

Ahem... performance of Swing was disastrous... ;-)

Swt on many platforms nowadays is slower than Swing, for instance Linux is one example, the Mac another one...

If you want to use a web application framework that that is thin client (no browser plugin required) and supports AJAX and gets you as close as you can get to a swing/swt API then you have got to check out echo2.

http://nextapp.com/products/echo2

It is opensource and very reliable.

Echo2 looks great indeed but looking at it in the light of application's target audiences, it seems to sit in a very narrow niche.

When I need just a few 'convenience' tricks like look-ahead of the names and on-the-fly form validations (looks cool indeed) for otherwise 'normal' browser applications, I'd rather use one of those thin AJAX libraries (script.aculo.us, DWR...)

But when the application really starts looking like complicated, I'd seriously consider building it as an applet or WebStart app (unless you are Google building GMail, of course) In either case, learning from experience I'd like to keep tight control on the communication between the presentation layer and business logics, to save myself trouble later in the project.

I detect a change in perception. For years I have been using some pretty fancy JavaScript. But the powers that be have always been told me to avoid using JavaScript unless absolutely necessary (it's a question of bad practice you know). However, it has nearly always been absolutely necessary given what these people ask me to build. Now I see that using fancy JavaScript has a name, I feel the time is coming where I will be asked to whole heartedly embrace AJAX.

I think I will be ready :-)

First of all, how come not a single comment on this thread addresses the subject at hand: Manning's "Ajax in Action."

Why do all of your comments immediately digress into a theist discussion having nothing to do with the post you're commenting on. What is this, Slashdot?

Now, moving along, did anyone else notice that this is an utterly crappy chapter which has next-to-nothing to do with so-called 'AJAX' technology. This chapter could *easily* be part of a book called Jumpin' Javascript, Delightful DOM, or Cunning css. It has nothing to do with the AJAXy part, i.e. the interaction of these client-side technologies with the cool innovative bits that sneak out to the server without refreshing the page.

That makes it a crappy chapter to pick as a sample.

Furthermore, did anyone stop to question this opening sentence:

"Ajax applications can contain much more client-side code than a standard web application, and hence benefit much more from the order that patterns and refactoring bring."

WTF?? How bafflingly false! What the heck does this even mean? Didja stop to think about it, or just swallow it, head-noddingly, as dogma.

Boo if ya want, ya know I'm right.

Spreading love and joy,
Benjamin Leo
http://www.anti313.com

What the heck does this even mean?

As I understand it, it means AJAX apps are supposed to have lotsa Javascript code and libraries at the client-side in order to make all that "magic" work, much more than the usual web apps we see today, some of which go as far as proposing their apps should have no javascript at all. Besides, not long ago most people regarded Javascript as a Bad Thing (TM), so this change in mind could really mean new ideas and concepts being adopted at the client-side, or at least I hope so if indeed AJAX is here to stay (Unit tests for AJAX, refactoring for AJAX, etc.), unlike XUL which didn't quite catch on.

Regards,
Henrique Steckelberg

You would make a great manager at my current company.

I understand why AJAX applications have more client-side code than a standard web application. (Wait! Don't stop reading the message and reply just yet!)

What I don't understand is why that should mean that they benefit much more from the order that patterns and refactoring bring.

Spreading love and joy,
Benjamin Leo
http://www.anti313.com

You would make a great manager at my current company.

Thanks! Though I am sure my company's managers wouldn't ever talk like that, anyway... ;)

I understand why AJAX applications have more client-side code than a standard web application. (Wait! Don't stop reading the message and reply just yet!)What I don't understand is why that should mean that they benefit much more from the order that patterns and refactoring bring.

Well, I wouldn't think of applying refactoring/patterns to a 6 LOC system... ;)

Regards,
Henrique Steckelberg

What I don't understand is why that should mean that they benefit much more from the order that patterns and refactoring bring.

Hi Benjamin,

What I meant by that was that the client-side code is bigger and more complicated in an Ajax app than in a traditional web app, where all the clever stuff takes place on the server.

Design patterns and refactoring are both tools for increasing the orderliness of a codebase. I've found them to be very useful when working with Ajax code, just as I do with my server code. Well-factored code is easier to look after in the long term, and any serious application development contains a good deal of looking after existing code, as well as developing new stuff. If you've worked on large-scale software projects in any language, you'll probably recognize this.

This is based on my own experience, looking after large banking applications containing around one hundred hand-written javascript files, on top of script that we generate dynamically from the J2EE back-end. That's bigger than your average Ajax project, I'll grant, but smaller projects can get real benefits from these too.

We lay down all the groundwork for refactoring and design tools in chapter 3 of the book, so I didn't give it much of a drumroll in chapter 4.

Hope that's clearer for you now.

Dave Crane

Thanks Dave. Anyone who has put an app that is heavy on the client-side into production knows that it can (and probably will) get very hairy in there very fast.

There is a tendency for developers to just "include that .js", and when they need more functions, tack them on the end as globals. This way leads to madness.

We've adopted the practice of making all js in client-side apps objects, stored in a class-per-file adhering to the java conventions. Throw JSUnit in there and you have something that is at the very least more maintainable and robust.

I think the main problem is that people have only started to write "good" code in javascript recently - its heritage over the past few years has just been simple validation and the like.

There's no reason for your Good Developer hat to fall off just because you're writing js.

Regards,

Greg Kerdemelidis

This is a sample AJAX application, which is done in a JSP/servlet/JavaBean framework. The database layer is handled by normal JavaBean, that handles the insert,update, find, delete and a servlet request handler, which dispatches actions to this JavaBean for different user's action. The web form is JSP and some rich UI taglib.

Try it out here http://rhae.dunco.com.my/examples/lppbap/jsp/

You can use hot key (short cut key) for actions such as, save, query, and navigate thru records, instead of using mouse clicking, please read the help, it works almost like Oracle developer forms and it is all handled by AJAX....

The above application was generated by an ASP version of tool, which is located at http://rhae.dunco.com.my/tools/LoginFormServlet, all the web forms, JS for AJAX, request & action handler Java classes, db transaction/queru handling JavaBean are all generated. A working, data-entry applications can be deployed within minutes. You only need to focus on coding complex business logic, such as calculation of tax, deduction etc for an online accounting application system

Would like to seek for publiv comment, and try it out