Feature Proposal: harmonize tables and data forms

I see solutions like EditTable* and MultiTopicSave that are built for one or the other, but DataForms are regularly structured and should be readibly presented to the user in a table. From there users expect to be able to add rows, sort the table, flip back and forth between table and form mode. Indeed, it would be good to be able use html forms in vertical layout to edit just table entries, and horizontal table format to edit data from data forms.

Motivation

Reasons why this feature is needed, and why it is suitable for adding to the next release of Foswiki.

• There's nothing to round-trip: no way to use table controls to edit data structures.
• A lot of similar code is being written, but its functionality will differ leading to user confusion, dispersed energy and potentially more bugs

Description and Documentation

Description of what this feature should do

• Provide common substrate so any table data will work interchangeably with form controls
• Provide common substrate so any form data will work interchangeably with table controls

Examples

Impact

• Probably be more careful about language: make DataForm the data entry method, use a word other for data structuring approach.

WhatDoesItAffect:

Implementation

CDot: MartinCleaver: the only work I'm aware of is the FQP, which pulls tables into the TOM

MartinCleaver: CDot: so, there's nothing to round-trip? Using table controls to edit data structures?

CDot:nope. Thought about doing it several times, if that's any consolation.

-- Contributors: MartinCleaver - 18 Mar 2010

Discussion

As SvenDowideit pointed out on IRC today, TML tables should be considered as just one possible serialisation format that DataForm definitions can be represented as.

So, probably, this topic should be a discussion about getting a centralised TML table parser into the core (make it a part of the TOM, as CDot says FQP does). And/Or the discussion about abstracting out the DataForm definition for alternative serialisation formats which could take advantage of such a thing (personally I'd like to see JSON data form definitions as a possibility

We still need to draw some lines around what we want from form definitions though: separate the data schema from GUI - and its logic? See CentralizeHtmlFormHandling.

Then there are my own agendas for getting Foswiki to play nice with the semantic web and linked data, which will require some hopefully trivial extras in all of this.

-- PaulHarvey - 18 Mar 2010

There is now a table parser in the core; see DemandParseTables. However this isn't about parsing tables out of data, it's about presenting dataforms as tables. The EditRowPlugin could, for example, be told to obtain table content from a source other than the tables in the topic - such as the dataform. I don't think this would be too difficult to do, though setting up the edit (dataforms and tables have different edit widgets) could be a bit awkward. I changed the topic summary to reflect this change in emphasis.

-- CrawfordCurrie - 21 May 2012