Thanks for the post. I've spent the better part of the last year building an application based on XQuery, XHTML, and JavaScript with RESTful leanings. I imagine the comparable acronym to be XRJ (JRX doesn't come off very well).
From experience I agree with the observation that reducing data translation greatly increases the ROI of the development process. Although I continue to encounter quite a bit of ugliness with JavaScript, it plays an important role in my application and fits into the XQuery/XML architecture quite well. There is a lot of room for improvement of course.
Looking forward to digging into the proper XRX architecture as well.
Jason Monberg | June 5, 2008 07:20 PM
You write "Declarative techniques that use XML structures tend to accelerate the creation of domain-specific languages (DSLs)." What is interesting is that the vitality and fecundity of domain-specific markup languages has not, so far, translated into any vitality of domain-specific support languages. Quite the reverse.
Now I don't doubt that it is possible for such ecosystems to emerge (isn't that what the RDF project is attempting), but since a large portion of the XML value proposition is based on the use of COTS and general-purpose tools, I think they will be the exception rather than the rule.
I have two concrete examples. First, the use of Schematron (which operates direct on the markup) and W3C RuleML (when operating on RDF.) The second is that when the gap between the markup and the data model is great enough (e.g. which people variously consider as ugly markup or elegant model-driven development take your pick) then having some kind of domain-specific support (often just an API rather than a whole language) is a reasonable (but regretable?) approach.
When you start using Google as a development platform you quickly run into limitations. Google was not prepared for the unwashed thousands yet, they have accomodated millions of requests. My travels have encountered almost all of the challenges and a fair share of solutions.
Let us take some time here to thank Michael. THANKS!!! - There now I feel better too. About a year ago this gentleman was writing about the GWT (Google Tookit) and his four part series seems to have surfaced in XRX jargon. I say try it!
The British royal family changed their last name from Saxe-Coburg-Gotha to Windsor. Renouncing all German titles and properties while in the midst of a great World War.
Clarification from the web....
On 17 July 1917, King George V issued a Proclamation which stated that the male line descendants of the royal family would bear the surname Windsor:
from the date of this Our Royal Proclamation Our House and Family shall be styled and known as the House and Family of Windsor, and that all the descendants in the male line of Our said Grandmother Queen Victoria who are subjects of these Realms, other than female descendants who may marry or may have married, shall bear the said Name of Windsor A few months later, King George V issued Letters Patent on 30 October 1917 which limited the title 'Prince' and the style 'Royal Highness' to the children of a sovereign, the children of sons of a sovereign and the eldest living son of the eldest son of the Prince of Wales. HH Prince Alastair of Connaught (1914-1943), grandson of HRH Prince Arthur, Duke of Connaught (Queen Victoria's fourth son), became the first member of the royal family to use the surname Windsor in lieu of his princely title. It has been suggested that it was a misinterpretation of these latest Letters Patent which led to HH Prince Alastair (for such he was based on practise going back to the time of King George I's accession in 1714 and which practise was confirmed in Queen Victoria's Letters Patent of 30 January 1864; source: "The Princes of Great Britain" article in Burke's Peerage 1963 edition, pp xxvii-xxxii) being denied his princely title. However, as he was the son and heir of a peeress (Princess Alexandra, Duchess of Fife), he was allowed the courtesy use of his mother's subsidiary title and became Alastair Windsor, styled Earl of Macduff.
On 11 December 1917, it was further decided by Letters Patent that:
the grandchildren of the sons of any such Sovereign in the direct male line (save only the eldest living son of the eldest son of the Prince of Wales) shall have the style and title enjoyed by the children of Dukes. In 1952, Queen Elizabeth II confirmed her grandfather's decision that the royal family's surname would continue to be Windsor. Her Majesty declared on 9 April 1952 that it was:
her Will and Pleasure that She and Her Children shall be styled and known as the House and Family of Windsor, and that Her descendants other than female descendants who marry and their descendants shall bear the name of Windsor. A few years later, HM The Queen modified this statement by issuing Letters Patent in February 1960 which stated in part:
while I and my children will continue to be styled and known as the House and Family of Windsor, my descendants, other than descendants enjoying the style, title or attributes of Royal Highness and the titular dignity of Prince or Princess, and female descendants who marry and their descendants, shall bear the name Mountbatten-Windsor. Did this mean that the name of some members of the royal family changed from "Windsor" to "Mountbatten-Windsor"? Some people contend that the goal of this declaration was meant to not only change the surname of the children of HM The Queen but those of her male-line descendants as well. At Princess Anne's wedding in November 1974, Anne signed the marriage register 'Anne', without a surname. It was the registrar who filled in her names as 'Anne Elizabeth Alice Louise Mountbatten-Windsor'. According to a Buckingham Palace statement issued in October 1975, the specific addition of the surname 'Mountbatten-Windsor' was "the Queen's decision that this should be done". Further, HM The Queen consulted with the acting Prime Minister to confirm whether all her children would have the surname Mountbatten-Windsor. She received the following reply:
"The effect of Your Majesty's Declaration is that all the children of Your Majesty who may at any time need a surname have the surnames of Mountbatten-Windsor." (Prince Philip: A Biography, by Denis Judd, London: Michael John, 1980, page 196) It would seem that the surname of HM The Queen's children is whatever HM wishes. Legally and constitutionally, however, the Queen cannot do as she wishes. The surname of the Queen's children is Mountbatten-Windsor in practise and has appeared three times: at Princess Anne's first marriage in 1974, on Prince Andrew's marriage register in 1986, and when the banns were read prior to Princess Anne's second marriage to Commander Laurence in 1992. (When the Prince of Wales married for the first time in 1981, he signed the register as "Charles P" and the registrar filled in his name as "His Royal Highness Prince Charles Philip Arthur George The Prince of Wales".) Nonetheless, the family name remains legally Windsor because there hasn't been any modification or clarification to the Letters Patent of 1960.
When Great Heart, slays the giant, a pillar is erected and his head is placed upon it. The following was written such that passengers and passers - by might read;
"He that did wear this head was one That pilgrims did misuse; He stopped their way, he spared none, But did them all abuse; Until that I, Great-heart, arose, The pilgrims' guide to be, Until that I did him oppose That was their enemy."
5 messages in net.sourceforge.lists.exist-openRe: XForms and eXist From Sent On Attachments Dan 21 Jan 2008 22:13 Scott Warren 22 Jan 2008 13:40 Andrzej Jan Taramina 22 Jan 2008 15:08 Adam Retter 23 Jan 2008 06:04 Scott Warren 23 Jan 2008 14:51 Subject: Re: XForms and eXist From: Scott Warren (scot...@ocom.com.au) Date: 01/23/2008 02:51:18 PM List: net.sourceforge.lists.exist-open Glad to hear. I had to ask J Still wondering where XRX came from ...
Regards
Scott Warren
From: Adam Retter [mailto:adam...@devon.gov.uk] Sent: Thursday, 24 January 2008 1:05 AM To: Scott Warren Cc: exis...@lists.sourceforge.net Subject: RE: [Exist-open] XForms and eXist
The temporary fragment issue is in hand, although it has been on pause for a few months whilst I moved house and renovated, hope to resume work on it ASAP.
-----Original Message----- From: exis...@lists.sourceforge.net [mailto:exis...@lists.sourceforge.net] On Behalf Of Scott Warren Sent: 22 January 2008 21:40 To: 'Dan'; exis...@lists.sourceforge.net Subject: Re: [Exist-open] XForms and eXist
Dan,
Did you make up XRX? I like it.
Once eXist fixes it's Temporary fragment issue it would the perfect platforms for such a "stack".
Regards
Scott Warren
Ocom Software
From: exis...@lists.sourceforge.net [mailto:exis...@lists.sourceforge.net] On Behalf Of Dan Sent: Tuesday, 22 January 2008 5:14 PM To: exis...@lists.sourceforge.net Subject: [Exist-open] XForms and eXist
Whatever system you choose for rendering XForms on the browser, and there are now several options, I believe that the combination of XForms/REST/XQuery (XRX) to be a magical fit. It has allowed me to quickly build complex web applications with deep nesting of XML data without ever having to use JavaScript or shred inserts into multiple tables of an RDBMS.
I don't really know if it was an accident that XRX got to be so powerful (I think not), but I believe it has become the "new stack" for building great web applications. I hope people get a chance to try out building some really complex applications with XForms/REST and eXist and see how the architecture holds up.
Chris Wallace, myself and a few others have been working on some small examples in wikibook format that you can get at the following links:
I want to explore the XRX (XForms, REST, XQuery) architecture, so I've set myself the challenge of implementing a social bookmarking web service modelled on del.icio.us as described in Chapter 7 of Leonard Richardson's and Sam Ruby's "RESTful Web Services", using Orbeon Forms and eXist. This is the first post in a series that will look at how the implementation works, and any problems I run into along the way. In this post, I'll be looking at setting up eXist with some basic data and queries that will support the rest of the application. eXist is an open-source native XML database; you might want something a bit more heavy-weight if you're looking to do this with enterprise-level quantities of content, but eXist has the basic capabilities that you'd expect from an XML database and is more than sufficient for exploring the XRX principles. eXist comes bundled with Orbeon; you can download the latest standalone version but the URLs that I'll be referencing here are all based on the bundled version.
XForms is something of an odd duck. Originally intended simply as a modularization of the HTML components so that they could better work in a more XML oriented environment, the XForms specification very quickly morphed into the foundation for a considerably more sophisticated application, albeit one that had a few ... idiosyncrasies.
For instance, unlike most other applications where the data model was bound into objects and object models, XForms defined its data models as blocks of XML, and the controls, rather than individually holding values that the application could set or retrieve via script, actually were bound to the data model - change a value in the model, and the control changed, change a control value, and the underlying model automatically reflected that change. Throw in bindings using XPath expressions, a purely declarative structure and working with models that could be loaded from the server or submitted to the server without forcing a reload of resources, and you could perhaps be forgiven for thinking that XForms was a language designed by committee (which, to be honest, is pretty much what happened).
W3C Standards are themselves a little odd, with the XML standards being particularly notable for this. In most cases, standards represent a consensus view about what the existing state of the industry looks like, only with the rough edges of controversy smoothed away in smoky, back-room deals (the truism of politics and sausage also applies to the creation of standards - one should never look too closely into how any of them are made). The W3C XML standards, however, involved a technology that itself had not existed until the W3C formally established it, though it did of course have the twenty five year old precedent of SGML to fall back on.
What emerged after XML, on the other hand, has bordered on the surreal. XSLT took a template matching approach to transformations and XML processing that was powerful but hardly intuitive (especially if you tended to be dubious about the power of recursion). XPath provided an odd notation for referencing the various parts of a given XML structure, while the recent completion of XQuery did the same thing for whole collections of XML documents. Even XML domain formats like SVG got into the act, representing a radical break in the depiction of vector graphics that seemed completely at odds with the instruction oriented approach that predated postscript.
All of these technologies (as well as XForms) represented the rethinking of computational tasks in light of a semantically neutral meta-language and a declarative approach to programming. Not surprisingly, the tools that emerged out of this bear remarkably little resemblance to more procedural imperative tools. Similarly, the XML community has always been somewhat smaller and ... well ... quirkier than its imperative counterparts in other languages, so it is perhaps not all that surprising that XForms has gained relatively short shrift compared to AJAX, Ruby or other web technologies.
However, there are a number of signs that XForms is beginning to establish itself as a legitimate tool for businesses and developers:
The XForms specification has gone through both a 1.0 release, which provided the first generation of XForms tools a stable standard on which to build, and a 1.1 working draft that represents some significant rethinking of 1.0 problem spots is now relatively stable and will likely become a formal recommendation this year. XForms implementations exist for Mozilla Firefox as a plugin that's been built in conjunction with the primary build, and this implementation now supports most of the 1.0 specification and several important pieces of the 1.1 specification. Third party support for an Internet Explorer is provided by FormsPlayer. Server-based XForms implementations by Orbeon and Chiba provide ways of hosting XForms on any platform that supports basic AJAX capabilities, with both increasingly appearing as bundled clients with a variety of XML Database servers ... and both boasting a significant customer base. XForms is now appearing as an embedded systems on mobile devices from companies such as PicoForms and Yahoo, and is also appearing as the embedded forms engine for the OpenOffice.org suite. The combination of XForms, REST and XQuery (a collection increasingly known collectively as XRX) is gaining prominence as XQuery itself becomes more widely accepted and more XQuery implementations appear on the market. Finally, as organizations move towards the creation of industry vertical XML taxonomies, the need for sophisticated and versatile tools for rendering this (highly malleable) content is rising. XForms is ideally suited for these types of applications. All of these factors indicate that XForms as a technology is beginning to become competitive, especially for those applications dealing with large, complex data structures. However, while this may show the viability of such applications, it doesn't necessarily indicate why XForms as a technology should be interesting to you or your organization. To better understand that, it's worth appreciating that a radical shift has been taking place quietly in the web application space for some time, a shift best embodied by the acronym MVC: Model/View/Controller.
Models have been at the heart of application development for some time, but typically the models involved are conceptual in nature, and tend to revolve primarily around the objects that are interact within the application and their correlated processes.
For instance, consider the typical insurance application, which in most cases actually tends to be a number of related applications. One part of this application is the sale of insurance policies, each of which usually has a number of potential sub-parts with fairly significant data acquisition requirements per policy or sub-policy. A second part of the application is the submission of a claim against such a policy, where a number of different people interact with the system: an agent records the initial claims from a customer (often going from screen to screen to handle whether the claim is against a small vehicle, a large vehicle, a house, or some other insured entity), a claims adjuster who compares the initial claim against the actual damages found, and consequently makes annotations or changes content and makes recommendations, and a claims manager, who either approves or disproves the claim, typically on the basis of external conditions, legal precedent and customer prior history. All of these people may in fact be utilizing the same basic record, but what they do with it differs dramatically; not surprisingly, such applications, for all that they may seem perfect for use on the web, often tend to be based on standalone apps because the complexities of setting up a website to manage this is just more work than its worth.
As it turns out, however, all of the actors above are in fact working on the same basic data model that in turn can be broken down into a few (fairly complex) collections of entities - a collection of policies, a collection of claims, and a collection or rules for determining if the claims will be paid out (there are also a couple of additional actor collections which determine permission action for various users, but the role that these play is comparatively minor and can be filled in as appropriate). Thus, in terms of a model, the primary objects defined in this case are policies, claims, and rules.
One of the central concepts of data modeling is that what you are attempting with a model to determine the minimal necessary set of data that needs to be maintained in order for an application to work. The configuration of this data can be called the state of the model at any given point in time, or an instance of the model. In the XML space, this condition can be restated by saying that a given model can be expressed as a set of XML structures, each of which holds some critical aspect of a model (for computational sake, there are times that it is easier to decompose certain portions of a model as separate XML instances than it is to maintain all of the state in a central document).
One implication of this, however, is that if the instances do in fact accurately represent the state of the model at any given time, then it is possible to conceive of a layer (called a controller) that can map the model to some distinct presentation or view. One such view may show a report providing the details of the claim in a read-only fashion. Another view may provide an editor that lets you make changes to the model (and that render changes in the model as some change in the user interface). If you indicate that a claim is being made for a boat, for instance, then only those parts of the claim editor that deal with marine vehicles are deemed relevant and displayed, while those dealing with houses or cars are hidden from the user.
In this example, relevancy is a significant aspect of a model that can be incorporated as a specific property in the model through the use of some form of constraint ... which is in fact exactly what the controller is supposed to control. Thus the role of the controller is to mediate constraints on the model, while the role of the view is to provide an interface between the model and the producer or consumer of instances of that model.
The Model/View/Controller (MVC) paradigm has been around for quite some time, but in general has been found more in the breech than in the observation. Most contemporary applications work upon a component basis where each component maintains its own (largely inaccessible) model, and any attempt to build a more cohesive large-scale model from this usually involved pushing the model into abstraction. The difficulty with abstract models is that they are extremely hard to enforce, especially when the controller portions are defined weakly if at all.
However, for a number of reasons, XML based web applications lend themselves strongly to MVC type applications. XML, by its very nature, makes it possible to establish a virtual object model without having to specifically the precise implementation of each subordinate object in the model. It is property based, rather than process based; this makes it easy to separate out the concerns between model and controller. XML has no intrinsic semantics (nor even an explicit requirement upon schema), meaning that it becomes the right and privilege of the application designer to determine the bindings on a given element in the model, not the framework's. Finally, because XML can be readily streamed over network connections, you can create complex distributed models at comparatively little impact (and in most cases, no impact) to the functioning of the application.
This is precisely what XForms does. XForms is an XML namespace layer that is meant to be bound into other namespaces - XHTML, SVG, Open Office, DocBook or DITA, proprietary namespaces, it really doesn't matter. An XForms application thus usually defines a model with one or more instances in it that hold sway within the scope of the particular page, graphic, or related context, all defined by the use of either local XML documents or imported XML streams. The application in question may also define constraints within that model called bindings that determine the relevancy, validity, value, or accessibility (read/write state) of given nodes within that model).
Once these are defined, the view defined by the XForms application in turn consists of various input (and output) components, each of which links via XPath to one or more nodes in the model. Sometimes these linkages are simple - a given selection box could be linked to the type of claim (auto, house, marine, etc.), such that by changing the value in that box you also change the type of claim. Other linkages are more complex - a repeat element will link to a set of elements which represents all boats that are covered by the claim, where the individual properties of each boat represent simple links. Perhaps most important, if a constraint in the model forces a change in the type of claim, then the select box will automatically (without user input) also change its value to represent this new state.
Put another way, these controls are bound to the model, which is bound to the control. The user seldom if ever needs to write any imperative code to accomplish these changes. More significantly, while the data model instance can be changed to reflect the changes introduced from this view, at any given time, the model itself is internally consistent. Indeed, it is even possible within XForms to keep an application from submitting an XForms model to a server (or persisting it locally) if the model instance in question doesn't have all of the right information (such as someone making a claim without adding the specific thing claimed damaged or stolen).
This kind of design approach has some huge implications:
Especially by controlling relevance, you can replace a large number of "screens" in a traditional server-based application with a single XHTML+XForms document that shows only the parts of the user interface that are relevant at any given time in the entry process. You can prevent model instances with incomplete state from being persisted to the server, or you could use an XForms interface to clearly differentiate between draft documents which aren't valid and processed documents that are. A given XHTML+XForms document can be broken down into distinct sub-pieces that are then compiled together as a single document when needed. This means that it becomes far easier to change portions of a document without having to replace the entire application. You can utilize XForms implementations in most browsers, so that changing your applications generally does not require extensive downloads and upgrades of the XForms-based application. XForms based applications work especially well in queued message environments: multiple agents can send new claims to the server where they are submitted in a message queue and can consequently be processed independent of the agent's own editing processes. Submissions that require clarification or are otherwise provisional rejected for re-editing would then be sent back to the user via notification systems (such as atom feeds). In most XForms implementations, it is possible to customize the look and feel of a given control, sometimes dramatically. For instance, in the insurance claim for an auto collision, it may be possible to define different types of collision intersections as graphics, then record the path of both vehicles as a set of lines from a graphic drawing interface that gets translated into a set of coordinates in a given field. The underlying XForms model and controller remains simple, but the components in the view can be made as sophisticated as necessary. The principle drawbacks that XForms has at this stage are generally those that any fairly new technology has, and as such need to be considered in that light when evaluating XForms. Specifically,
the developer community is small, albeit is growing at a fairly dramatic pace. This will likely continue as a number of XForms pilot projects in various industries come to fruition, and the demand for XForms developers continues to gain steam, because of the close (and obvious) coupling between XForms and XQuery, as more systems implement robust XQuery based systems, the architectures for supporting XForms on the server will also increase. XQuery implementations have risen dramatically in the last year after the publication of the W3C XQuery recommendation (significantly, this same coupling also has meant that every XQuery developer has in turn either also also become or worked in conjunction with an XForms developer), in general, the XForms technologies are currently produced by tier 2 or tier 3 companies, or exist as open source projects of the same magnitude. Given the synergies between XQuery and XForms, it is likely that many of these companies or projects will be absorbed by one or more tier 1 companies over time, XForms 1.0 has some issues that have limited the complexity of the applications built against it. XForms 1.1, now in Candidate Recommendation status, resolves most of these issues, while still remaining backwards compatible with 1.0, and it will likely become a full Recommendation by June 2008. Discussions for an XForms 2.0, which incorporates many of the innovations brought with XPath 2.0 and XQuery 1.0, are currently underway, and will likely convene as a full working group upon publication of 1.1. What this means is that the technology has both reached a point of stability and has developed a set of complementary technologies that are also stable enough to make XForms a good tool for exploration via pilot projects. It is debatable whether the technology is stable enough for the full deployment of enterprise applications at the moment, though the trends indicate that this will be case by the end of 2008 or mid-2009 at the outside.
XForms represents one area where Burton Group recognizes the potential for significant growth in both market presence and technological adoption. It is no panacea (though few technologies are, even those that may be advertised as such) but especially in increasingly sophisticated XML data applications it is a logical, compelling, and attractive alternative to complex applications that become bogged down because of server application complexity.
XRX: Simple, Elegant, Disruptive - O'Reilly XML Blog
Mr. Vaibhav V. Gadge (vaigadge@in.ibm.com), Software Engineer, IBM
25 Jul 2006
Web applications are ready to go to the next level, and Rich Internet Applications (RIAs) can greatly enhance user interaction. In this overview of RIAs, you'll learn how to adapt them in the user interface (UI) layer. Web developers and architects might be particularly interested in the discussion of Laszlo, XUL, XForms, Macromedia Flex, and Dojo -- the common technologies currently available in this area. Links to other technologies are also included. A fair understanding of traditional UI tools, such as HTML and XML, is assumed.
Rich Internet Applications (RIAs) go beyond the standard limited set of conventional user interface (UI) controls provided by HTML, such as text boxes, checkboxes, or radio buttons. RIAs provide users with a much richer set of controls, and a more sophisticated server interaction mechanism. With RIAs, users don't have to refresh the page when they submit data from a browser; they can refresh only a part of page, have better error handling, and a lot more.
This article covers:
Overview of RIAs
UI technologies, including Laszlo, XUL, XForms, Dojo, and Macromedia Flex
Comparison of tools
Other technologies
Overview of RIAs
The term "Rich Internet Application" has been around for a few years, although the concept has also been known as:
Remote scripting
X Internet
Rich (Web) clients
Rich Web application
The Internet is a huge source of information, and technologies strive to improve information delivery and storage performance on the Web in a sophisticated and user-friendly manner. In most Web applications, a substantial amount of processing takes place on the server side and mere user interaction takes place on the client side. This eventually burdens the server with a heavy data and processing load, and increased dependency on network traffic.
The ancient client-server based architecture has high flexibility and richness, but died in the age of the Web. One reason was the lack of uniformity or standardization of client applications. Now, undoubtedly, the browser is the universally accepted Web tool. Yet, it lacks intelligent processing. So the onus lies on client applications that can deliver a richer user experience and do simple processing on the client side. RIAs provide opportunities to design much better, faster, more engaging, and infinitely more usable user experiences -- all within a browser.
Developers who work on the Web and internet UI layer often experiment on the UI layer and try various RIA tools that can work effectively with minimum external support. In most cases, however, the browser needs some support in terms of plug-ins, extensions, or downloads to work seamlessly inside the browser.
This article discusses the tools and parameters that help identify the best RIA choices for a business case. It isn't possible to discuss all the factors of RIAs, but I'll concentrate on some important features to review as you evaluate RIA technologies.
What to evaluate
When you evaluate RIA technologies, consider the following factors:
Richness of the UI
How many basic, out-of-the-box UI widgets or controls are readily available to develop a UI? How can you do data binding and event binding with these controls? The new controls should be easy to use, and also easily pluggable. Some RIA technologies give simple ways to add richness and more informative visual experiences, such as providing animation APIs in the page. For example, to ensure users click only once on a button, you can animate the button to move out of the view.
Complexity
Developers have used existing page-based models for so many years because it is easy and simple, however clumsy it might appear. RIA technology has to be easy to learn, build, and extend. It should also interoperate with existing Web technologies.
Flexibility and componentization
Flexibility to collaborate with different middleware components is important. Collaboration should be easily composable and extendable to create new customized widgets. Once you create libraries of custom widgets, you can reuse them in applications.
Refreshing the page
There is a significant advantage to refreshing a block of a page instead of an entire page, as it directly depends on network traffic. Refreshing a block makes the application faster, more usable, and a much better visual experience for users. It also helps manage errors better.
Suppose a user performs an action or a first task on a Web page, and the data is submitted to a server in the background. Then the user resumes another task on the same page. In the meantime, the feedback from the first task has come back and updated some part of the same page. Thus, if you design the Web page in such a way, you make the work and tasks more efficient.
Security
When you adapt to RIAs, ensure that there is no increased security threat compared to conventional applications. Be aware of security surrounding server communications, or browser plug-ins and extensions downloaded on a client.
Support for basic Web paradigms
The technology should support the basic Web paradigms that have evolved in today's Web applications, such as internationalization, user device independence, browser independence, and binary file transfer support for upload and download functions. Even the maturity of the technology matters.
Tooling
Review the tooling that's available for developers in the form of integrated development environments (IDE), with unit testing and debugging support. Tooling might be plug-ins with existing editors or supported editors.
Usability
Users expect the browser application to work with its usual browser features. In particular, features such as saving images, Ctrl+F to search for content on a page, and copy-and-paste don't work in Flash-based solutions. Base your RIA usability design on human-computer interaction (HCI) principles.
Back to top
UI technologies
This section discusses some different options provided by current UI technologies.
Laszlo
Laszlo is the leading open source platform for the development and delivery of RIAs on the Web using Flash. Flash player was initially started with a small plug-in to run Flash files inside browsers. Because of its high reliability and compatibility, it is extensively used for creating flashy and animated images. Later versions have incorporated some serious scripting compatibility, data exchange with servers, and Flash 6 that adds bidirectional audio and video communications.
Laszlo has extended this richness, and used scripting language that generates Flash and delivers in a browser. It provides an open source XML-native platform for building RIAs.
What is XPath?
XML Path Language is a W3C-recommended language designed to address the information in an XML document. XPath's primary purpose is to navigate through any node and attributes in XML documents.
It needs only Flash 5.x+ installed on any browser. The script is written in an XML-based language called LZX. LZX is an object oriented, tag-based language that uses XML and JavaScript syntax to create the dynamically generated Flash files. The LZX compiler on a server compiles an LZX file and sends out Flash files to the browser. The actual data exchange is in XML form, and LZX controls use XPath to refer to XML. Events are also easy to bind with the controls. Each control defines a set of events that can inherit events from the parent. The example in Listing 1 shows how to use an event.
Listing 1. Example, simplelaszlo.lzx
You'll find Laszlo easy to learn, develop new components, componentize, and integrate with any Web application. It has a rich library of components compared to other RIA tools.
LZX has the capability to make HTTP and Web services requests with SOAP and RPC protocols to the server, in the background, without refreshing the page. A plug-in is already present to integrate any Web application file with the Laszlo library. Currently, an Eclipse-based IDE is available for development. There is also some tooling available for debugging in LZX on the client side. Interestingly, they also provide the Lzunit framework for testing Laszlo applications.
Recently, Laszlo announced support to deliver the application in a browser as a DHTML using the same existing framework. This provides you the option to configure whether you want to deliver the application to DHTML or Flash. Laszlo has also extended support to the Ajax community and multiple user device delivery.
Figure 1 shows an example of Laszlo and Dojo.
Figure 1. RIA image created with Laszlo and Dojo
XUL
XML user-interface language (XUL) is Mozilla's XML-based, cross-platform language that describes user interfaces of applications. It provides a rich library of ready-made components for use in a page. Currently, it works only on Gecko-based browsers such as Mozilla Firefox, or Netscape 6 or later.
XUL uses an XML-based markup language to describe the user interfaces controls. It provides all sorts of popular rich internet controls such as menus, tabs, trees, and pop-up menus. XUL uses a document object model (DOM) to store the tree of nodes. Once all XUL files are loaded, XUL parses and converts all tags in a hierarchical document structure of nodes. You can then use the DOM structure to examine and modify the data using its own method and additional methods provided by XUL functions. You can always access and manipulate DOM from JavaScript, making it easy to handle it like a typical HTML control. Each control and each node have several attributes that define their appearance and structure.
A browser handles XUL files similarly to HTML or other browser content when accessed from a remote location. However, when they are installed locally in a browser in its chrome system as an extension, they receive special privileges to access local systems and bookmarks. In this case, it can perform additional privileged operations.
The Mozilla browser itself is also a set of packages containing XUL files, JavaScript, and stylesheets, although it is a much larger and much sophisticated extension.
XUL uses the eXtensible Bindings Language (XBL) for binding. Each control can be bound using Mozilla's XBL. XUL uses the RDF format, which can be used to store resources. You can use data in other formats and create RDF data from it, which will be bound to XUL elements.
Because XUL is like an XML file, you can use any text editor or XML editor for the IDE. Since the same underlying code handles all the XUL files, HTML, and SVG, you can use CSS properties to style XUL files. It has built-in support for localization, as all text content is kept separately in a browser.
Skins, made up of CSS files in Mozilla, define the user interface of the browser. You can modify and create skins for different looks without changing the code. It is similar to extending the power of the browser APIs by adding features.
If you run the file in Listing 2 in Mozilla Firefox, it will render a text box and button.
XForms
XForms 1.0 provides a new platform-independent markup language for online interaction. W3C has come up with the specification for implementing XForms, and it is considered a successor to HTML forms.
XForms is independent of the presentation device. It can be delivered without any code changes to a traditional browser, PDA mobile phone, voice browser, and even some more exotic emerging clients such as an instant messenger. This makes it an attractive tool for RIA.
In XForms, the actual data (XML form definition) is separated from the presentation of the form. This device-independent XML form definition, called the XForms model, can work with a variety of standard or proprietary user interfaces.
XForms user interfaces provide a standard set of visual controls that are targeted toward replacing today's XHTML form controls. They are usable inside XHTML SVG or other groups, voice browser groups, or can also independently develop user interface components for XForms.The XForms model is referred in each XForms control to render the data. It follows the XPath to refer the elements in XML. When data is submitted, it can just submit the populated XML data model.
XML events
XML events is an XML language with the ability to uniformly integrate event listeners and associated event handlers with a DOM event. When an event occurs, it's dispatched to the element (target) through a document tree path and can be passed back to the tree again. The observer can respond to the event in the path.
XForms uses XML events for handling events and actions. The XML event specifies event, observer, and handler. As shown in Listing 3, DOMActivate is the event, message element is the handler, and parent trigger is the observer.
You can integrate XForms with AJAX. Currently, at the W3C, you can find 20 or more example implementations of XForms. Many vendors, including IBM, have already developed XForms engines (see Resources for the XML Forms Package). Mozilla has announced that XForms will be supported on all platforms on which Mozilla runs. To look at a good example of XForms implementation, see Resources.
Listing 3 shows a simple example of XForms that displays a text box and button rendered with a FormFaces™ implementation.
Listing 3. XForm displaying a text box and button rendered with a FormFaces™ implementation
Dojo
Dojo is an open source DHTML toolkit written in JavaScript. The Dojo Toolkit provides a core set of libraries, and rich set of different package libraries, and each one provides specific functions. Dojo provides lower level APIs to write portable JavaScript and simplify complex scripts. It is easy and quick to prototype interactive widgets and animated transitions. It provides libraries for events system, I/O packages, and generic language enhancement. You can write scripts with Dojo, and can include as little or as much of the available APIs as you want to suit your needs.
Dojo also provides a set of widget libraries that you can use directly in any application. You can use some of the core widgets as UI controls, such as the menu widget, tabs set, tree widget, and more. Others are generic functions, such as layout widgets, date picker, SVG widget, and so on.
Dojo is built around a single markup language that provides a simple way to declare and use response DHTML interface components. Listing 4 shows a simple example of a Dojo component for a special button to the user in an HTML page.
Listing 4. Example, dojosample.html
You need to include the Dojo widgets library that is required in your HTML page.
The Dojo kit also includes some debugging options. The AJAX Toolkit Framework (ATF) can be used as a powerful IDE. This is part of IBM's Emerging technology Toolkit (ETTK), which is a special collection of emerging techniques. ATF is based largely on the Eclipse Web tools project, which enables support for DOM browsing, JavaScript debugging, and more.
Recently, the Dojo Foundation announced a partnership agreement with Laszlo. Under this agreement, you can use the Dojo Toolkit in Laszlo's open source projects. In turn, Laszlo will contribute libraries to the Dojo Foundation, thereby advancing the growing open source communities at large.
Macromedia Flex
Macromedia Flex is another Flash-based user interface. It provides a Flex presentation server that sits on top of an application server, and generates Flash files dynamically from the server and delivers to a browser. These Flash files are executed inside the Flash player of the browser, and allow interaction with users, the performing of operations, and even the generation of SOAP, HTTP, or AMF requests to connect back to the server.
The layout and UI components are defined in an XML-based language called MXML. Flex provides a rich MXML extensive class library for visual components, containers, and remote service objects and data models. It also does data binding with controls, and accesses server-side data.
An ECMA scripting language (ActionScript 2) is embedded in MXML to handle user events, system events, or to construct complex data models. This is an object-oriented language, similar to JavaScript and ECME script. Like XForms, Flex also keeps data model, data presentation, data validators, and data services separate (similar to the MVC style).
All requests that come to MXML are processed through the Flex compiler, which compiles MXML and generates SWF, and caches until it is modified and finally delivered to the browser.
Any XML editor can be used for scripting of MXML, but Macromedia also provides a special IDE called Flex Builder 1.5 for Flex application development. It has the advantage that it is integrated with the Flex server. It also provides components that allow connecting to the server, doing normal HTTP calls, connecting to remote Java™ objects, and interacting with Web services from the browser itself. It can be integrated with existing J2EE and .NET application models.
Listing 5 shows an example of Macromedia Flex code.
Macromedia Flex looks similar to Laszlo. Both are rich and powerful Flash-based applications. Laszlo stands outside of the Flash engine, so performance might take a hit, but it has several other advantages.
Back to top
Comparison of tools
The following table compares the five technologies discussed in the previous section, as well as Altiolive (a rich enterprise application).
Table 1. Comparison of tools
Technologies Browser technology Scripting Richness Notable
Laszlo Flash,XML LZX files+JavaScript High Easy to learn, rich
Mozilla XUL XUL language XUL files+JavaScript High Powerful with browser dependency
XForms Xform Depends on implementation Up to certain extent Device-neutral and W3C compliant
Dojo JavaScript HTML+JavaScript Up to certain extent JavaScript based. Growing and adaptable.
Macromedia Flex Flash, XML MXML files High Not open source. Proprietary tool of Macromedia.
Altiolive Applet, XML Java Up to certain extent http://www.altio.com/
Back to top
Other technologies
You've looked at five technologies, but there are certainly more. A number of companies provide very impressive prototypes of RIAs using various technologies. While out of the scope of this article to discuss each of them, it is worth your looking into the following:
Backbase - Develops and sells software that helps create AJAX applications.
Netvibes - A free service for custom-made Web home page solutions.
Zimbra - An open source server and client technology for next-generation enterprise messaging and collaboration.
Protopage - Free, personal start pages.
Nexaweb - A software platform for building and deploying Enterprise Internet Applications.
altio - Rich enterprise applications in a browser.
Back to top
In conclusion
This article introduced RIAs, discussed current UI technologies, and pointed to additional technologies. I hope this comparison of the tools will help you choose the one right for your requirements. Each technology has different advantages, giving developers a rich set of controls based on your needs.
The technologies discussed bring some amazing things to users, and provide a richer user experience. You can now go beyond the browser and render to PDAs, mobile devices across platforms, and empower the user experience with audio, video, graphics, and animation. RIAs have almost embraced XML, and XML is undoubtedly the winner here.
In the future, I expect RIAs will play a major role in transforming Web UIs to the next level, and aid preparation to support Web 2.0.
Resources
Learn
OpenLaszlo: Learn all about this open source platform.
XULPlanet: See how easily you can create rich, sophisticated, cross-platform Web applications.
XForms: Visit the W3 place for XForms and the latest implementations.
Macromedia Flex: Look at sample applications at Adobe's Flex Development Center.
Dojo WikiHome: Contribute a Dojo project.
Articles: Read about Rich Internet Applications, and how "RIAs are designed to deliver 8A's Software Simply."
Orbeon: Check out a good example of XForms implementation.
developerWorks Web architecture zone: Expand your Web-building skills.
developerWorks technical events and webcasts: Stay current on technology with these sessions.
Get products and technologies
Dojo tool kit: Speed your Web developement with this JavaScript toolkit.
Mozilla Firefox: Set up the browser to run XUL files. It also comes with a JavaScript Debugger extension that helps JavaScript debugging.
Ajax Toolkit Framework: From Eclipse Web tools, try this as an IDE for Dojo.
XML Forms Package: Get these XForms engines available from alphaWorks.
IBM trial software: Build your next development project with software available for download directly from developerWorks.
Discuss
Participate in the discussion forum.
developerWorks blogs: Participate and get involved in the developerWorks community.
About the author
Vaibhav V. Gadge is a software engineer at the IBM Software Lab in Bangalore, India. He currently works on the Portal team of the Websphere Product Center. He is a Java certified professional, and has around five years of technical experience in Java, J2EE, and Web-based technologies on multiple platforms. He holds a Bachelor's degree of Electronics Engineering from Nagpur University. You can reach Vaibhav at vaigadge@in.ibm.com.
Rate this page
Please take a moment to complete this form to help us better serve you.
Did the information help you to achieve your goal?
Yes No Don't know
Please provide us with comments to help improve this page:
How useful is the information?
1 2 3 4 5
Not
useful Extremely
useful
Share this....
Digg this story del.icio.us Slashdot it!
Logic designer and internet administrator. John is the kind of technical person that will spend 12 hours on a challenge so that the next time it is encountered only 12 micro seconds are required for the proven solution.
"Marblehead CG-7" is an action adventure novel about Lt. Bliss, the Navy, Radio, "The Three Friends", Baseball and Cuba in the 1890's.
Tech Support
This Joe Novell character is very good at providing Technical Support. Matter of fact, most of the visitors here at LinuxViews are very good at technical Support. Email joenovell@gmail.com and get into some of the discussion groups.
