Forms (Talk)

[pmonks1]

(Peter Monks - 2008-03-27)

Has there been any thought / discussion around separation of data model from UI?

Over the years I've heard people who both like and dislike this approach, but some existing CMSes work this way and it has some distinct advantages (eg. allowing multiple different form UIs for generating the same underlying data structure - this is a classic role-based content entry requirement).

It'd be ideal if we could still auto-generate a generic form directly from the data model (the 80% case), but with 2.x Web Forms the inability to get into the XForm and customise at that point in the process has been a problem for some users of Alfresco (not the majority, mind you).

Continuing on a little further, my $0.02 is that XML Schema is a pretty good data modeling language - better than relational, better than proprietary XML based data description languages, and far better than proprietary non-XML data definition languages.

Although vanilla XML Schema is a pretty good constraint language, it'd be good if we added support for something like Schematron on top.  It's very non-intrusive (Schematron is implemented as XSD annotations, like our widget stuff), but adds a lot of expressiveness on the constraint front.

Oh and we should also allows customers to turn on validation of documents created via forms - at the moment it's easy to define a 2.x Web Form that generates documents that don't validate against the original schema, which causes some consternation.  😉

Also - here are some JIRAs which capture additional requirements around forms: WCM-380, WCM-517, WCM-518, WCM-979, WCM-980.  Many of them are expressed as being WCM specific, but they really apply to all forms regardless of the use case.

(Peter Monks - 2008-03-29)

Here's an interesting forum post related to this: http://forums.alfresco.com/viewtopic.php?t=11723.  My take is that XML Schema is probably not the right technology to underpin a 'business-user friendly' form building UI, but that XForms might (being a more directly form-focused technology, so less impedance mismatch).

Perhaps an ideal solution is for the fundamental forms technology to support configurability of both XSDs and XForms, but also support auto-generation in either direction.  In other words if I upload an XSD without any XForms, a default generic XForm is auto-generated (which is what we do today).  Similarly if I upload an XForm without a backing XSD, a default generic XSD would be auto-generated from the XForm definition (the inverse of what we do today).  On top of that, I'd also have the option to upload both an XSD and one or more XForms, thereby bypassing any kind of auto-generation.

One detail that would have to be worked out is how the dynamic include functionality would fit in with this - eg. it'd need to be possible to dynamically include at both the XSD level and the XForm level.  This is pretty important functionality (it's critical for things like dynamically generated default values, dynamically generated dropdown lists etc.) so deprecating this functionality isn't really an option.

That said the current dynamic include mechanism (including JSPs from the Web Project) is a kludge and causes many problems in practice.  It would be preferable to deprecate that mechanism and switch to web scripts for includes instead (see WCM-555).  In fact being able to specify that the entire XSD or XForm for a Form is generated in its entirety by a web script would also be valuable.

(Peter Monks - 2009-02-16)

Some things I'd like to see described in a bit more detail:

• Role based UIs - will it be possible to define multiple forms for the same underlying data type, with the form picked at runtime based on the user's role?
  
• How will nested complex types (as available in 2.x Web Forms) be handled, both in the API / Service layer and the UI layer?
  
• Will validity rules that have granularity other than field-level (eg. form-level or repo-level) be supported?
  
• Customisation / extension points - where can we extend / customise and how is it done?
  
  • UI widgets (ala Web Form widgets in 2.x) - how are these implemented, deployed, selected in form definitions, etc.?
    
  • Form layout - will it be possible to control the full visual design of a form?  Example form layouts that are commonly requested:
    
    • Tabbed forms
      
    • Wizards
      
    • Freeform layout (fields organised into groups and/or columns)
      
  • Pluggable persistence layers (DM vs WCM vs relational vs other)
    

Please refer to some of the JIRA tickets linked above for more details on the kinds of things we require from the Forms Service.

(Gavin Cornwell - 2009-02-17)

80% of your questions above should be answered by the time this page and it's corresponding developer page have been fully written. We are still discussing the roadmap for the WCM forms so I have no definitive answer for that yet, but the approach we are taking should lend itself nicely to all the comments above i.e. the data model/service is separate from the UI.

(Peter Monks - 2009-02-17)

Great!  I'll keep an eye on this page as it evolves.