Tag Archives: Development

Oct200623

0

Dojo 0.4 Release Upon Us

The Dojo team is eyeing a full release for Tuesday at The Ajax Experience (a lot of the team will be here!). Today they put out which will probably be the final release candidate, so baring any issues in testing we will be ready. Dojo 0.4 Features
  • GFX Library
  • Internationalization infrastructure
  • dojo.debug.console: console logger, improved debugging with Firebug
  • dojo.html.metrics - scrollbar width measurement, current font size measurements, the ability to get how much of an HTML fragment will fit on a single line in a container, and to populate a container node with as much of an HTML fragment as will fit into it. Also included is a way of measuring the dimensions of a node if one was to populate it with a specific HTML fragment.
  • Widget Infrastructure: namespace support, subwidgets, refactoring of dir structure
  • Widgets: New widgets have been added and updated including: VML support, FilteringTable widget, Slider, Toaster, DropDownTimePicker, RadioGroup, Clock, ProgressBar, Datepicker, Editor, AccordionContainer, and many more.
Read more in the release notes, and stop by Alex Russells Dojo session at The Ajax Experience for more info. We will put up information from his talk. [via Ajaxian]

»crosslinked«

Did you like this? Share it:

Oct200617

0

Bookmarkability

Back in february when I wrote my first two tutorials on how to build an Ajax Portal, I explained how to make the pages bookmarkable. Bookmarks in Ajax Applications are very different from bookmarks in Web 1.0. In classic Web applications bookmarks pointed to a Resource (always remember that URI stands for Uniform Resource Identifier) and that was really why bookmarks were (and still are) so usefull, you could save the URL, come back later and find the same content, send it to a friend and he would see the same thing as you did, this sharing is really popular today (see Digg.com and del.icio.us). Bookmarks in Ajax Applications go far beyond this resource identification, they conceptually save the state of the Ajax Application itself, so that the state can be resumed at a later time. Going back to the example I used in the tutorials, the currently displayed content will certainly be important to save, so saving the currently displayed document in the URL is important, on the other hand the automagically updating list of online users is not context relevant and is not important to save to the URL. in fact the user list is volatile, updates independently from the page itself and would be a complete overkill to put into your URL. To sum it up:
KISS: Keep it simple stupid, don’t overload the URLs with useless state information that isn’t necessary. Creating too many differing URLs is not good coding style, keep them short and easy to remember, even better if it is something that makes sense.
The reason why I write this article is that just today I received a comment on my old tutorial asking how to save Form data in the URL. First of all: it wasn’t possible in Web 1.0, why should you want to in Web 2.0? Forms submitted with the POST-Method isn’t saved in classic URLs either, and we never complained about this. In Web 2.0 we now have to first answer a conceptual question: is the data sent from the Form worth saving to the URL? If I have a Registration Form I wouldn’t want a user to be able to save the Page after the Form, because it would mean that every time he opens this page it would issue a new Registration request. Where saving Form data may be relevant is a Search feature where the searchtherm is saved, but again this is no big deal because you can simply add a parameter to the URL. Although the difference may be subtle it is still important to keep this in mind, there are things that are nice to be bookmarkable, others aren’t, the question of what is best is to be answered by you when developing :)
Did you like this? Share it:

Oct200616

0

Benchmark: Prototype and jQuery

Claudio Cicali thought it might be fun to test wether the common prejudices against jQuery / for prototype hold:
  • Prototype CSS Selector is good
  • jQuery CSS Selector is evil
After all jQuery has a reallygood potential of becoming one of the nig players on the library market. Its ever expanding list of plugins already contains many desirable features. He set up some tests
  • select elements by a type selector (html element). Element selected (1000 times)
  • select elements by a type selector (html element). No element selected (1000 times)
  • select elements by a simple class selector. The class name does not exist (5000 times)
  • select elements by a simple class selector. The class name does exist (5000 times)
  • select elements by a simple id selector. The id does not exist (5000 times)
  • select elements by a simple id selector. The id does exist (5000 times)
  • select elements by a descendant selector (no elements selected) (1000 times)
  • select elements by a descendant selector (20 elements selected) (1000 times)
  • select 20 elements by a id selector and bind an event handler to each one (100 times)
  • select 20 elements by a class selector and add an addictional class name to each one (1000 times)
and ran them with both Libraries and tada, he got some interesting results:
The white/green representation may be a bit misleading, on some domains jQuery leases prototype far behind while in others the difference isn’t that big.
Did you like this? Share it:

Oct200614

0

Backbase launches Ajax Struts Edition

Being a big Java fan I am very excited that Backbase has announced a Struts Version of its popular Library.
“This newest edition of our Backbase AJAX software can revitalize business-critical Struts applications without compromising the reliability of the existing applications,” says Jouk Pleiter, CEO of Backbase, “Global 2000 companies and other large organizations will see an almost immediate return on investment.”
Along with the well known Backbase functionality you also get a taglib which allows you to add this functionality to your existing applications. [via AjaxWorld]
Did you like this? Share it:

Oct200610

0

Ajax and REST

As I wrote earlier I had the pleasure to read this very well written post over at IBM about why Ajax is a way to be RESTful. Bill Higgins starts by explaining what REST is and why it is important:
REST’s “client-stateless-server” constraint forbids session state on the server. Designing within this constraint promotes the system properties of visibility, reliability, and scalability. But immersive server-side Web applications wish to provide a great deal of personalization to a single user [...]
In short the REST-style allows us to keep simple resources that can be cached, and therefore take the load away from the server. Back in March I wrote a post explaining why Ajax is a better concept than traditional, session-driven, applications. It allows you to map a resource (the data that is needed by your application) to an URI, this allows you to keep those information-fragments well separated from the rest of the application, which will change its state during execution, while data probably wont. The “pure” data is separated from its representation and has become cacheable, and REST compatible, or as Bill explains it,

Going back to the Amazon.com example, imagine that you click a link to view information about a book on design patterns. In Amazon.com’s current application, the link click action sends a variety of information identifying the requested resource. It also sends various session-state artifacts that let the server create a new page that includes prior session state (such as recently viewed items), personalization information (such as “you purchased this book in 1999″), and the actual business resource itself. The application is very dynamic and highly personalized — but not cacheable and not natural scalable (though as Amazon demonstrates, these architectural problems can be overcome with millions of dollars of infrastructure engineering). Now consider this action in the (imaginary) Ajax version of the application. No processing needs to occur with regard to “recently viewed items.” This is simply information already present in the page that won’t go away when you click on a link. Two requests will likely be related to the design patterns book:

  • /Books/0201633612 (where 0201633612 is the design pattern book’s ISBN number)
  • /PurchaseHistory/0201633612/bhiggins@us.ibm.com

The first hypothetical request returns information about the book (author, title, descriptions, and so on); it contains no user-specific data. The absence of user-specific data means that as more users request the same resource, it is likely that they’ll retrieve cached versions of it from intermediate nodes on the Internet rather than from the originating server. This characteristic reduces server and overall network load. The second request, on the other hand, contains user-specific information (Bill Higgins’ purchase history for this book). Because this data includes personalized information, only a single user should ever successfully retrieve and cache the data from this URI. Although this personalized data doesn’t have the scalable characteristics of the nonpersonalized data, the important point is that this information is retrieved from a distinct URL and therefore has the positive characteristic that it doesn’t interfere with the caching of other application and data resources that are cacheable.

Personally I hope that this style of archieving things will be common practise in future. It makes things a lot easier, and solves many of the scalability problems we currently have :)

Technorati Tags: ,
Did you like this? Share it:

« Older Entries   Recent Entries »