Pure Ajax or Existing ajax framework ?

[Nakata kokuyo]

hi, good day, i'm have no knowledge in ajax, and wanna have a try on it soon, can comeone please guide me should we start to learn pure ajax or existing ajax framework like DWR and so on ?

thank you very much for advice

[Sergey Smirnov]

Both ways pretty equal. I mean pure ajax and DWR from the JSF perspective. If you are not going to use JSF, DWR might be preferable.

[John Fallows]

Writing an Ajax framework that works correctly across different browsers can be an extremely difficult task, depending on the scope of the effort.

I'd recommend learning enough about pure Ajax to understand the common problems and then leverage an existing Ajax-enabled JavaScript framework, such as Dojo Toolkit to deliver the solutions.

In our book, Jonas and I show how to integrate Dojo Toolkit with JavaServer Faces using the Java.net open source project called Weblets. The same technique can be used to integrate other Ajax frameworks as well.

Kind Regards.

[Sergey Smirnov]

Dojo knows about JSF lifecycle, validations, converters and listeners. It knows how to update the portion of the view keepping the syncronization with the components tree on the server. Do I follow the idea correctly?

[Jonas Jacobi]

Dojo is a regular Ajax toolkit that provides, apart from cool Ajax features, solutions to most of the cross-browser issues you would hit writing your own Ajax framework. We used Dojo because it provided the functionality we needed, and it is also one of the most established Ajax toolkits on the market. Essentially, you could use any Ajax framework for your JSF components - Kabuki, [url=http://dojotoolkit.org/]Dojo[url], Backbase etc...

"Dojo knows about JSF lifecycle, validations, converters and listeners. It knows how to update the portion of the view keepping the syncronization with the components tree on the server. Do I follow the idea correctly?"

Dojo is not aware of JSF. We used Dojo to enhance our plain HTML JSF components providing richer functionality. In our book we discuss how to make the client side model, provided by Ajax, and the server side model, provided by JSF, work smothly together.

[Adeel Ansari]

Originally posted by Jonas Jacobi:
"Dojo knows about JSF lifecycle, validations, converters and listeners. It knows how to update the portion of the view keepping the syncronization with the components tree on the server.... "

Coool, I must say.
[ April 05, 2006: Message edited by: Adeel Ansari ]

[Pradeep bhatt]

What is a AJAX framework ? Why do we need it ? I thought AJAX is achieved by javaScript XmlhttpRequest.

[Adeel Ansari]

Originally posted by Pradip Bhat:
What is a AJAX framework ? Why do we need it ? I thought AJAX is achieved by javaScript XmlhttpRequest.

Yes right. Its nothing new but a technic. I guess, he/she is refering dojo, Kabuki, DWR as an AJAX frameworks.

[Nakata kokuyo]

in term of learning curve, which one will take less time?

[Sergey Smirnov]

Originally posted by Pradip Bhat:
What is a AJAX framework ? Why do we need it ? I thought AJAX is achieved by javaScript XmlhttpRequest.

AJAX is achieved by javaScript XmlhttpRequest in the same degree as web applications are achieved by HTTP protocol. Do you know RFC-2616 well. Ok, let me re-phase my question - does anybody have to know it today in order to develop web applications? The answer was not the same we have currently. Personality, I learnt the RFC (RFC-1945) about ten years ago because CGI requires to have a deal with it.
XmlhttpRequest - is too much low level. Dojo (prototype.js and so on) is just one small step to the right direction. I suggest, we will develop AJAX-enabled application without having a deal with XmlhttpRequest and javascript code at all. Like we have not to have a deal now with request parameters directly in JSF.
Javascript is not designed originally to be a primary language for application, so it has a few chance to be a king on the AJAX scheme a long period of time.

P.S. Just for your reference:
RFC-2616 http://www.w3.org/Protocols/rfc2616/rfc2616.txt
RFC-1945 http://www.w3.org/Protocols/rfc1945/rfc1945.txt