W3C home > Mailing lists > Public > www-forms@w3.org > March 2001

Re: Fw: XForms requirements

From: Bruce Atherton <bruce@hagbard.flair.law.ubc.ca>
Date: Mon, 26 Mar 2001 15:10:15 -0800
Message-Id: <5.0.2.1.0.20010326144737.030f5018@flair.law.ubc.ca>
To: "John J. Barton" <John_Barton@hpl.hp.com>, Bruce Atherton <bruce@hagbard.flair.law.ubc.ca>, Berin Loritsch <bloritsch@apache.org>, XForms Mailing List <www-forms@w3.org>
At 02:34 PM 26/03/2001 -0800, John J. Barton wrote:
>At 02:03 PM 3/26/2001 -0800, Bruce Atherton wrote:
><snip>
>>XForms is designed for defining the UI of three-tier applications, not 
>>for client/server applications. Trying to shoehorn in client/server 
>>support would IMHO be a very Bad Thing because client-server and 
>>three-tier are fundamentally very different things on the client side.
>>
>>Some might feel that XForms is even more narrowly designed, so that it is 
>>only intended for browsers connecting to web applications. My hope is 
>>that people will recognize that there is enough overlap in design that 
>>the more general solution for three-tier environments can be accommodated.
>
>Bruce, can you elaborate your definitions of client/server and three tier
>in this context and explain how XFORMs can be used in the way you envision?
>I'm confused by the idea that XFORMs for client server would be a Bad Thing
>and yet XFORMs for web applications might be the "only" intension.

Sure, so long as you keep in mind that this is just one guy's opinion. 
First, let's make sure we are talking the same language.

If you set up a client that directly accesses the backend in a typical two 
tier environment, then all of your business logic needs to live in the 
client (unless you use a hybrid app-server/database). Want to change your 
pricing algorithmically based on which customer you are selling to? Then 
the client needs to do that work.

In a three-tier environment, you can keep the business logic out of the 
client. Your client, in fact, can be nothing more than a User Interface. 
That is how HTML forms (without Javascript) work. They just set up the User 
Interface, but they do nothing to try to implement business logic. They are 
pure "View".

Of course, HTML forms by themselves aren't enough. We need some amount of 
logic in the UI since we want to limit the types of values elements can 
have, control when widgets become enabled, etc. What I was referring to as 
the UI Model as opposed to the Application Model. HTML forms also don't 
offer a rich enough UI to be used as the front end for most applications.

So modifying XForms to include all the business logic that belongs on the 
middle tier is a Bad Thing because it breaks that nice intuitive separation 
of the client as the View from the rest of the application.

My concern, though, is that by assuming that the XForms UI components are 
only working in a browser-type environment and providing only forms, you 
lose the richness that other applications and clients may require. This is 
why I was asking whether there were plans to support Windows and Dialog 
Boxes. What I would like to see is the UI elements that forms would not 
necessarily require, but that other applications would, supported within 
XForms. Perhaps integrating XUL and XForms, for example.

So far, I haven't seen much support for the UI requirements of more general 
applications in the XForms spec. That is why I made that (obviously 
unclear) comment. I hope I am wrong.
Received on Monday, 26 March 2001 18:29:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:21:48 GMT