Difference between revisions of "WikiDB/Features"

From TestWiki
Jump to: navigation, search
(Table redirects have been implemented for quite a while.)
(Planned features (in progress): Add a few more bits)
Line 40: Line 40:
  
 
=== Queries ===
 
=== Queries ===
* More sophisticated filtering, including full range of equality operators (<nowiki>>, <, >=, <=, =, <></nowiki>) at the very least.
+
* More sophisticated filtering, including full range of equality operators (<nowiki>>, <, >=, <=, =, <></nowiki> as a minimum), boolean operators (AND, OR, NOT plus parentheses to give precedence) and ability to compare fields with each other.
 
* Allow default values to be specified in {{{field}}} references.
 
* Allow default values to be specified in {{{field}}} references.
 +
* Allow limiting of results - possibly with pagination.
  
 
=== Interface ===
 
=== Interface ===
 
* Highlight 'bad' data on the table's data page.
 
* Highlight 'bad' data on the table's data page.
 +
* Add filtering/ordering functionality to the data tab.
 +
 +
=== Compatibility ===
 +
* Make extension compatible with PostgreSQL.
  
 
== Other possible features (speculative) ==
 
== Other possible features (speculative) ==

Revision as of 15:52, 23 March 2013

Note: This page is still fairly incomplete. I will add to it as I remember things.

If you want to suggest new features, please use WikiDB/Feature requests rather than this page.

Current features

The following features are currently working (or mostly working). Please see the Tutorial first - some of these features may be a little unclear until you understand what the extension does.

Data

  • Data may be defined on any page in the wiki.
  • The new <data> tag can be used to replace infobox templates. The result is identical, but the data is also added to the appropriate table.
  • You can define data without defining any kind of table structure.
  • Data may be typed, but all typing is loose, and does not affect the stored data.

Table definitions

  • Support for multiple table namespaces for easy separation of data.
  • Table definitions can include standard wiki markup for ease of annotating their use.
  • Aliases may be defined for fields, so that common naming mistakes or legacy data can be seamlessly mapped to the correct field.
  • Fields can be typed and, where appropriate, a range can be specified.
  • An extensible type mechanism allows new custom field types to be added. For example, you could create an 'ISBN' data type that only allowed valid ISBN numbers. The data types can be as complex as you want.
  • The data page shows you how the data looks when formatted to the tables current specification
  • Table pages that are redirects automatically map to the target table. All data that points to a redirect actually ends up in the table it redirects to.

Queries

You can use the <repeat> tag to perform queries.

  • The tag can be used on any page in the wiki.
  • You can specify multiple fields to sort on.
  • Fields can be sorted in ascending or descending order.
  • You can filter results (currently only very simply)
  • The contents of the tag are repeated for each row returned by the query, with {{{fields}}} replaced by their data.
  • If the tag has no contents, the results are displayed in a standard format.

Interface

  • New 'data' tab for table pages, which shows you all the data defined for that table. This tab is available even if no table definition is defined.
  • Special:AllTables lists all defined tables on the wiki.
  • Special:UndefinedTables lists tables that do not exist, but for which data has been defined.
  • Special:EmptyTables lists tables that have a definition but no data.

Planned features (in progress)

The following features are in the pipeline, but have not yet been implemented. There are others that I have forgotten about, which will add when I think of them. See also WikiDB/ToDo

Queries

  • More sophisticated filtering, including full range of equality operators (>, <, >=, <=, =, <> as a minimum), boolean operators (AND, OR, NOT plus parentheses to give precedence) and ability to compare fields with each other.
  • Allow default values to be specified in {{{field}}} references.
  • Allow limiting of results - possibly with pagination.

Interface

  • Highlight 'bad' data on the table's data page.
  • Add filtering/ordering functionality to the data tab.

Compatibility

  • Make extension compatible with PostgreSQL.

Other possible features (speculative)

These are some thoughts on later developments, for further down the line.

Interface

  • Form-based data entry.

Data linking

  • Ability to specify joins between tables.
  • Able to specify relationships between data, e.g. 'is a type of'