Editing WikiDB/Roadmap

From TestWiki
Jump to: navigation, search

Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision Your text
Line 1: Line 1:
<div class="Information">
+
This is an (incomplete) list of features that I plan to add.  There are also good ideas from other people scattered around the wiki, which I should really add to this page, but haven't yet.
; 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>
+
  
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 this page reflects my current development version - if an item is removed from this page due to being implemented, it may not turn up in a public release for a little while.
  
<div class="Warning">
+
The bug list has been moved to [[WikiDB/Bugs]].  Please report bugs there.
'''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>
+
 
+
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.
+
  
 
== Planned features (in progress) ==
 
== Planned features (in progress) ==
  
=== Table definitions ===
+
=== Back-end ===
 
+
* 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 ===
+
 
+
* 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. <code>int</code> and <code>integer</code>).  Currently you need to define the same type multiple times if you want this.
+
 
* Add 'date' data-type.
 
* Add 'date' data-type.
 
+
* Joins in queries
=== Querying back-end ===
+
* Foreign key definitions
 
+
* 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 ===
 
=== Syntax ===
 
+
* Repeat tag - Add boolean NOT operator (AND, OR and XOR are implemented, but NOT is unary and therefore trickier).
* Formalise syntax for referring to identifiers and literals.
+
* Repeat tag - Allow LIMIT argument (or maybe 'range'), possibly with pagination.
* <code>&lt;repeat&gt;</code> tag:
+
* 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...
** 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 ===
 
=== Interface ===
 
 
* Highlight 'bad' data on the table's data page.
 
* 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 ===
+
=== Code Tidying ===
 +
* Add profiling statements.
  
* Code Tidying:
+
=== Administration ===
** Add profiling statements.
+
* 'What links here' should show templates that are included via data tags.
* 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) ==
 
== Other possible features (speculative) ==

Please note that all contributions to TestWiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see TestWiki:Copyrights for details). Do not submit copyrighted work without permission!

To edit this page, please answer the question that appears below (more info):

Cancel | Editing help (opens in new window)