 ZDNet | Evolving from Web 1.0 to Web 2.0 ZDNet - In “Web 2.0 = a piece of jargon,” fellow ZDNet blogger Dan Farber highlights Tim Berners-Lee’s recent commentary on Web 2.0 and notes that “For Berners ... Web 2.0 = a piece of jargon Scrap Web 2.0, yes, but embrace Knowledge 2.0 surely |
| Scrap Web 2.0, yes, but embrace Knowledge 2.0 surely ZDNet - Gavin Clarke at The Register provides a needed wet blanket to toss over all things "… 2.0," especially Web 2.0. In many respects ... |
The latest edition of the venerable tome JavaScript: The Definitive Guide is a sorely needed update. I guess it took Ajax, Web 2.0, and an intervening five years to revive interest in in this quirky client-side language. The fourth edition, while still providing a good formal specification of the language, had fallen woefully out of date both with some of the new features introduced in recent browser versions and in terms of practical examples of how JavaScript is being used to enable Ajax and Web 2.0 applications.
I don’t mean to give a full review of a thousand plus page book here. Rather, I just want to focus on the chapter that covers client-side persistence. In the fourth edition, the corresponding chapter only discussed “cookie scripting.” While this chapter does talk about cookies, it delves into a number of other options for persisting data on the client.
Unfortunately, for a book that describes itself as the “definitive guide”, it only discusses three options for persistence: cookies, IE userData persistence and Flash SharedObjects. This coverage is far from definitive. In fact, Brad Neuberg in his discussion of dojo.storage enumerates seven different client-side storage mechanisms:
Maybe this is just a sign that the use of JavaScript has grown so far beyond what was common or even thinkable in 2001 that it is simply isn’t possible to write a definitive guide, at least not in a thousand pages. Would you buy a book called “Java: The Definitive Guide?” Probably not.
What is there — the discussion of Flash SharedObjects and IE userData persistence — is pretty brief in comparison to the exhaustive treatment of cookie persistence. It does give you a basic description and enough code samples to get you started, but a cookbook it is not. The section on persistence alternatives has the feeling of an afterthought — something shoehorned into the book relatively late to address Ajax and Web 2.0. In fact, many parts of client-side portion of the book have that feel.
I think the book is still worth buying as a language reference, if only for its treatment of closures and object creation, but for now you’ll have to look online for more detailed, exhaustive, and “definitive” treatment of many topics.
| AOL Hosts Dojo Version 0.3.1 to Further Ajax, JavaScript Adoption IT News Online, India - ... its continued involvement with and support of the Dojo Foundation, by hosting the recently launched Dojo version 0.3.1 to help further Ajax and JavaScript ... |
Kris Zyp has written up a RFC for JavaScript Persistent Object Notation (JSPON). The idea is to standardize a method for the identification of objects for efficient transfer and persistence of objects within large object graphs.
JavaScript Persistent Object Notation (JSPON) is a data-interchange format with the goal of simply being a defined usage of JavaScript Object Notation (JSON) to facilitate JavaScript objects that are intended to persist by defining a scheme to provide the necessary semantics needed for efficient and meaningful persistent objects. JSPON is pure JSON and maintains the same simplicity of JSON, and establishes a format for serializing and referring to objects to enable the persistence of JavaScript objects and object graphs by defining a set of fields for identification, deferred value loading, decentralized object creation, and primitive value, function and array object augmentation.
JSON provides simple straightforward mechanism for serialization of objects that can efficiently and easily be read by humans and machines. JSON can be adequate for the persistence of simple small objects. However applications that have large complex object graphs and sets of data generally require the exchange of smaller subsets of the data/object graph to be transferred and persisted at a time rather than requiring an entire object graph to be treated as whole, as well as allow objects to be referred from multiple fiels. Such operations on subsets of data entail identifying objects within a graph and allowing for transfers of subsections of object graphs (and not just end point subsets). JSPON provides the common language so that objects can be passed with proper identification and reference information. This also allows objects to be referred to more than once (not possible within a normal JSON object graph). Standard JSPON simply defines several fields that can be added to JSON object to assist in data description.
Terry Laurenzo has posted on Embedded SVG from his experience starting with the SVG example from Mozilla, and adapting Protowidget so that it could attach widgets to some SVG elements.
You can check out the test on an SVG enabled browser
| Sir Tim Berners-Lee punctures Web 2.0 hype PC Pro, UK - Tim Berners-Lee has debunked all the hype surrounding Web 2.0 insisting that what it purports to describe is exactly what he intended the Web to be when he ... |
The Ajax2jsf open source project now has a spin off G4jsf subproject that allows you to build JSF components in GWT.
Sergey Smirnov has written an article / tutorial on integrating the Google Web Toolkit with JSF using G4jsf:
The Google Web Toolkit (GWT) has attracted a lot of attention lately as a way to make it easier for developers to add AJAX Web 2.0 features to their applications. Like other approaches, the designers of GWT have tried to insulate developers from having to deal with the underlying JavaScript, which implements these features. GWT achieves this goal of simplifying the creation of advanced client-side JavaScript widgets by generating them from Java code.
At the same time, JavaServer Faces (JSF) has gathered more and more momentum as a general server-side framework for Web applications. The key to its success has been its top-to-bottom component-based approach to Web development. Although JSF comes with its own standard out-of-the-box UI components, it is designed for the easy inclusion of other component libraries.
While both of these technologies are incredibly beneficial on their own, they also both complement each other extremely well. GWT is server-side-agnostic, while JSF's component-based architecture can easily accommodate any approach for rendering components. In this article, we will discuss (primarily by using a step-by-step example) a new integration library for facilitating the combination of these two complementary technologies.