Brainstorming Data Form Definitions

DataForms tables are awkward and limiting

Problems:

• Types and their modifiers are a little awkward (thinking of select+multi+values...etc). This could be richer.
  • Consider plugins which would like to add web-2.0 stuff, E.g. googlemaps formfield type: do we have a decent way for the user to apply modifiers to a hypothetical googlemaps field type? (assuming the formfield value would just hold whatever would go into the google maps search box):
    • Pre-set Flikr & Wikipeida items
    • Pre-set satellite vs map view vs hybrid view
    • Control size of map widget for display
• Attributes column is hard-coded to single character boolean-true-if-present implementation. Yet this is where most of the modifier info for a formfield type should be going.
• Feeding in large/rich content (eg. from external topics) for the values or tooltip field is difficult and fraught with problems.
• Controlling the way formfields are rendered for view and edit is unwieldy. Vast majority of foswiki users/admins will have to live with their default look. Example customisation I'm sure most wiki app developers would like to do more easily:
  • Make textareas appear below the fieldname heading, instead of beside it in a key:value 2-column table layout.
  • Merge some smaller state fields (eg. something that is just a select, couple of radio buttons or checkboxes) into fewer lines.
  • Break up formfields into groups, possibly separated by chunks of help text, possibly using jquery tabpanes as MichaelDaum does in NatSkin

Background: attributes for WYSIWYG formfields

I hope an attributes column could look something like:

M, EDITOR=TinyMCEPlugin+styles+headings+lists, H

Over in the Type column, would be a policy for the HTML2TML part that did something like this:

textarea, tml=strict+notables

Problems with attributes column

Currently the attribute column consists of a number of non-space characters, and is scanned using m/M/ and m/H/. Thus the syntax of the base attributes column can be defined as a set of single-character boolean attributes separated by \W*. If we take that as the "compatibility baseline" then we have absolutely no scope for more sophisticated syntax in that column (I have seen "Mandatory Hidden" in that column before now). So, I can't see any alternative to adding a new column, to support the extended attribute syntax Paul is proposing. Proposal:

The extended attributes field is a comma-separated set of strings, using decimal URL-style encoding of dodgy chars (to allow for inclusion of TML, newlines etc). Extended attributes override "old style" attributes. For consistency, %META:FILEATTACHMENT should be extended (documented) the same way, even if we don't implement it immediately.

I just went and read the code for the form schema "parser", and am struck how shite it is. When I think of the problems I've had in the past with ludicrously wide form table rows and nasty characters, it makes me think it may be better to deprecate the whole form schema style, and replace it with something more structured (and memorable). For example, leveraging TML (as I did in Config.spec):

---

Question

• Type: select+new
• Help: Ask questions to try and determine what I'm thinking about
• Size: 3
• Value: Animal,Vegetable,Mineral
• Attrs: Mandatory

Answer

• Type: textarea
• Help: Write your answer here using words of one syllable or less
• Size: 10x30
• Attrs: Editor=TinyMCEPlugin+styles+headings+lists

---

or even JSON, which would help with client-side:

[
 { name: 'Question',
  type: 'select+new',
  help: 'Ask questions to try and determine what I\'m thinking about',
  size: 3,
  value: [ 'Animal', 'Vegetable', 'Mineral' ],
  attrs: { 'Mandatory' => 1 }
 },
 { name: 'Answer',
   type: 'textarea',
   help: 'Write your answer here using words of one syllable or less',
   size: '10x30',
   attrs: { 'Editor' => 'TinyMCEPlugin+styles+headings+lists' }
 }
]

Though I suppose that could be generated on demand.

-- CrawfordCurrie - 20 Feb 2010

Ooh, just had an idea:

%JQREQUIRE{"chili"}%
%FORMFIELD{"Question"
  type="select+new"
  help="$include(HelpForQuestion)"
  size="3"
  value="Animal,Vegetable,Mineral"
  attrs="Mandatory"
 }%
%FORMFIELD{"Answer"
   type="textarea"
   help="Write your answer here using words of one syllable or less"
   size="10x30"
   value="$include(DefaultAnswer)"
   attrs="Editor=TinyMCEPlugin+styles+headings+lists"
 }%

-- CrawfordCurrie - 20 Feb 2010

Great ideas, but I think it should be %DEFINEFORMFIELD%.

I do not like the macro approach. I think it makes it even less accessible to Foswiki newcomers than an obscure table syntax.

I really like the usability of headings + lists. This philosophy reminds me of YAML, which I know from my past non-programmers are easily able to grasp (well, simple array-or-hash YAML anyway). And the added benefit is that it can be edited in WYSIWYG without any macro code:

Below, I try to make examples that would be roughly equivalent with YAML's three basic data structures: scalar (values), sequences (arrays, implemented below as bullet lists), maps (hashes, implemented below as headings)

---

Question

• Help Ask questions to try and determine what I'm thinking about
• Size 3

Type

• select
  • multi
  • values

Attributes

• Mandatory

Value

Animal

Yes, a heading section (this text) as the value part of an "Animal" option is somewhat overkill, but it demonstrates the point, no?

Vegetable

%INCLUDE{"SomeStuffBetterKeptElsewhere"}%

Mineral

Just the good stuff

Answer

• Help Write your answer here using words of one syllable or less
• Size 10x30
• Attributes
  • Editor
    • TinyMCEPlugin
      • styles
      • headings
      • lists

Type textarea

• tml
  • strict
  • notables

---

Note that I've used a shortcut I'm still thinking about. A bullet where the first word(s) are bolded, indicates a hash key, where the value is to be found following (non-bold part).

-- PaulHarvey - 20 Feb 2010

Creating a foswikiTable to define a DataForm is error prone. Most of the time people get this wrong first shot, even I fail regularly to count the columns per row correctly.

So while extend this model, we are free to replace it with another model that is at least as error prone but more powerful ;).

Basically, it doesn't matter in what format the DataForm definition is stored. What matters is that it is (a) powerful and (b) processable efficiently by foswiki. That's why I like the JSON approach most.

Creating such a JSON object should be done using a simple web app that will finally attach the JSON to the DataForm definition topic.

-- MichaelDaum - 01 Oct 2010

I agree JSON would be a good first shot.

-- PaulHarvey - 01 Oct 2010

I've run into this problem about not being able to write a dataform value using [[dataform value][display value]] and seen this task about fixing it. This problem is causing us some trouble, so I wanted to chime in here to add my vote for this feature to be implemented. Not sure if/how I can help (I'm not a programmer), but I'd like to assist in any way I can! I saw that there's no entry in the FeatureProposals -- Why not, and should I simply write one now?

-- TorbenGB - 17 Nov 2010

Even JSON is difficult to get right: double quotes, commas (except for the last item). It would be best if a web interface creates the JSON object.

The macro approach above is quite similar to http://foswiki.org/Extensions/FormPlugin#FORMELEMENT. Instead of attrs the attributes could be written out: mandatory=1, etc.

What is also missing from FormPlugin are dependencies. For example in Tasks web, the "waiting for" field should only appear after having selected status "waiting for feedback".

-- ArthurClemens - 17 Nov 2010