best practices for splitting form data from reference data?

The problem is typical: a form to be filled needs to specify the valid
enumeration values for some fields (usually coming from a database).
How this reference data is stored has implications on how the xform is
designed.

(1) Use different models: one for form data, another for reference data.

I haven't tried it yet, are there any known bugs/limitations in the
support for multiple models?

(2) Use one model with two instances: one for form data, another for
reference data.

implication: references to model fields will have to start with an
instance selector, like instance('form-data') or
instance('reference-data'). This is cumbersome and error-prone for the
people coding the form.

(3) insert the values inside the definition of the UI control (like in
the typical samples for select and select1).

implication: the view section is tied more with the data model. I'd
prefer a stronger separation (such as the control only to have a
nodeset reference to the source of data).

These are only some criteria, there are likely others as well. I've
seen all of the above approaches in various tutorials or examples, but
haven't seen a more thorough discussion on the tradeoffs.

I'd appreciate your thoughts.
JL


--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws

Jean Luc wrote:
> The problem is typical: a form to be filled needs to specify the valid
> enumeration values for some fields (usually coming from a database).
> How this reference data is stored has implications on how the xform is
> designed.
>
> (1) Use different models: one for form data, another for reference data.
>
> I haven't tried it yet, are there any known bugs/limitations in the
> support for multiple models?

There are always bugs ;-) But we routinely use multiple models with
Orbeon Forms.

The main limitation is that in theory, you can't access data
cross-models. We overcome this limitation in part with an extension
function, xxforms:instance(), which gives you access to other models'
instances.
I think you should use itemsets rather than individual items in the
view. This allows you to load this reference data in the model by using
XForms submissions or xforms:instance/@src. You can also leverage
read-only and shared instances this way:

http://www.orbeon.com/ops/doc/reference-xforms-2#xxforms-readonly

Whether you put the instances for this data in the same model or in a
different model really is up to you. The main benefit of putting this in
a separate model is if you want to reuse that model in multiple pages.
Then you can do so simply with XInclude.

-Erik

--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/


--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws

Jean-Luc, here's my tuppence-worth:

1) Multiple models:
As far as I know, there should only be one model per form.  I think the ability to create more than one model exists to allow you to create multiple forms in the same XForms document, so you probably wouldn't want to create another model just to store reference data (unless you needed to share common reference data across multiple forms perhaps).

2) One model, separate instances for form and reference data:
This is what I usually do, as I like the way it separates out the form from the reference data.  Although you do have to use an instance selector, you can set up an xforms:bind in the model then reference the binded nodeset using an xforms:itemset/@bind in your select/select1 control.  You can then reuse commonly used enumerations (e.g. Yes/No) from multiple places in your form without using the instance selector.

3) Insert the values inside the definition of the UI control:
I agree, embedding the data items directly within the control does move away from the idea of separating the model and view.  One advantage of this, however, is that you can listen for an xforms-select/xforms-deselect event on an individual data item and set up an specific action to deal with the event (although I haven't tried this using Orbeon Forms yet).

Cheers, Dan

Dan Godley
Standards Developer
Origo Services Ltd



-----Original Message-----
From: Jean Luc [mailto:[hidden email]]
Sent: 08 November 2007 03:18
To: [hidden email]
Subject: [ops-users] best practices for splitting form data from reference data?

The problem is typical: a form to be filled needs to specify the valid enumeration values for some fields (usually coming from a database).
How this reference data is stored has implications on how the xform is designed.

(1) Use different models: one for form data, another for reference data.

I haven't tried it yet, are there any known bugs/limitations in the support for multiple models?

(2) Use one model with two instances: one for form data, another for reference data.

implication: references to model fields will have to start with an instance selector, like instance('form-data') or instance('reference-data'). This is cumbersome and error-prone for the people coding the form.

(3) insert the values inside the definition of the UI control (like in the typical samples for select and select1).

implication: the view section is tied more with the data model. I'd prefer a stronger separation (such as the control only to have a nodeset reference to the source of data).

These are only some criteria, there are likely others as well. I've seen all of the above approaches in various tutorials or examples, but haven't seen a more thorough discussion on the tradeoffs.

I'd appreciate your thoughts.
JL

E-mail disclaimer

The information in this e-mail is sent in confidence for the addressee only and may be legally privileged. Unauthorised recipients must preserve this confidentiality and should please advise the sender immediately of the error in transmission and then delete this e-mail. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on its content is prohibited and may be unlawful.

Origo Services Limited accepts no responsibility for any loss or damage resulting directly or indirectly from the use of this e-mail or the contents.  It is your responsibility to scan for viruses.  Origo Services Limited reserves the right to monitor e-mails sent to or from addresses under its control.  When you reply to this e-mail, you are consenting to Origo Services Limited monitoring the content of the e-mails you send to or receive from Origo Services Limited.  If this e-mail is non-business related Origo Services Limited is not liable for any opinions expressed by the sender.  The contents of this e-mail are protected by copyright.  All rights reserved.

Origo Services Limited is a company incorporated in Scotland (company number 115061) having its registered office at 4th floor, Saltire Court, 20 Castle Terrace, Edinburgh EH1 2EN.



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws