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...
Rik Van Bruggen
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
There is a need of a new generation of universal client,
> XML based, that let developers to make a proper engineering
Right on. Enterprise applications are long overdue for a universal XML application language. I'm surprised Gerald hasn't replied to this yet with a plug for XUL. :o)
> for enterprise applications I do not see any justification
> about using web navigators, other that it is a universal client
And that one justification is all-important. We are all writing web applications not because the web browser is easy to program, but because the browser is the only universal client
Small intranet apps might get away with some client installation (JVM, Flash, ActiveX, etc). Big intranet apps, and ~any~ extranet or Internet app, ~must~ deploy to web browsers. With an installed base of billions, the web browser isn't going away in this decade.
But that's OK. With a properly engineered presentation layer
, web browsers can handle much more than the limited concepts in Xforms.
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
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
1) Implements all presentation controls
2) Implements a common presentation layer (spec compliant)
1) Interrogated the native os for presentation capability and relays this
information to the application at app server end.
1) Generates the code, while being cognizant of the current browser's
1) Application does not have to devise ingenious mechanisms for presentation
2) Leads to division of labor
3) presentation executes, at point closest to its presence, hence best class
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.
Right on. Enterprise applications are long overdue for a universal XML
> application language. I'm surprised Gerald hasn't replied to this yet with a
> plug for XUL. :o)
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.
To find out more about XUL (XML UI Language) check out the XUL Alliance site online @ http://xul.sourceforge.net
or catch the latest XUL buzz live from the XUL News Wire online @ http://news.gmane.org/gmane.comp.lang.xul.announce
but because the browser is the only universal client.
Which is weird because I can't count(like the stars in the sky) the number of products that only support one browser (IE). In my mind, it makes it not that universal.
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 weve 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. Its easy enough to google them, but Ill throw one URL out, which is the package Ive decided to try a proof-of-concept with first.
Id be extremely interested in hearing from others especially BEA portal, or JSR 168 users who are one a similar journey.
a completely new, standards-based and data-binding set of frontend technologies
> based on Xforms and JSR 168 portlets.
Rick, does Novell plan to support next-gen XML markup languages such as XUL (including Macromedia XUL - aka Flex or Microsoft XUL - aka XAML) or SVG?
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.
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.
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.
Mark, I hope you realize that XHTML *2.0* is a next-gen XML markup language. XHTML *2.0* burns all bridges and won't be backwards compatible with XHTML *1.x*.
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.
Mark, I invite you discuss your questions on the xul-talk mailinglist hosted at the XUL Alliance site at sourceforge online @ http://xul.sourceforge.net
You can subscribe/unsubscribe to xul-talk at any time online @ http://lists.sourceforge.net/lists/listinfo/xul-talk
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
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.