The recent AJAX hype has lead to the belief that AJAX is a Good Thing. Without saying it is a Bad Thing, I do think in some cases it is being used for inappropriate purposes. It requires some explanation to tell when it's appropriate and when it's not. The main point being made here is that AJAX is an unreliable technique. I don't mean the word "unreliable" as negative as it may sound. It just means the technique should be treated with special care.
What makes AJAX unreliable?
Two things: the fact that it is JavaScript and the fact that it is Asynchronous.
Why is JavaScript unreliable?
First of all a rough 10% of web site visitors disable JavaScript. An increasing number of RSS readers like RSS Bandit tend to disable JavaScript in their browser component for security reasons by default. This means you cannot rely on the availability of JavaScript and you should ensure your web application is still accessible without JavaScript.
If JavaScript is enabled, it's still a common weak point in web applications. There are subtle differences between JavaScript implementations through several browsers and versions. It's a tough job to test through all browsers, versions and operating systems. It is recommended to stick with the standard JavaScript functionality that has been around for a long time and not to use browser specific features.
JavaScripts are error prone by their nature. JavaScript is dynamically typed and uses weak typing. Dynamic typing means variables are not explicitly declared with a type; instead all variables are a "var" and get a more specific type on initialization. Weak typing means that once a variable is initialized, it can still change types when needed. Strong typed languages (regardless of whether they are statically or dynamically typed) generate an error message when programmers forget to perform proper conversion of variable types.
The lack of error messages is a tricky part. An essential programming philosophy is the Fail Fast principle. The basic idea of this principle is that when something goes wrong, a program does not try to continue working. It should stop and display an error message. Contrinuing working after an error is very risky because it is unpredictible what the program will do after the error. To a web site visitor it is better to display an error message with an indication whether it makes sense to try again, come back tomorrow, install new software or go to a church and pray. In consultancy this is called "managing expectations". Telling the visitor it won't work is better than letting him continue working for 30 minutes and then find out the 30 minutes were a complete waste of time.
Implementing the Fail Fast principle in JavaScript is not easy if not impossible. The error handling mechanisms in JavaScript are very poor. Most of the time the best you can get is "something went wrong". In more sophisticated languages like Python, Java and C# you can get specific exceptions with stack traces leading to the exact point of failure. This is one of the reasons why I'm very glad with Microsoft's transition from ASP Classic to ASP.Net. Compiled dotNet code is much more stable, predictible and easier to debug than VBScript based ASP Classic.
What's wrong with Asynchronous code?
Nothing really, as long as you don't forget it is asynchronous and asynchronous is unreliable by definition. The difference between synchronous code and asynchronous code is the predictibility of the server response. A synchronous request blocks until a response is received. If the response times out, you get a clear error message. As long as you don't introduce multi-threading yourself, your code is completely predictible.
In contrast, asynchronous code continues working without knowing when the reponse will be received. If your code depends on the response, you need to build in a system that checks the status of the response before it starts executing. The risk is that while developing and testing your server responds so fast that you forget the possibility of not receiving a response. Building a system that checks the status of a response makes your code complex and hard to maintain. Building such a system goes against the nature of asynchronous requests. It means you're using functionality for a purpose it wasn't meant for. Denying the nature of a technique is a Code Smell. This means you should consider doing things in a fundamentally different way.
How can I still use AJAX?
You should have a clear understanding of why you need AJAX. AJAX is not a goal, it is a method to achieve a goal. What is your goal and why is AJAX the appropriate solution? Are there alternatives? Is there a backup method to fall back on when it doesn't work?
AJAX is a client side technology. As with all client side technology, your server should be developed in a defensive way. All client side checking of form input should be rechecked server side just to be sure. Also, in the absence of client side support for AJAX technology, the server should provide functionality to fall back on so the web application keeps working.
The most popular reason for AJAX is performance. AJAX reduces the load of traffic between client and server and reduces the need for page reloading in the browser. This is good as long as the page reloading method still works. Google suggest is a good example. Google still works when the suggest-feature is not available. It is very user friendly though that the feature is there when the browser is able to process the scripts and the server responds in time.
AJAX can be very helpful when providing early feedback on a form filled out by a web visitor. For example a registration form can warn that the username chosen by the visitor already exists before the form is submitted. This saves time. As long as the server checks the username again on form submission, this is proper use of AJAX.
Inappropriate use of AJAX would be if a search engine decided all search results are loaded through AJAX and classic form submission would no longer be possible because it would be slow anyway. Inappripriate usage would be if a drop down menu in a form depended on content provided by AJAX depending on earlier input in the form. Even though this might work in 98% of the cases, it is no proper way to provide your services to your visitors.
Conclusion
More general, what this article says about AJAX, can be translated to any client side technique. You should also be careful depending on client side technology when it's Flash, a Media Player, browser versions or devices. Making assumptions about client side features has been one of the main causes for irritation by visitors of many web sites. Of course there are differences between personal sites, entertainment sites and company or government sites. Especially in the last case, special care is required.
When NOT to use AJAX? Do not use AJAX when you depend on it. Use AJAX as an additional feature to spice up your web application and serve your customer.
AJAX | JavaScript
Sunday, July 17, 2005
Monday, July 11, 2005
XHTML 2 and the MVC Design Pattern
The World Wide Web Consortium (W3C) has been working on a slow paradigm shift to purify HTML since the introduction of HTML 4. Before that, HTML was mainly a layout language suitable for WYSIWYG editing of web pages. In the early days of HTML, the layout options were limited. HTML was intended as a document description language, not a layout model. Users wanted better looking pages, so browser vendors added layout features to HTML. HTML 4 Strict was intended to end this practice and return HTML to the early days without layout options.
HTML Strict forces users into using CSS style sheets for layout. Because most HTML content was written with layout within the HTML it is impossible to switch to HTML Strict overnight. That's why the W3C introduced (X)HTML Transitional version to allow layout within HTML to help the transitioning process. The result of these two versions: (X)HTML Strict made it just a little bit too hard to do the actual switch and (X)HTML Transitional made it just a little bit too easy not to switch. Only recently web developers start showing interest in the Strict version of HTML and XHTML because they see the advantages when supporting mobile web sites, RSS feeds, print views, text-to-speech software and options to allow visitors to choose their own style sheet. (X)HTML Strict has a few flaws. XHTML 2 will help to improve the standard to overcome these flaws.
MVC
The idea behind separating content and layout is based on the Model-View-Controller (MVC) design pattern. A design pattern is a commonly agreed upon best practice for software developers. The concept of design patterns was initially introduced by the four authors (gang of four) of the book Design Patterns. The MVC pattern has its origins in the SmallTalk programming language. SmallTalk is one of the earliest fully object oriented programming languages and many concepts in Java and C# are inspired by SmallTalk.
The MVC pattern suggests that in software design the Model (data) should be separated from its View (layout) and Controller (actions). Separating these aspects allows software to dynamically switch one of these modules without affecting the others. For example you could switch from a web browser view to an automated voice reading the message to visually disabled people, without affecting the data or the actions that can be performed on the data.
MVC allows designers and software engineers to work together without interfering with each other more then necessary. They only need to agree on a common definition of the data - the Model - and then the designers can work on the View and the developers on the Controller. Integration is only a matter of testing. It is an art to define proper models allowing reuse of existing code, easy maintenance and extensions for future additions. It requires both creativity and communicative skills, a good understanding of the problem area, experience with the modeling techniques and vision for future requirements. No single person should do this on his own, defining proper models is a team effort.
Drawbacks
Many developers love MVC, some hate it. The downside of MVC is that you need to know what you're doing. If you are used to WYSIWYG clicketyclicking until it works without thinking about why it works, MVC might turn out to be a disaster. For MVC you need a clear understanding of the underlying concepts of the platform you're developing for. If you are unable to define clever concepts or abuse existing concepts, the resulting application will punnish you with bugs, bad performance and a crappy interface.
An example is the overusage of MVC in the Java Swing platform. Swing is an API for creating graphical user interfaces in Java. It is nearly impossible to develop a proper user interface in an MVC environment without thorough understanding of the MVC concept. Many people think Swing is no good because they have only seen poorly written Swing applications. It takes at least a year experience for a developer to use Swing properly. There are several reasons for the popularity of Eclipse's SWT alternative. Performance and platform integration are not the only reasons. Nevertheless I love Swing and its overdesigned object model. If you know how to use it, it's a model that comes alive and starts acting on its own.
For the current version of Visual Studio, Microsoft delibarately chose not to use the MVC pattern but follow the clicketyclick-until-it-works-without-knowing-why-it-works-approach. The result is that it takes very little time and knowledge to implement an application in Visual Basic compared to implementing the same application in Java and Swing. However, when you want to reuse existing code to implement another application, it takes little time in Java and a lot of time and copy/pasting in Visual Basic. For larger applications reuse of code is fundamental for developing maintainable programs. Still, comanies with limited resources cannot afford to chose proper modeling over rapid development.
(X)HTML Strict
A common misconception is that transitioning from old HTML to HTML Strict is about replacing TABLEs with DIVs. A more accurate description is replacing meaningless tags and layout tags with meaningful and descriptive tags and defining the layout separately in CSS files. Tables provide powerful ways for positioning content. For this purpose tables are used with content that is not actually a table. In IE4 and Netscape 4 DIVs were refered to as "layers" and also meant to position content. IE4 introduced the idea of replacing tables with layers. In recent browsers almost all HTML tags have positioning capabilities similar to DIVs. DIV tags provide little meaning to content other than to separate unrelated parts of an HTML document. Therefore they shouldn't be used for other purposes than separating content.
Instead of using DIV tags, web developers should find tags that describe the nature of the content. For example many menu structures implemented as DIVs and TABLEs are actually unordered lists (UL) with list elements (LI). In combination with CSS and a little JavaScript, menus can very well be implemented in UL- and LI-tags resulting in menus providing the same functionality with less JavaScript code. The main advantage is that when you view the page in a text-oriented browser (Lynx) the page is still understandable and provides the complete functionality. You can see this by disabling the CSS file. It doesn't look pretty but if you want to, you can still find your way.
Layout oriented tags like B (bold) and FONT should be replaced with meaningful tags like STRONG and EM (emphasis) to separate the meaning of the text from its layout. TABLEs can be used for defining data that actually is meant as a table. Headers are used to structure a page and possibly allow the automatic generation of a table of content. Keep thinking how a text-to-speech engine would read the page to visually disabled people. Keep in mind it is a form of discrimination when you do not try the best way you can to enable your page for disabled people. They have the right to read your articles, buy your products and need to access government services from time to time.
Similarities
The idea of separating document structure and layout is not new. Experienced users of MS Word use headings and style profiles to markup their documents. The automatic generation of tables of content in Word completely depends on this idea. A better example is LATEX. This is text based document structuring language used for academic publishing for many many years.
XHTML 2
Web developers who are separating content from presentation are forced to use a few dirty tricks to accomplish what they want to do in the current versions of (X)HTML. For example to create a good looking menu, a designer may want to use pictures instead of text. The picture actually contains text and when viewing in a text based browser, you want to see the text. There are CSS tricks that allow the designer to provide the text in the HTML and replace the text with a picture using a style sheet.
XHTML 2 has new features to prevent the need for these tricks. In the current versions of (X)HTML an image can be provided by using an IMG tag or by using a CSS property. In XHTML 2 the SRC property of the IMG element can be applied to any XHTML element. For example it is possible to define a [li scr="image.png"]Descriptive text[/li] without the IMG tag. If the browser is unable to view the image, the descriptive text is viewed instead. Otherwise the image replaces the descriptive text. There is no need for ALT attributes anymore, a cleaner view is given when the image is unavailable, there are no unnecessary ID and CLASS attributes and there is no pollution of the CSS file. The CSS provides metadata that should be the same for every page; the menuimage in many cases actually is data that may change from page to page. XHTML 2 solves this issue and the trick is no longer needed.
Similarly it is not necessary anymore to use an anchor (A) to provide a link. The HREF-attribute can be applied to any element. For example [li href="/newpage.html"]Descriptive text [/li] generates a linked list item. The advantage is that links are no longer limited to text links - or images using the IMG tag. With the generalization of the image SRC attribute, it is a logical choice to do the same with the HREF attribute. If any element can be a link, the number of options increases tremendously. Emulations of this behavior using an ONCLICK attribute to trigger a JavaScript event are no longer needed.
By the way, the W3C chose not to use the XLink spec. I think this is a good idea because HTML editors are too used to the HREF attribute to change that. The XLink spec never became popular and received a lot of criticism. This design choice in XHTML 2 might be fatal to the XLink standard.
Modularity
In HTML 2 forms are defined using XForms. In other posts in this weblog I am writing about XForms. Right now it is hard for me to imagine that XForms is going to be the default implementation in a major standard like XHTML. In the new philosophy it is logical to separate a form from a document definition because the nature of a form is fundamentally different from the nature of a document structure. The same way frames are defined in a separate module XFrames. A frame has nothing to do with defining a documents. It is just a convenience to the user for example when viewing JavaDoc API documents.
Adoption
The main question for the success of XHTML 2 is whether it will be used by web developers or not. There are several threats that may stand in the way of successful adoption of XHTML 2. One of the main hurdles is the learning curve for XHTML Strict and CSS. An intelligent web designer will see the advantages and learn XHTML 2. However, most of the internet is filled with content written by average users, not web specialists. The average web editor uses a WYSIWYG tool to create web pages. WYSIWYG tools give the author control for what the web page will look like. Shifting to the new paradigm where layout is defined in CSS files, the content author loses control of the layout. Many users will not easily accept a decline in features and usability of their application. Solving this issue requires more than training. Perhaps brain-washing is a more accurate description.
At this moment, most HTML editors in content management systems are layout based and use B and I tags, font types and colors etc, etc. I haven't found a proper editor for document structuring yet. An editor that integrates with any possible CSS file and still provide a WYSIWYG view while defining structure instead of layout is not easy to develop. For this issue, we'll have to wait and find out. Tips from readers are welcome by the way. Please leave a comment if you know of any effort or have experience in solving this issue.
Another risk is the required skills for developing a proper web site where content and layout are separated. Document modeling is not an easy task. Large organizations can afford to hire qualified developers. But the average web site is developed by amateurs lacking the skills and experience to define an accurate document structure presented by style sheets. What we need is proper and clever tools. I'm not a fan of Dreamweaver, but I do think it is up to Macromedia to provide the tools to use XHTML 2.
Last but not least, don't forget the adoption of XHTML 2 by browser vendors. I have faith in the Mozilla organization, they'll create new versions of Firefox imlementing XHTML 2. But it is questionable whether Microsoft's Internet Explorer will support XHTML 2 in the near future. IE has a history of implementing what the users want. There's a good chance that time is standing still and we're stuck with (X)HTML Transitional. I really hope my pessimism is misplaced and I'm wrong here. Possibly the recent community-awareness of Microsoft will convince them to follow the standards, who knows?
For now, at the time of writing, the proposal for XHTML 2 is not even final yet, so let's be patient.
Your feedback?
Even though some of the above statements may sound like I'm presenting facts, everything is my opinion. I didn't do my homework and I didn't check every detail I've written. If you disagree with my opinion or especially if you can prove me wrong, please leave a comment. I'm always interested in opposing views and I know many web developers see things differently. Most interesting is not what you think, but why you think it. Also feel free to post links to your own weblog if you have content related to this subject. I don't mind shameless self-promotion as long as it leads to interesting stuff.
Thank you for reading my text! My next article will explain when not to use AJAX. Watch the RSS feed (Atom actually). If you do not use RSS news readers yet, try the open source RSS Bandit for a while. It's dotNet, looks like Office 2003 and does what it is supposed to do.
Tags: Semantic Web | XHTML | XHTML 2 | MVC
HTML Strict forces users into using CSS style sheets for layout. Because most HTML content was written with layout within the HTML it is impossible to switch to HTML Strict overnight. That's why the W3C introduced (X)HTML Transitional version to allow layout within HTML to help the transitioning process. The result of these two versions: (X)HTML Strict made it just a little bit too hard to do the actual switch and (X)HTML Transitional made it just a little bit too easy not to switch. Only recently web developers start showing interest in the Strict version of HTML and XHTML because they see the advantages when supporting mobile web sites, RSS feeds, print views, text-to-speech software and options to allow visitors to choose their own style sheet. (X)HTML Strict has a few flaws. XHTML 2 will help to improve the standard to overcome these flaws.
MVC
The idea behind separating content and layout is based on the Model-View-Controller (MVC) design pattern. A design pattern is a commonly agreed upon best practice for software developers. The concept of design patterns was initially introduced by the four authors (gang of four) of the book Design Patterns. The MVC pattern has its origins in the SmallTalk programming language. SmallTalk is one of the earliest fully object oriented programming languages and many concepts in Java and C# are inspired by SmallTalk.
The MVC pattern suggests that in software design the Model (data) should be separated from its View (layout) and Controller (actions). Separating these aspects allows software to dynamically switch one of these modules without affecting the others. For example you could switch from a web browser view to an automated voice reading the message to visually disabled people, without affecting the data or the actions that can be performed on the data.
MVC allows designers and software engineers to work together without interfering with each other more then necessary. They only need to agree on a common definition of the data - the Model - and then the designers can work on the View and the developers on the Controller. Integration is only a matter of testing. It is an art to define proper models allowing reuse of existing code, easy maintenance and extensions for future additions. It requires both creativity and communicative skills, a good understanding of the problem area, experience with the modeling techniques and vision for future requirements. No single person should do this on his own, defining proper models is a team effort.
Drawbacks
Many developers love MVC, some hate it. The downside of MVC is that you need to know what you're doing. If you are used to WYSIWYG clicketyclicking until it works without thinking about why it works, MVC might turn out to be a disaster. For MVC you need a clear understanding of the underlying concepts of the platform you're developing for. If you are unable to define clever concepts or abuse existing concepts, the resulting application will punnish you with bugs, bad performance and a crappy interface.
An example is the overusage of MVC in the Java Swing platform. Swing is an API for creating graphical user interfaces in Java. It is nearly impossible to develop a proper user interface in an MVC environment without thorough understanding of the MVC concept. Many people think Swing is no good because they have only seen poorly written Swing applications. It takes at least a year experience for a developer to use Swing properly. There are several reasons for the popularity of Eclipse's SWT alternative. Performance and platform integration are not the only reasons. Nevertheless I love Swing and its overdesigned object model. If you know how to use it, it's a model that comes alive and starts acting on its own.
For the current version of Visual Studio, Microsoft delibarately chose not to use the MVC pattern but follow the clicketyclick-until-it-works-without-knowing-why-it-works-approach. The result is that it takes very little time and knowledge to implement an application in Visual Basic compared to implementing the same application in Java and Swing. However, when you want to reuse existing code to implement another application, it takes little time in Java and a lot of time and copy/pasting in Visual Basic. For larger applications reuse of code is fundamental for developing maintainable programs. Still, comanies with limited resources cannot afford to chose proper modeling over rapid development.
(X)HTML Strict
A common misconception is that transitioning from old HTML to HTML Strict is about replacing TABLEs with DIVs. A more accurate description is replacing meaningless tags and layout tags with meaningful and descriptive tags and defining the layout separately in CSS files. Tables provide powerful ways for positioning content. For this purpose tables are used with content that is not actually a table. In IE4 and Netscape 4 DIVs were refered to as "layers" and also meant to position content. IE4 introduced the idea of replacing tables with layers. In recent browsers almost all HTML tags have positioning capabilities similar to DIVs. DIV tags provide little meaning to content other than to separate unrelated parts of an HTML document. Therefore they shouldn't be used for other purposes than separating content.
Instead of using DIV tags, web developers should find tags that describe the nature of the content. For example many menu structures implemented as DIVs and TABLEs are actually unordered lists (UL) with list elements (LI). In combination with CSS and a little JavaScript, menus can very well be implemented in UL- and LI-tags resulting in menus providing the same functionality with less JavaScript code. The main advantage is that when you view the page in a text-oriented browser (Lynx) the page is still understandable and provides the complete functionality. You can see this by disabling the CSS file. It doesn't look pretty but if you want to, you can still find your way.
Layout oriented tags like B (bold) and FONT should be replaced with meaningful tags like STRONG and EM (emphasis) to separate the meaning of the text from its layout. TABLEs can be used for defining data that actually is meant as a table. Headers are used to structure a page and possibly allow the automatic generation of a table of content. Keep thinking how a text-to-speech engine would read the page to visually disabled people. Keep in mind it is a form of discrimination when you do not try the best way you can to enable your page for disabled people. They have the right to read your articles, buy your products and need to access government services from time to time.
Similarities
The idea of separating document structure and layout is not new. Experienced users of MS Word use headings and style profiles to markup their documents. The automatic generation of tables of content in Word completely depends on this idea. A better example is LATEX. This is text based document structuring language used for academic publishing for many many years.
XHTML 2
Web developers who are separating content from presentation are forced to use a few dirty tricks to accomplish what they want to do in the current versions of (X)HTML. For example to create a good looking menu, a designer may want to use pictures instead of text. The picture actually contains text and when viewing in a text based browser, you want to see the text. There are CSS tricks that allow the designer to provide the text in the HTML and replace the text with a picture using a style sheet.
XHTML 2 has new features to prevent the need for these tricks. In the current versions of (X)HTML an image can be provided by using an IMG tag or by using a CSS property. In XHTML 2 the SRC property of the IMG element can be applied to any XHTML element. For example it is possible to define a [li scr="image.png"]Descriptive text[/li] without the IMG tag. If the browser is unable to view the image, the descriptive text is viewed instead. Otherwise the image replaces the descriptive text. There is no need for ALT attributes anymore, a cleaner view is given when the image is unavailable, there are no unnecessary ID and CLASS attributes and there is no pollution of the CSS file. The CSS provides metadata that should be the same for every page; the menuimage in many cases actually is data that may change from page to page. XHTML 2 solves this issue and the trick is no longer needed.
Similarly it is not necessary anymore to use an anchor (A) to provide a link. The HREF-attribute can be applied to any element. For example [li href="/newpage.html"]Descriptive text [/li] generates a linked list item. The advantage is that links are no longer limited to text links - or images using the IMG tag. With the generalization of the image SRC attribute, it is a logical choice to do the same with the HREF attribute. If any element can be a link, the number of options increases tremendously. Emulations of this behavior using an ONCLICK attribute to trigger a JavaScript event are no longer needed.
By the way, the W3C chose not to use the XLink spec. I think this is a good idea because HTML editors are too used to the HREF attribute to change that. The XLink spec never became popular and received a lot of criticism. This design choice in XHTML 2 might be fatal to the XLink standard.
Modularity
In HTML 2 forms are defined using XForms. In other posts in this weblog I am writing about XForms. Right now it is hard for me to imagine that XForms is going to be the default implementation in a major standard like XHTML. In the new philosophy it is logical to separate a form from a document definition because the nature of a form is fundamentally different from the nature of a document structure. The same way frames are defined in a separate module XFrames. A frame has nothing to do with defining a documents. It is just a convenience to the user for example when viewing JavaDoc API documents.
Adoption
The main question for the success of XHTML 2 is whether it will be used by web developers or not. There are several threats that may stand in the way of successful adoption of XHTML 2. One of the main hurdles is the learning curve for XHTML Strict and CSS. An intelligent web designer will see the advantages and learn XHTML 2. However, most of the internet is filled with content written by average users, not web specialists. The average web editor uses a WYSIWYG tool to create web pages. WYSIWYG tools give the author control for what the web page will look like. Shifting to the new paradigm where layout is defined in CSS files, the content author loses control of the layout. Many users will not easily accept a decline in features and usability of their application. Solving this issue requires more than training. Perhaps brain-washing is a more accurate description.
At this moment, most HTML editors in content management systems are layout based and use B and I tags, font types and colors etc, etc. I haven't found a proper editor for document structuring yet. An editor that integrates with any possible CSS file and still provide a WYSIWYG view while defining structure instead of layout is not easy to develop. For this issue, we'll have to wait and find out. Tips from readers are welcome by the way. Please leave a comment if you know of any effort or have experience in solving this issue.
Another risk is the required skills for developing a proper web site where content and layout are separated. Document modeling is not an easy task. Large organizations can afford to hire qualified developers. But the average web site is developed by amateurs lacking the skills and experience to define an accurate document structure presented by style sheets. What we need is proper and clever tools. I'm not a fan of Dreamweaver, but I do think it is up to Macromedia to provide the tools to use XHTML 2.
Last but not least, don't forget the adoption of XHTML 2 by browser vendors. I have faith in the Mozilla organization, they'll create new versions of Firefox imlementing XHTML 2. But it is questionable whether Microsoft's Internet Explorer will support XHTML 2 in the near future. IE has a history of implementing what the users want. There's a good chance that time is standing still and we're stuck with (X)HTML Transitional. I really hope my pessimism is misplaced and I'm wrong here. Possibly the recent community-awareness of Microsoft will convince them to follow the standards, who knows?
For now, at the time of writing, the proposal for XHTML 2 is not even final yet, so let's be patient.
Your feedback?
Even though some of the above statements may sound like I'm presenting facts, everything is my opinion. I didn't do my homework and I didn't check every detail I've written. If you disagree with my opinion or especially if you can prove me wrong, please leave a comment. I'm always interested in opposing views and I know many web developers see things differently. Most interesting is not what you think, but why you think it. Also feel free to post links to your own weblog if you have content related to this subject. I don't mind shameless self-promotion as long as it leads to interesting stuff.
Thank you for reading my text! My next article will explain when not to use AJAX. Watch the RSS feed (Atom actually). If you do not use RSS news readers yet, try the open source RSS Bandit for a while. It's dotNet, looks like Office 2003 and does what it is supposed to do.
Tags: Semantic Web | XHTML | XHTML 2 | MVC
Saturday, July 02, 2005
XForms part 2.5: OpenOffice
THIS POST IS SUPERSEDED BY A NEW SERIES OF ARTICLES ON XML TECHNOLOGIES AND XFORMS... READ MORE IN PART 5 OF THE XFORMS TUTORIAL...
Please hang on, I did not stop writing the rest of the XForms tutorial. I'm just waiting for the XForms plugin in Mozilla to mature. In the latest stable releases I do not get the repeat-elements to work. Might be my mistake, but for now I blame the plugin. I tried the nightly build, but it does not load XForms at all. As soon as I have a working version, I'll continue.
In the mean time I did try the XForms part of OpenOffice 2.0. Maybe you read about it somewhere else, but you couldn't find the functionality in OpenOffice. The feature is hidden well. A simple File -> New -> XML Form does the trick though. OpenOffice might be one of the first major applications to offer a visual interface to XForms. Like InfoPath, the average Access user should be able to use the functionality; it's not meant for your grandmother though.
My most important observation: OpenOffice does not implement the XForms user interface; only the XForms backend. Instead it uses existing forms elements from OpenOffice and connects them to the XForms backend. At first I was a little bit disappointed about this. Especially the fact that I still miss some sort of repeat-element. However, when I think about it a bit longer, I can still be enthousiastic about the OpenOffice implementation. In the past, the XForms backend has been criticized for being too heavy for client side systems - especially browsers. The OpenOffice team chose to use the XForms backend even without the rest of the spec. to support their own forms. That says something.
Main conclusion: XForms is not about a cool new forms interface for the browser that happens to carry a backend with it... XForms is a forms modelling platform providing means to implement business logic in a declarative way and adds a cool new interface as an extra.
I can hear you thinking: shouldn't business logic be implemented server side? For XForms the same rule applies as for AJAX: it is meant for convenience to the user (ease of use and responsiveness); its working and the generated input to the server should be considered unreliable at all times. Use these techniques to offer options to the user but never depend on the availability of the options. Make sure the interface still works when the option fails.
By the way, OpenOffice 2 is worth looking at anyway. The killer feature for version 1 was the "Export to PDF" option. I loved it. Instead of buying an expensive Adobe Acrobat, using some freeware tool loaded with spyware or going through hell with "Print to PostScript" and a ps2pdf converter, I can do this with a single click for free. I switched from MS Office to OpenOffice for typing by C.V. I prefer sending this as a PDF to ensure the formatting doesn't change and to prevent red lines under words like "XForms".
Another killer feature (for geeks, not your grandmother) besides XForms is "Base" providing an Access-like interface to any database accessible through JDBC. JDBC is Java's standard for connecting to databases and exists for many years. The standard is mature and is used in major enterprise applications with large numbers of users. A product that offers this functionality can exist on its own. But with the integration with other OpenOffice applications it really comes alive. I will test some more and maybe report later.
Tags: XForms | OpenOffice
THIS POST IS SUPERSEDED BY A NEW SERIES OF ARTICLES ON XML TECHNOLOGIES AND XFORMS... READ MORE IN PART 5 OF THE XFORMS TUTORIAL...
Subscribe to:
Posts (Atom)