- From: Bruce Atherton <bruce@hagbard.flair.law.ubc.ca>
- Date: Tue, 27 Mar 2001 10:58:18 -0800
- To: "Michael Friedman" <mfriedma@echinachem.com>, "XForms Mailing List" <www-forms@w3.org>
At 11:31 AM 27/03/2001 +0800, Michael Friedman wrote:
>Bruce, if I want to put a heavy duty order processing application on the
>web, is XForms supposed to be something that I can use?
I would hope so.
>If so, is it something that I am supposed to use directly or am I supposed
>to use a higher level forms application that generates XForms automatically
>for the browser?
I'm not clear on what you mean by a "higher level forms application". It
sounds like you are talking about server-side tags. I don't see how keeping
business logic out of the client implies server-side tags.
If, OTOH, you are talking about the fact that XForms use XML rather than
supporting serialized Java objects or ODBC result sets, then I agree that
this is a restriction but don't agree that it is onerous. Even in a
client-server architecture, the client needs some mechanism for
communicating with the database. That communications mechanism can be
through a web service delivering XML as easily as anything else. And if you
don't want to define a DTD for your particular data, it can be completely
generic, like so:
<resultset>
<row>
<col name="CUST_NAME">Acme Explosives</col>
<col name="ACCT_BALANCE">-12850.25</col>
</row>
</resultset>
>If the answer to the second question is "Yes, use it directly" then I don't
>think you have succeeded.
Since I haven't done anything but request a slightly broader focus for
XForms, I can't claim to have succeeded at anything in this context.
But those who have designed the XForms spec so far seem to have, unless I
am just missing your point. Why do you think you cannot use XForms directly
in a heavy duty order processing application?
Received on Tuesday, 27 March 2001 14:00:34 UTC