Home

At the same time of the Eclipse announcement, Novell announced also announced the availability of Novell exteNd 5, an innovative set of service-oriented integration and portal technologies. Much of the innovation of this release has gone into the creation of a completely new, standards-based and data-binding set of frontend technologies based on Xforms and JSR 168 portlets. See the full press release at http://www.novell.com/news/press/archive/2004/01/pr04008.html and download the software from http://download.novell.com - developer versions of the product are FREE.

What does TheServerSide community think about Xforms based development? What are your opinions about appserver independent products like exteNd? Comments always appreciated...

I think Xforms is great. Currently, web development is a mesh. Everything is mixed up in web pages: presentation, data and logic with tags, scripting...The web was created to navigate through documents, not to make transactional applications, so a number of modifications to the original idea have been coming up through the last ten years to finish with we have today...garbage.
There is a need of a new generation of universal client, XML based, that let developers to make a proper engineering decisions. Xforms is a good starting point but the problem is that when you embed it into HTML, you are losing a great deal of their adventages. The whole lenguage should be revisited. Xforms can provide for data and logic but a new, separated presentation layer should be developed to get rid of the current situation.

This would not change the web, but for enterprise applications I do not see any justification about using web navigators, other that it is a universal client

I have been thinking about this for a while, and am at fundamental loggerheadwith following.

Using server to generate presentation artifacts.
Look at most often used control(s) on browser, and you can
quickly identify those to be text input fied and button (that is
nothing but html directives to render certain behavior and presentation
on browser face.

Unarguably, native OS would always have the richest presentation controls
and behavior. Only, if browser could tap those to help itself with the
presentation and behavior control.

That leads to an idea of federated presentation engine, where HTML or some
close avtaar, negotiates and decides the browser native presenation controls
available, and presents this capability matrix as part of init to the application boot strap code.
The application on boot, would then, based on this information, spit out the
presentation drivers most apt to leverage the interrogated layer, to the
maximum.
Obviously, it would be nice, if the common presentation capability could be
defined as a spec and available on all native os's. I do not think, this is
a long shot.

application's default presentation driver, would always be programmed against this default spec compliant presentation driver, and changed to higher and more
refined presentation controls, if and when available on the rendering platform.
In essence, division of labor takes place as follows
Native OS:
1) Implements all presentation controls
2) Implements a common presentation layer (spec compliant)

Browser:
1) Interrogated the native os for presentation capability and relays this
information to the application at app server end.

Application Server:
1) Generates the code, while being cognizant of the current browser's
presentation capabilities.

Benefits:
1) Application does not have to devise ingenious mechanisms for presentation
rendering.
2) Leads to division of labor
3) presentation executes, at point closest to its presence, hence best class
performance

This is obviously just a wild idea, but on analogous thoughts, JVM download, into browser, to paint swing faces, failed, because of remoteness of reality, lack of performance, plain ugly controls and lack of maturity in controls.

Just to get the story straight: XForms is *not* a free-standing markup language like HTML, SVG or XUL but XForms is just a data binding architecture and thus needs a next-gen XML host language such as SVG or XUL.

I'm evaluating XForms at the moment as a possible technology for easing portal development / interaction with our BPM engine. XML Schema is what makes this possibility exciting.

Things look promising so far, but I'd like to point out a couple things:

1) Vendors selling XForms solutions are invariably packaging those solutions along with other business components (most commonly BPM/Workflow frameworks). In our case - where we have already adopted a BPM and development framework (Weblogic platform 8.1) - there is a 0% chance I am going to approach my boss and suggest we spend that much again  for essentially a competing development environment/application framework, just to gain access to pre-packaged Novell XForm portlets. I'm getting a little frustrated with vendors inability to find the right product offering granularity. A component is a component - sell it on its own, and let architects like myself choose what we want to piece together. And keep the prices realistic too, or weve forced to either roll our own, or find open source alternatives.

2) XForms is NOT restricted to client implementations. If it was, it would have no purpose for my application, since I couldn't rely on an incoming form submission's validity. Note the title of this website... I'd like to point out that Java too was misunderstood in a similar way.

3) There are opensource J2EE server-side implementations of XForms. Its easy enough to google them, but Ill throw one URL out, which is the package Ive decided to try a proof-of-concept with first.

Also note that XForms is just a data-binding architecture and not a free-standing markup language like XUL, SVG or HTML and thus XForms requires a *next-gen* XML hosting language and a *next-gen* XML browser.

To say that XForms _requires_ a next gen xml language is misleading, especially considering that it will be the native forms engine for the w3c XHTML 2.0 spec, (finally) replacing HTML forms. So even XHTML, as thin as it is, is an appropriate host for XForms. But your comments make a great point in that they do demonstrate one of the greatest strengths of XForms, which is that XForms is extremely flexible and can be integrated elegantly into other XML based presentation technologies. This will enable a paring of technologies in which the combined whole characteristically changes the underlying technologies.
A great example of this is SVG. SVG is great as a graphics display technology and is a technology choice free from IP issues and single vendor dependencies, but it could not compete with Flash for RIA (Rich Internet Application) development because there was not an elegant way to create UI Widgets for user input. But now SVG can be the host language for an XForm, which has rich and flexible user input capabilities to supplement SVG's lightweight graphics and animation capabilities. The result is an RIA environment that is WAY easier to programmatically generate than Flash is thanks to XML, based upon open standards, and free from single vendor dependencies. Flex comes a long way, but the XML tags Flex uses to generate the UI are better seen as a custom tag library, not a markup language based upon XML and backed by a schema (a la HTML). The difference is critical, and becomes most apparent when you are programmatically generating the markup for presentation. We programmatically construct HTML so easily that we take it for granted. The custom tag approach necessitates a completely different model where the developer is sitting there coding each display document and using these tags to do so. So if you have a presentation tier that dynamically constructs presentation flows based upon declarative metadata, XForms would be a better choice.
I am far from being an expert on XUL (or presentation tier technologies in general), but for what it's worth, the biggest problem that I can see with an XForm-XUL integration is controller logic conflicts. Who is driving the process? Who controls the event model? XForms and XUL are both designed with the presumption that they are driving the event model. Also, why does XUL need XForms? It already has a richer widget set than XForms, and I am struggling to find the value that XForms would provide in an XUL context. A better candidate for XForms integration would be a technology that does not attempt to address the whole stack of UI construction concerns, but instead focuses on presentation and then communicates with the XForms engine via XML Events or JavaScript (ie XHTML or SVG).
On last thing - the best thing about XForms is the way that it simplifies the server side. One feature in particular: support for multiple page flows within the context of a single request. The user can request your form, transition through a number of pages on the client without needing to talk to the server, and when the user submits the client sends ready-to-go XML back to the server. That means no need for a finite state machine in the application tier to manage user navigation, no more chatty and poor performing clients, and significantly reduced complexity in request processing logic because you are starting with the XML.

Thanks for posting back. I think that we completely agree with each other, but just to be clear, according to the w3c Working Draft XHTML 2.0 will run in 95% of the existing browser base without modification. So the "burns all bridges" statement should not infer that HTML loses it's greatest strength, which is the existence of a universal thin client. From what I can see, XHTML 2.0 is focused on two major objectives: 1) the completion of the long migration towards CSS for presentation styling (as opposed to HTML attributes), and 2) fully embracing XML and the modularization/integration that it provides. If you already make use of XML compliant HTML and you use CSS for styling, you are already well on your way. Also, browsers will be able to support both XHTML 1.x and 2.0 at the same time, so the burning bridges statement should also not infer that architects will have to choose between one or the other.
There is a caveat to the backward compatibility statement, which ironically enough involves XForms itself as well as a couple of other new modules. The new modules: XForms, XML Events, and Ruby (which is a module for displaying the Chinese character set) will not be supported by current browsers, just as HTML tables weren't supported by everybody when they were first introduced. But that is not to say that the rest of XHTML 2.0 won't work fine in your browser.
Also, I did not intend to give the impression that XForms is dependent on XHTML 2.0. Perhaps a better example to demonstrate that XForms does not require a next gen markup language would be XHTML 1.x, which I assumed was a given since that is how production XForms implementations are deployed today. XHTML and XForms do not have integrated namespaces yet, but that doesn't stop XHTML 1.x from being a fine host language for XForms. Because most of the current browsers do not have XForms capability you will need a plugin until browser support is native, which admittedly makes my universal thin client argument pretty week once XForms is thrown into the mix. So we completely agree on that front. There is an existing mozilla bug to make XForms support on Mozilla/Netscape native. IE is another story, and I have no idea if Microsoft will see XForms as a competitor to XAML and therefore limit support for it. Most of the current XForms plugins specifically target IE, so there would be a workaround, although I think you would agree that plugin dependencies should be a last resort.
On your other post, I am disappointed that you do not see value in XML Events or the forms capabilities that XForms provides. We may have to agree to disagree on that one.

Again, thanks for posting back. Out of curiosity, are you involved in the XUL project? If so, are you guys going to try and converge with XAML, perhaps providing an open source implementation? Or alternatively have the XUL engine also support XAML? That would be great. I think there would be a lot of synergies with the Mono project if you guys decide to take that on. Best of luck.

Out of curiosity, are you involved in the XUL project? If so, are you guys going

> to try and converge with XAML, perhaps providing an open source implementation?
> Or alternatively have the XUL engine also support XAML? That would be great. I
> think there would be a lot of synergies with the Mono project if you guys decide
> to take that on.

PS: To answer your question about XUL: I'm not involved in Mozilla XUL other than promoting it and pushing for change. However, I'm the XUL Alliance webmaster and head the Luxor XUL Toolkit project. I suggest using xul-talk because several Mozilla XUL guys such as Ian Hickson are subscribed to xul-talk and don't read TSS for sure.

Also, why does XUL need XForms? It already has a richer widget set than XForms,

> and I am struggling to find the value that XForms would provide in an XUL
> context.

Mark, XUL and XForms go together. XForms basically is just a data binding architecture that lets you load and save (send and receive) XML data (=XML in, XML out). All the rest that comes with the XForms 1.0 spec such as its widget set or XEvents model is just useless bloat.

IMHO XForms is not fully understood. XForms has an XML section which is the data model for the form and a second section that contains the logic with which the end-user interacts with the form. This section IS NOT ABOUT WIDGETS. They are outside the scope of XForms. The user could interact with the form with a voice application for example. Then, you have conditionals, iterators, calculated values and a number of other nice features. This is the beauty of XForms.

On the other hand, for the desktop, you need to map XForms controls to widgets that will have their look and their layout. This part is not in the standard. As you put XForms as part of XHTML 2.0, the whole thing is covered but it seems to me that the logic part of XForms is meshed up with presentation, we lose the separation of presentation and logic. XUL is really mainly about widgets and does not have much about logic or data separation.

I guess they have to make up for their purchase of SUSE & Ximian somehow: "The Professional Suite is available for $50,000 per CPU, and the Enterprise Suite is available for $120,000 per CPU...". Of course, just get your CEO to take a .1% pay cut and it's paid for!

I thought it was pretty interesting that the demo is Web Start Java application (or a download - http://developer.novell.com/xforms/) that the XForms run in. And the windows that popup aren't XForms - they're Swing.

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.