Ed Burns's Blog

TSSJS - AJAX with Ben and Dion

I'm at The ServerSide Java Symposium, blogging live.

Let me use this forum to list the people I'd like to meet here: Ben Galbraith, Howard Lewis Ship, Matt Raible, The Bile Blogger. If you see me, please say hi.

I just attended Dion Almaer and Ben Galbraith's talk on ajax. Here are my notes.

I The Myth:

  Not possible too create rich ui only inbrowser

II What is ajax

  A. History: HTML->JS->Applets->Flash (Back Button) and SVG (Not impl)

  B. JS Pain 1998
  
   debugging was nightmare

   xp pain

 C. Defining

    Asynchronous JavaScript and XmlHttpRequest

    Standards based presentation

    Use XML to manipulate data with XSLT

  D. Client model

     No more single request/response restrictions, more flexibility to
     go back to server at will.

  E. Can do it asynchronous, it's a big deal because it changes the
     request/response paradigm.  Gets rid of submit button

  F. A bit on how

     a. still have to do the browser detection thing, but can be abstracted.

     b. showed the code to do the request, handle the response, by
        installing a JS callback.  Get the response as XML, use dom to
        extract info, use dom to put it back into the form.

  G. History of the XmlHttpRequest, methods on it.

    open(), send(), can pass basic auth credentials. (What about certs?)

    JS has function pointers

  H. Ecmascript for XML (E4X)

     Build dom straight into Ecmascript
  
III Who's doing it

  A. Google: maps

    images are tiled.  Requested asynchronously, that's how panning
    works.  JS supports layering, with transparent images.  

     They use IFRAME, which allows history to work.  

  B. Google maps becomes a platform

   When you get into this world, you are building a platform
    
   If you are lucky, there will be a Google hacks on the way.

   Lots of cool hack out there already

  C. Google suggest

    aim: let you know what people are searching

  D. TadaList

    Built on Ruby on Rails

    Simple List component, keeps server side component updated.

IV General Framework

  A. General Solns

    CRUD on the DOM

    Ideal for portals

    Animations, feedback messages

      Feedback messages: just show a message and not re-display the
      whole page.

    Deleting from the Admin Panel

      A tree control, delete a node, don't re-render the tree: just nuke
      it from the DOM.

    Recalculate:

      Why not recalculate on the fly?

  B. SOAP access

     RESTful web services.

  C. Frameworks: Custom...

     Listed examples of common things you can specify as patterns of usage.  

  D. JSON: JavaScript Object Notation

     Lightweight format to get objects back that are not XML.  Built on
      Object, Array, String, Number, etc

  E. JSON RPC: essentially a Java ORB

  F. JavaScript Templates

     Manipulating the DOM is a pain.  Use templating.  Basically, allow
      parameterized DOM access.

  G. AOP with JavaScript?  Yes, you can.  

  H. How to fit with frameworks?

    Have component that integrates this functionality.

    You can register a component with tapestry that will receive all the
      requests dynamically.

   (I'll be talking with Ben immediately after this talk)

  I. JSUnit: how to do test first with JavaScript.

   Solenium

V RSS Reader Demo

  Show you can build an offline capable application with AJAX.

VI Conclusion, warnings

  A. Warnings

  Don't use for technoligies sake.

  Understand Usability testing

  Understand restrictions

  Still in creative mode

    Frameworks will be coming, take the work out of it

  B. JS Survival tips

    You'll miss the IDE

    Packaging as source only lets people see source code

    Debugging, tougher, firefox, mozilla has something

    Packaging libraries: be wary of namespace.  The packaging scheme is
      basic

  C. JS Limitations,

    Can't access resources on other sites: wrong, must sign code.

    Signed code can also read from and write to the local filesystem.

    You have to get permission in every function.

  D. ajaxian.com

     Don't build your own framework.  It's probably been done before.

Comments

• Just a question for you. Above you write of AJAX:

  'You can register a component with tapestry that will receive all the requests dynamically.'

  
  As someone with a large investment in Tapestry, I am curious to know if you think it would almost be transparent to write AJAX style applications in this framework, given client side validations and such? I like the component development paradigm in Tapestry much more than in other frameworks like JSF, but I do not want to create each and every component with AJAX particularly in mind.
  

  Posted by: steve_thompson on March 17, 2005 at 11:08 AM

This work is licensed under a Creative Commons License.