Difference between revisions of "WikiDB/Roadmap"

From TestWiki
Jump to: navigation, search
m (Administration: undelete fixed)
(Planned features (in progress): + aliases)
 
(21 intermediate revisions by the same user not shown)
Line 1: Line 1:
This is an (incomplete) list of features that I plan to add before v1.
+
<div class="Information">
 +
; Do not add new feature requests to this page.
 +
: This page represents my own roadmap and should be maintained only by me.  Instead, use one of the following pages:
 +
:* Use '''[[WikiDB/Feature requests]]''' to request a new feature.
 +
:* Use '''[[WikiDB/Bugs]]''' to report a bug.
 +
</div>
  
The bug list has been moved to [[WikiDB/Bugs]]Please report bugs there.
+
This page contains the current roadmap for WikiDB.  The list represents some of the things that I am currently exploring and my aspirations for future development, but it is unlikely to be a complete list and may not always be kept up-to-date as things evolve.
  
Note that items marked as FIXED IN HEAD have been fixed in my local version, but may not have been uploaded to the site yet.
+
<div class="Warning">
 +
'''Warning:''' This page does ''not'' guarantee that the suggested features will ever be implemented, nor does it indicate my development priorities - it simply represents my current thinking about the features I would like to add, in no particular order.
 +
</div>
  
== Administration ==
+
There are also good ideas from other people scattered around the wiki, particularly on the [[WikiDB/Feature requests|feature requests page]].  Some of those suggestions get incorporated into this page, if there is a clear benefit and no obvious barriers to implementation.  Any ideas that have not been added to this page are still contenders for inclusion (particularly if demand is high); they are just not at the front of my mind.
  
* <s>Update tables when page is moved.</s> FIXED IN HEAD
+
== Planned features (in progress) ==
* <s>Update tables when page is deleted.</s> FIXED IN HEAD
+
* <s>Update tables when page is undeleted.</s> FIXED IN HEAD
+
* <s>(check that rollbacks work)</s> FIXED IN HEAD
+
* 'What links here' should show templates that are included via data tags.
+
* <s>Show table definitions correctly when using 'preview' (currently displays as if normal wiki text).</s> FIXED IN HEAD
+
  
== Syntax ==
+
=== Table definitions ===
  
* Better data syntax:  Need to allow multiple rows in a single definition.
+
* Allow foreign keys to be defined.
** Also, data definitions in a DB namespace shouldn't require the 'table' attribute (default to current).
+
* Allow 'closed' tables (where all data is supplied on the schema page), as a method for implementing Enum fields.
* Repeat tag - some things to iron out (see below)
+
* Field names need to be limited to 255 chars (DB limit)
+
* Field names need to have leading underscores removed (Reserved for special uses)
+
* Provide a mechanism for 'pass-through' parameters to the &lt;data&gt; tag (i.e. parameters that are supplied to the template, but which don't get added to the table).  Suggestion is to prefix the name with an exclamation mark.  Alternatively, an underscore could be used, as this is already reserved in table definitions, and therefore is not allowed in data tags (though this is not enforced) - may kill two birds with one stone...
+
  
== Repeat tag ==
+
=== Data types ===
Still quite a way to go on this, but here's where I'm up to:
+
  
=== Done ===
+
* Introduce new class-based method for defining data types (custom and internal) to improve code re-use and to make it easier to add new features.
* Basic sort/filter is implementedOnly limited filter options available, due to a parsing issue with MW/HTML.
+
* Allow aliases to be specified (e.g. <code>int</code> and <code>integer</code>)Currently you need to define the same type multiple times if you want this.
* Contents of repeat tag are repeated for each row with variables expanded (see below for limitations).
+
* Add 'date' data-type.
  
=== To Do ===
+
=== Querying back-end ===
 +
 
 +
* Allow JOINS in queries.
 +
* Add support for boolean NOT operator (AND, OR and XOR are implemented, but NOT is unary and therefore trickier).
 +
* Add support for LIKE comparisons?
 +
* Add support for REGEX comparisons?
 +
* Add support for OFFSET/LIMIT.
 +
* Add support for field lists and DISTINCT clause.
 +
* Add support for calculated fields.
 +
* Add support for custom functions.
 +
 
 +
=== Syntax ===
 +
 
 +
* Formalise syntax for referring to identifiers and literals.
 +
* <code>&lt;repeat&gt;</code> tag:
 +
** Allow LIMIT argument (or maybe 'range'), possibly with pagination.
 +
** Add ability to specify field list and limit to DISTINCT rows.
 +
* <code>&lt;data&gt;</code> tag:
 +
** Provide a mechanism for 'pass-through' parameters (i.e. parameters that are supplied to the template, but which don't get added to the table).  Suggestion is to prefix the name with an exclamation mark.  Alternatively, an underscore could be used, as this is already reserved in table definitions, and therefore is not allowed in data tags (though this is not enforced) - may kill two birds with one stone...
 +
** Allow multi-line field data.
 +
 
 +
=== Interface ===
 +
 
 +
* Highlight 'bad' data on the table's data page.
 +
* Add special page to list all defined data types.
 +
* 'What links here' should show templates that are included via data tags.
  
* Tag Contents
+
=== Internals ===
** Aliases are currently expanding correctly, but not in a foolproof manner (e.g. aliases that point to aliases are not handled - this is a general issue, I think)
+
** Undefined fields - is their current handling OK?  Currently they will be expanded if defined for the row, and left as they are if not.  This might be the best behaviour, but perhaps not.
+
** Cannot currently supply default values for empty fields.  In any case (given the above point) default values for undefined fields must, by definition, be ignored (I think).
+
** Cannot handle nested vars.  Not a problem at the moment, but if default values are allowed, the default should be allowed to be an alternative variable (e.g. <code>{{{DisplayName|{{{ShortName}}}|No name defined}}}</code> should be valid syntax).
+
** Should strip blank lines at start and end.  Maybe restrict to stripping 1 line only (so &lt;repeat&gt; need not be on the same line as the start of it's content).  Should _not_ use trim(), as we need to allow for space at start of line (wiki &lt;pre&gt; syntax).
+
* Filtering
+
** Can't use &gt; in attribute values, e.g. criteria="Field>Value", as it cripples parser.  Need to decide how to specify criteria.
+
** In general - how detailed can we get?
+
* Other
+
** Ability to have header/footer? Ideally you put your header before the repeat tag, and the footer afterwards, but tables are screwed up by this (though I might be able to fix that somehow). There may also be other situations that cause problems.
+
  
== Code Tidying ==
+
* Code Tidying:
 +
** Add profiling statements.
 +
* Internationalisation:
 +
** Allow type names to be translated.
 +
** Allow type aliases to be translated.
 +
** Allow tag names to be translated?
 +
** Allow data to be translated?
  
* Ensure all user-visible text uses the message cache.
+
== Other possible features (speculative) ==
* Add profiling statements.
+
These are some thoughts on later developments, for further down the line.
  
== Misc ==
+
=== Interface ===
 +
* Form-based data entry.
  
* References to tables in table="..." attributes should follow redirects.  This allows tables to be moved without screwing everything up!
+
=== Data linking ===
 +
* Ability to specify joins between tables.
 +
* Able to specify relationships between data, e.g. 'is a type of'

Latest revision as of 17:35, 19 August 2021

Do not add new feature requests to this page.
This page represents my own roadmap and should be maintained only by me. Instead, use one of the following pages:

This page contains the current roadmap for WikiDB. The list represents some of the things that I am currently exploring and my aspirations for future development, but it is unlikely to be a complete list and may not always be kept up-to-date as things evolve.

Warning: This page does not guarantee that the suggested features will ever be implemented, nor does it indicate my development priorities - it simply represents my current thinking about the features I would like to add, in no particular order.

There are also good ideas from other people scattered around the wiki, particularly on the feature requests page. Some of those suggestions get incorporated into this page, if there is a clear benefit and no obvious barriers to implementation. Any ideas that have not been added to this page are still contenders for inclusion (particularly if demand is high); they are just not at the front of my mind.

Planned features (in progress)[edit]

Table definitions[edit]

  • Allow foreign keys to be defined.
  • Allow 'closed' tables (where all data is supplied on the schema page), as a method for implementing Enum fields.

Data types[edit]

  • Introduce new class-based method for defining data types (custom and internal) to improve code re-use and to make it easier to add new features.
  • Allow aliases to be specified (e.g. int and integer). Currently you need to define the same type multiple times if you want this.
  • Add 'date' data-type.

Querying back-end[edit]

  • Allow JOINS in queries.
  • Add support for boolean NOT operator (AND, OR and XOR are implemented, but NOT is unary and therefore trickier).
  • Add support for LIKE comparisons?
  • Add support for REGEX comparisons?
  • Add support for OFFSET/LIMIT.
  • Add support for field lists and DISTINCT clause.
  • Add support for calculated fields.
  • Add support for custom functions.

Syntax[edit]

  • Formalise syntax for referring to identifiers and literals.
  • <repeat> tag:
    • Allow LIMIT argument (or maybe 'range'), possibly with pagination.
    • Add ability to specify field list and limit to DISTINCT rows.
  • <data> tag:
    • Provide a mechanism for 'pass-through' parameters (i.e. parameters that are supplied to the template, but which don't get added to the table). Suggestion is to prefix the name with an exclamation mark. Alternatively, an underscore could be used, as this is already reserved in table definitions, and therefore is not allowed in data tags (though this is not enforced) - may kill two birds with one stone...
    • Allow multi-line field data.

Interface[edit]

  • Highlight 'bad' data on the table's data page.
  • Add special page to list all defined data types.
  • 'What links here' should show templates that are included via data tags.

Internals[edit]

  • Code Tidying:
    • Add profiling statements.
  • Internationalisation:
    • Allow type names to be translated.
    • Allow type aliases to be translated.
    • Allow tag names to be translated?
    • Allow data to be translated?

Other possible features (speculative)[edit]

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

Interface[edit]

  • Form-based data entry.

Data linking[edit]

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