Re: Fw: XForms requirements

Michael Friedman wrote:
> 
> Berin,
> 
> I'm not really worried about all the widgets.
> 
> I want things like parent child block coordination, binding as you discuss,
> etc.

By parent child block coordination, are you talking about a form with both
header information and line item information, or are you talking about a
form that has other associated forms?

For example:

We have developed a web application that has four major types of forms.  Each
form has global header information (transaction name, run dates, etc.).  Each
form also has line item information (line item name, UPC code, value, dimensions,
etc).  In this respect each form has a Parent/Child relationship.  However,
one form can also include two of the remaining forms depending on business
logic.

That means that the other forms are children of the parent form.

Are you limiting that to header/line-item, to parent form/child form, or
including both?

The header/line-item approach can be accomplished by making your model have
repeatable sections.  I don't think the Model allows for heirarchical models
or composite models (i.e. one model inheriting from another, or one model
made of other smaller models).

I would like to see this included.

> I don't actually think that binding to EJBs is really any harder than
> binding to a database or fundamentally different.  For example, the latest
> version of Oracle Developer can bind form blocks to tables or to database
> stored procedures.  That's not very different from an EJB.

My point is that the binding to data has to be flexible enough.  It all
depends on how the XForms processor creates instances of the model.
If you have your XForms processor grab instances from a URL, then it is
up to the processor to determine how to create and populate the instance.
That is one of the main focusses of my ExFormula project
(http://exformula.sourceforge.net)--keep in mind there is no code yet,
and it started days ago.

If you have any ideas on this front, I would like to here it.

> But what about things like tying error returns to individual rows of user
> entered data?

That's a good point.  Again this is the responsibility of the XForms Processor.
The processor has to make sure all constraints are correct before moving on.
That means that if the processor is client side, the client has to identify
the error conditions to the user.  If the processor is server side, then
the same form needs to be sent back to the user, with the error messages.

The thing that XForms does not identify in the DCL that should be identified
is how to express the error conditions to the user in a way they can
understand.  Even if it is only a reportError("condition") function.  The
DCL does have a mechanism for expansion.

> Mike
> ----------------------------------------------------------------------------
> ----
> Michael Friedman
> mfriedma@alum.mit.edu
> +852 9458 6060
> www.Michael-Friedman.com
> 
> Maintainer of the B2B_HK mailing list for B2B in Hong Kong and Greater
> China.  Send e-mail to b2b_hk-subscribe@egroups.com to subscribe.
> 
> Maintainer of www.eChinaB2B.Net - the directory of B2B companies in Greater
> China
> 
> ----- Original Message -----
> From: "Berin Loritsch" <bloritsch@apache.org>
> To: "Michael Friedman" <mfriedma@alum.mit.edu>
> Sent: Monday, March 26, 2001 10:23 PM
> Subject: Re: Fw: XForms requirements
> 
> > Michael Friedman wrote:
> > >
> > > With Micah's permission I'm posting this to the list.
> > >
> > > Quick summary:
> > >
> > > My concern is that the requirements do not make clear whether the
> objective
> > > is to do a better job of handling forms of the type that are currently
> done
> > > on the web and marginally increase the complexity and power of the forms
> we
> > > can use or if the objective is to let people build powerful and complex
> > > forms with tight database integrations like the ones people build with
> > > Oracle Developer, PowerBuilder, etc.
> >
> > It appears to me that XForms is trying to provide a pure XML MVC (Model
> View
> > Controller) pattern.  That means that you have the XForms Model (The model
> > portion), XForms DCL and processor (the controller), XForms UI (the view).
> >
> > The separation of the Model and the Controller has alot of overlap, and I
> am
> > not that crazy about that part.  The "richness" of the XForms UI section
> > leaves alot of things missing--I think part of the design.  The reason is
> that
> > they are trying to cater to the smallest subset available (wireless
> devices).
> > The Model describes XML schema and dynamic constraints/calculated fields
> > for a data instance.  The instance is XML that conforms to the XForms
> Schema.
> >
> > It is up to you to bind the instance to a real datasource.  That is one of
> the
> > major shortcommings of XForms.  The other is that it assumes that the
> prefered
> > method of dealing with XForms is through a DOM.
> >
> > > My concern is that the need is for the latter, but the requirements
> cater
> > > more to the former.
> >
> > The requirements are still young.  You also have to keep in mind that
> Database
> > integration is only one type of data binding.  What about mapping to EJBs
> or
> > CORBA objects?  There are other standards that deal with that mapping.  I
> am
> > looking at a public domain one that maps XML to a DBMS.
> >
> > That is also part of the limitation with the XForms Model.  The Model
> assumes
> > nothing other than XML integration.  What is needed is a standard binding
> language
> > that will conform XML to an arbitrary backend--whether it is object based
> or
> > table based.  I have not looked at XBL (XML Binding Language) yet, but it
> could
> > possibly fill this void.
> >
> > > I would really appreciate it if some of the people involved in the
> standard
> > > could look at some of the more complex forms in the client/server
> versions
> > > of Oracle Financials, Peoplesoft, or SAP and ask themselves if XForms
> can be
> > > used to duplicate that functionality with a reasonable effort.
> >
> > If you are talking about rich form controls that you would normally get
> with
> > an application setting, I am not sure how that would be approached.  You
> would
> > almost need a conformance level: embedded devices have to enable the core
> set
> > of UI controls, browser enabled deveices may have to enable a few more,
> and
> > lastly, stand alone applications would have to enable yet another set.
> >
> > I don't know how desirable that is.  Maybe we could take a look at how
> many
> > distinct UI controls there are in use in today's GUIs.  The XForms spec
> makes
> > reference to a few more, but they have not been worked out as of the
> writing of
> > the spec.
> >

Received on Monday, 26 March 2001 10:06:48 UTC