Proposed: New FIELD variable to query fields in forms, bullets and tables

Summary: New %FIELD{"name"}% variable to pull a named field from a TWiki form, a bullet, or a table row.

This is a useful feature to easily pull structured content from other places (user home pages etc) without the need to type a complex SEARCH with a regular expression.

Parameters of %FIELD{"name"}% variable:

Search scope:

• For TWiki form fields: Name of form field. Example:
  • Above summary can be shown with %FIELD{"TopicSummary"}%
• For bullets and definition lists: Name is assumed to be between an asterisk/dollar sign and a colon; value starts after the colon. Formatting (bold etc) is accounted for. Example:
  • Name: Ako Tanaka
  • City: San Jose
• For tables: Name is assumed to be in first table column, value in the second column. Formatting (table header etc) is accounted for. Example:

  Name:	Ako Tanaka
  City:	Tokyo

Contributors:
-- PeterThoeny - 05 Feb 2004

Discussions

A similar idea has been posted in SpreadSheetPluginDev.

-- PeterThoeny - 05 Feb 2004

I like this idea. However, I would strengthen the designation of the field in a table, assuming I understand it right. The field in a table is identified by a 3-tuple (tablenumber x row x column), unless you just look into the first table found. But you still should allow access to any cell in the table. The syntax there would be like in SpreadSheetPlugin, I think.

-- ThomasWeigert - 05 Feb 2004

For what kind of queries would a 3-tuple (tablenumber x row x column) be useful? This sounds more like a $T() reference of the SpreadSheetPlugin then a search on a key.

I was thinking of a simple search that grabs all table rows of all tables in the topic and uses the first matching key. This assumes tables with a horizontal layout like:

The question is if a vertical layout should be supported as well, which would not be as simple to implement as the horizontal one. Example:

-- PeterThoeny - 05 Feb 2004

I think this feature would access some structured information somewhere on the page. Information about a table is identified by a table identity, and the row and column of the cell of interest. The value held in the cell is the value of interest (and yes, this is like the $T{}% in the SpreadSheetPlugin). There is nothing privileged of being a value in the first row or column of a table.

-- ThomasWeigert - 06 Feb 2004

CrawfordCurrie's Plugins.FormQueryPlugin already provides substantial support for querying tables in topics. FormattedTWikiFormDataInTopicText contains support for querying webforms. Furthermore OverridePreferenceSettingsInTopics combined with UsingFormsForSettings provides another method for doing this.

The implementor of this option should consider writing this as a plugin if they do it to allow the behaviour to be easily overridden by local admins using an alternative.

Further, consider the alternative syntax: %Web.Topic#SubItem%, as convergence on the approach taken by other wikis - it's also much more "wiki" like, unlike the constant usage of the UserUnfriendly %FIELD{"field" topic="foo" web="web"}% type syntax.

This then logically falled back to %Topic#SubItem%, and to %SubItem% . (The last of which works pretty nicely, as noted on using forms for settings- which you get if you allow override preference settings in topics and also use the minor patch I made/noted on using forms for settings.

Finally, consider the option of allowing implicity named sections be a field.

(Some of the above ideas are potentially mutually exclusive, or redundant depending on your point of view)

-- MS - 06 Feb 2004

Some related code (and discussion) is already implemented, FormattedTWikiFormDataInTopicText

-- PeterThoeny - 13 Mar 2004