Help coderanch get a
new server
by contributing to the fundraiser

Jord Sonneveld

Author
+ Follow
since Apr 09, 2007
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Jord Sonneveld

Why wasn't LiveConnect more popular? Having an invisible Java applet on your page that can fully interact with the DOM seems much more awesome and powerful than this silly Ajax stuff .

What makes them so different? Some things I can think of:
-Applets need the Sun Java plug-in / "Ajax" is built right in.
-Applet start-up time is slow / "Ajax" startup time is fast.

Is it just the slow JRE start-up and the need for the Java plug-in that slowed adoption? Is LiveConnect poised for a comeback, now that computers are faster and can load the JRE faster, and that people are starting to realize the power of RIAs? Was LiveConnect just too far ahead for its time?

Behold the re-revolution of LiveConnect with LiveJAX!
[ April 15, 2007: Message edited by: Jord Sonneveld ]

Originally posted by Roger F. Gay:
Perhaps I haven't read far enough yet, but what seems to be missing (compared to LiveConn) is the ability to call JavaScript functions from Java programs; thus triggering a page event whenever the Java program has something to send.

Do you want to call browser-side JavaScript from a browser-side Java applet? Or from server-side Java?

javascript / applet interaction : http://www.raditha.com/java/javascript.php
javascript / server-side java interaction : DWR reverse Ajax allows this.

Make sure you're reading the DWR 2.0 docs, as Reverse Ajax was introduced in that version. You can see a small sample at Joe's blog at http://getahead.org/blog/joe/2006/04/11/1144770216929.html

Are you sure this stuff isn't supported in standard JavaScript?

Server-side Java / Client-side JavaScript interaction is not supported right out of the box, by which I mean, there is no clear, well-defined standard API for doing this.

That doesn't mean that it isn't possible to write such an API that uses XHR to create this effect; that's what Joe has done w/ DWR.





j\s

Originally posted by Roger F. Gay:
I mean, I want asynchronous intereaction with back-end processes, but not just responses to clicks.

Definitely possible. You could use Prototype's periodical updater, which we cover.

Once communication starts, some processes may decide to provide updated information at any time, time and time again. This was easy enough to do with LiveConn and the iframes approach.

What I really want is that seamless use of JavaScript / Java (or other) that I got using LiveConn.

Given that: Is "AJAX in Practice" the book I'm looking for?

Definitely. We have a few examples that will show you how to do periodic updates. However, if you want the server to send messages to the client and have them appear instantaneously, I do not believe we cover that. Of course, it's easy to do: just use DWR's 'Reverse Ajax' functionality. You can find DWR at http://getahead.org/dwr and more info on its Reverse Ajax functionality at http://getahead.org/dwr/changelog/dwr20

Originally posted by ankur rathi:
A huge web application is already exist without Ajax. Now what steps do I need to take into account if I wish Ajax in it?



That's a pretty broad question

First step would be to identify what things you'd like to "Ajaxify". Once you know that, come back, and we can maybe talk more about it
[ April 13, 2007: Message edited by: Jord Sonneveld ]

Originally posted by Stan James:
Authors, what's your take on the readiness of these libraries for picky corporate users?

Some of them are quite ready; in fact, some are even developed by picky corporate users! GWT is of course created by Google; if they're using it, they're probably getting some kind of benefit out of it. OpenRico is actually created by Sabre for their own purposes.

Should GWT give me better warm and fuzzy feelings, just because Google seems to be Very Smart People?

Seeing as how I work for Google, yes, you should get very warm and fuzzy feelings

Originally posted by Javier Sanchez Cerrillo:
Hi, I haven't used AJAX Before but.

Will it replace the way we see JavaScript?



I think so. Before, much of the client logic was still executing on the server. With Ajax, a lot of client/user interface logic can be pushed to the client. JavaScript before Ajax was seen as something neat to spruce up the UI a little bit; post-Ajax, it will become an integral part of web application programming.
Afraid I have not read that particular book.

Originally posted by Bear Bibeault:
Other librarires were chosen not necessarily for their popularity, but for their utility.

Precisely. Not all libraries replicate each other's functionality. For example, AMASS functionality is not found anywhere else (local client storage), but it is still really handy to have.

Originally posted by Anupam Sinha:
With my limited knowledge and experience on AJAX, I think that AJAX's basically XMLHttpRequest and javascript. XMLHttpRequest is good enough for getting a response and after that it's all javascript. So I guess the book mainly covers javascript and probably some design patterns as well. Or is there more to AJAX minus javascript than XMLHttpRequest?

So, very basically, AJAX = XHR + DHTML + JavaScript + XML. If you take away the JavaScript, then you're left with DHTML + XHR + XML. But don't underestimate the JavaScript part. Using XHR in your apps really affects your client UI. You can do more powerful things, but of course at the cost of added complexity. We hope to show you how to handle that complexity.

And Appendix B is Why Go Commercial? Can you give a hint as to whether it talks about some open source tools or some paid ones to make life easier.

It was decided to make B an on-line only chapter. Yes, it will discuss commercial tools to make life easier; as you may guess, there isn't much discussion of open source tools in the "Why Go Commercial" chapter . That's because the rest of the book purely focuses on open source solutions.

Originally posted by Saif uddin:
I read this article "JSON is not as safe as people think it is" but I cannot find where the weak point is ? can you please define in a simple way that what are the thinks to follow when use JSON?Thanks



Another site that shows the exploit is here: http://robubu.com/?p=24

Originally posted by Bear Bibeault:
For DHTML, I swear by the flamingo




Forsooth! How could I forget the flamingo!

Yes, between the Rhino and the Flamingo, you should be off to a good start.

Originally posted by Jeanette Miles:
What are some of the best practices should be followed and does the book cover this subject.

See: https://coderanch.com/t/119812/HTML-JavaScript/Ajax-design-patterns

Is a questionaire application a good Ajax candidate?

Any application is a good Ajax candidate.

More seriously, "it all depends". I'm not too familiar with questionnaire applications. What would you like to do with them that would require Ajax techniques?

Also, what Ajax frameworks are covered in your book?
See: https://coderanch.com/t/119801/HTML-JavaScript/Ajax-Practice-kind-Blue-Prints

Originally posted by Jeanette Miles:
Also, what Javascript books are recommended that would be great to accompaniment an Ajax book?



You'll actually need books on three topics:
-JavaScript
-DHTML
-JavaScript + DHTML

For just JavaScript, the Rhino Book from O'Reilly is indispensable:
http://www.oreilly.com/catalog/jscript5/index.html

For the last two, I must confess that I usually just look through the W3C specs and the Mozilla developer manuals, which is sub-optimal. Anyone care to recommend some good ones?

People always forget (myself included) that JavaScript really is a powerful language in its own right. (At a previous company, we wrote apps in pure JavaScript which was then compiled to Java bytecode.) But having just JavaScript in a browser is useless. What makes JavaScript so powerful in the browser is that browsers expose access to their underlying internals through the DOM.

This is why you really need three books. The first to learn JavaScript by itself properly. The second to see how browsers expose the DOM to JavaScript. The third to see what neat stuff you can do w/ the combination.
To answer the question from the topic title about debugging tools for Ajax:

FIREBUG!!! http://www.getfirebug.com/

It's only for Firefox, but it's (probably) the only debugging tool you need.
Good question! Sounds like a good topic to write a book about...