Input on several features/wishes: version management, building blocks etc

>> Version management
>> Orbeon default stores forms in the eXist database. Is there a way to
>> manage different versions for forms using this database? Can yo
>> recommend alternatives if version management is not supported. If we
>> really want version management, what do you think about using
>> Subversion. Can we use the REST Web API for that?
>
> The eXist persistence layer does not support versioning at the moment.
>
> The Oracle XML kind of does, in that it keeps older versions. But this is
> not visible at the level of the REST API.
>
> See also this section on the wiki, which I just updated:
>
> http://wiki.orbeon.com/forms/doc/contributor-guide/form-builder-integration-notes#TOC-Support-for-versioning
>
>> Generic building blocks for forms
>> Is it possible to construct a form from pre-defined form components?
>> We would like to be able to define and use reusable chunks of forms
>> definition, logic and validation.
>
> We have basic support for this, in the form of what we call Section
> Templates:
>
> http://wiki.orbeon.com/forms/doc/user-guide/form-builder-user-guide#TOC-Section-templates
>
> (Note that this Form Builder guide is being written as we speak.)
>
>> Different forms variants
>> Is it possible to create different variants of a form for different
>> types of users using some kind of extension mechanism. We want to be
>> able to create a generic form and then allow some users to make
>> changes to it, to make it specific for their purpose. Ideally it would
>> be possible to keep track some how of the changes made and merge them
>> if a new generic version is made available. I thought about using
>> Subversion for version management, I thought we could then also use it
>> to support different variants for a form by branching in Subversion.
>
> Currently there is no such extension mechanism.
>
>> Wizard
>> Is it possible to present a form as a wizard using multiple screens
>> and some kind of progress indicator.
>
> This is an oft-requested feature, but we don't have it yet. One approach was
> to:
>
> * Allow for sub-sections in Form Builder
> * Allow for top-level sections (possibly other sections) to be represented
> as a wizard
>
>> Validations
>> Is it possible to do multi-field validations. What functionality is
>> there to do create custom validations e.g. using Javascript?
>
> Could you precise "multi-field validations"?
>
> You can write custom validation using XPath expressions or schema types in
> XForms.
>
> We don't really have support for writing validation rules in JavaScript.
>
>> Saving form state
>> If the user does not submit directly, is the forms state maintained?
>> Or does the user have to fill in all fields anew?
>
> You have the notion of "saving" the form and "submitting" the form to a
> service. This might help.
>
>> Is it possible to
>> fill in a form without a internet connection?
>
> We have some code in the XForms engine for offline support using Google
> Gears, but this is not integrated in Form Runner yet.
>
>> Business rules
>> Do you of applications where Orbeon was used together with a business
>> rule framework/engine.
>
> I don't think we have particular recommendations on this point.
>
> -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
>
>

> already
> doing this, but to assist in your thinking of versioning and how to  
> select
> versions here is a technique we have built into the schema for this.
>
> The issue for us is that instances may be created with one version  
> of a
> schema/form at one time and another version at another time.  
> However, we
> still need to edit instances created with older versions later and  
> they are
> essentially treated as the same thing from a users point of view.
>
> What we are doing is to add a <VersionText/> tag to our schema with  
> a fixed
> text value of the version string. Any instance created against this  
> schema
> will not validate unless it has that tag with the specific fixed  
> value. This
> has some advantages, including that the instance specifically  
> declares the
> version it was created with, and this allows the schema file name  
> itself to
> remain constant.
>
> It then is a (relatively) simple matter to read the value of this  
> version
> tag for any particular instance. For example, in order to display the
> instance with the correct form for editing.