Re: Fw: XForms requirements

Michael Friedman wrote:
> 
> Berin wrote:
> 
> > 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?
> 
> I don't care.  This is an implementation detail.  The user does not care if
> you implement with one form or many.  He cares about what he experiences.
> 
> What I care about is that it should be easy to build multi-level business
> forms (ie. parent-child-grandchild) so that as the user navigates through
> the parent and child the child and grandchild data stay coordinated.

That is what I was referring to.  This is the responsibility of the XForms
processor.  It is also the void that I am gearing ExFormula to fill.

> For example, if the user changes child data and then goes back to the parent
> and hits next row that should automatically send the changed child data back
> up to the server.

Right.  XForms is supposed to allow for the idea of multipage forms.  So it
means that the form is partially processed a bit at a time.  It is not clear
from the spec how this is accomplished.  However, I am leveraging techonologies
already developed (Apache Cocoon 2) to handle these implementation details.

I am using XForms as a common markup for the forms.

> What about autoquery blocks?  As the user moves to a new parent row the
> associated child rows should be automatically populated.  Probably in groups
> (ie. bring back first 10).  Then if the user navigates to the child records
> and down to the bottom of the form the form should automatically pull back
> another block of 10 rows of child data.

IOW, the concept of an Inbox, or any form with many items available and you
want to view only a portion at a time.  This can come from dynamically building
the form a bit at a time--which is what I am doing with Cocoon.

> In a business forms platform this kind of coordination is built into the
> platform - form designers just have to define the data bindings and specify
> parameters like how many rows to bring back at a time.

I see your point.  At this time, it doesn't look like it is specified in
the XForms spec.  That definitely should be.  Basically, a list view by
describing what a line in the list would look like.

> It seems that in XForms the form designer will have to build this into every
> form.  This makes building significant business forms directly on XForms
> almost impossible.  XForms becomes, at most, an infrastructure layer used by
> higher level forms controllers.  But in that case, don't we lose much of the
> value of having a standard?

Not entirely.  If we have a common language to speak, then it will make things
alot easier for integration in the long run.  What happens when you have a
requirement for a Non-Oracle database?  You lose the advantage of PowerBuilder.

I think this discussion helped draw out exactly what you wanted.  I am not
an official member of the committee, but we both want the same thing, and I
would like to work with you on how best to accomplish the goal.

I would also like support for the concept in the XForms proposal.

> 
> 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@echinachem.com>; "XForms Mailing List"
> <www-forms@w3.org>
> Sent: Monday, March 26, 2001 11:04 PM
> Subject: 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:54:17 UTC