// $Id: TODO.txt,v 1.29.2.2 2006/04/13 15:45:06 unconed Exp $

TODO

MAJOR FEATURES

*  Create node-views and do replacements on the URLs. /node/NID/view/VIEWNAME
   ^-- put off for v2.

*  Allow breadcrumb trail to be specified.
   ^-- Not sure what to do with this.

*  XML view?
   ^-- put off for v2 or plugin module.

LESS TIME CONSUMING STUFF
// Most of this is now slated for post 4.7 update.

*  Check queries for injection attacks, especially on the URL!
*  provide more default operator handlers
*  Validation needs a thorough going-over.
*  plugin module?
*  Getting started doc
	-> Getting Started with Views
	-> walk-through changing the default tracker view
	-> All of the Views Fields explained
* fix tracker default view
* add my tracker default view
* add taxonomy/term default view

* double check the access check on block views
* controller for external view output control. i.e, centralized code to
  deal with 'calendar', 'xml', 'specialized grouping' and other module-specific
  view needs. Should have an API available.

DEFAULT VIEWS/MODULES TO SUPPORT

*  workflow
*  taxonomy
*  forum
*  poll
*  blog
*  book
*  sort on number of reads if statistics module enabled
*  event

TO DONE

*  Actually implement the _block and _menu hooks so that views can expose them.
*  Add special handling for non-field data, such as new comments, node changed.
*  Extend table field info: Let admin change header name. 
*  Allow tables to be click-sorted.
*  Each table field and header should have CSS tag.
*  Modify title list to be "List View" and allow the table fields; but instead
   of viewing as a table, it uses a list, with each field in <div> tags allowing
   styling by CSS. Heck, allow ordered/unordered list as an option.
*  Fix themeing to allow each view to be its own theme, if desired. Make sure 
   the support functions exist.
*  get rid of $view->numsorts
*  Try to change hardcoded switch-case statements to callbacks where it
   makes sense to allow modules to extend functionality.
*  Re-factor sorting info so that it goes into the table data and is assembled,
   rather than being hard-coded as it is now.
*  Create on-the-fly filtering too
*  Allow a NOT in the and/or algorithm.
*  description field for view
*  Add changed field to prevent multiple admins from saving views simultaneously
*  query caching
*  redo the $tabledata stuff to generate once and stick it into a well-named
   global for cacheing (this is a prelude to exposing the API).
*  Just put the node information in the full tables section, rather than 3 stupid functions
*  default views
*  Expose an API so modules can provide table and sorting and special
   field-handling information.
*  allow random selection from a view
*  provide blocks for default views that request them
*  arguments API
*  Create a tool to ease creation of default views.
*  add not-saved reminder to form
*  Document the API
*  4.7 forms API and other 4.7 transition requirements.
*  Add 'move up, move down, move to top, move to bottom' buttons to make 
   re-ordering easier. 
*  variable_get on default filter format on forms.
*  option field for filter
*  option field for sort
*  taxonomy filter by hierarchy
*  variable titles for argument queries with summaries (Use %arg# for substitution)
*  taxonomy depth (argument) Taxonomy Summary View with Depth is basically broken, unlikely to be fixed.
*  Optional [MORE] link in blocks that are also page views.
*  Function between views_view_page() and views_view() to make it easy to
   access a view externally.
*  Function that just returns a list of nodes and doesn't theme it at all.
*  table data needs a way to document itself.
*  View trading interface.
*  glossary mode
*  Write some decent help for the edit view page.
*  The query object is turning into a hash. At the very least, add_table 
   and the variants on trace, ensure_table, etc, need a thorough going-over
   to make sure they all make sense. There are unDOUBTedly some bugs in
   here because I keep confusing them.
*  history table -- allow to filter on 'has updates' or not.
* 'custom' filter handler should just be called 'handler' I think
*  Split form components out into a .inc
*  cacheing of table data
* generalize query builder so a base-table can be defined, and remove
  hard-coded references to 'node'.
* change all references of the node table from 'n' to 'node'.
* extra args for add_where, add_orderby used like db_query
* substitution on generated queries so that 'current user' based queries can still
  be cached.
* allow disabling of default views
* allow a view to specify exact menu path for view
* mark default views that are overridden by views in the database
* option for 'Home' breadcrumb item
* breadcrumb for arguments
* allow a view to specify: menu entry, tab, default tab.
* cache default views
* wildcards in arguments
* fix [more] link
* figure out required modules when exporting; guard against that on import.
* Allow filters to be presented to the end-user so that they may filter a resultset.
  Each filter should have: A way to not use it (either a checkbox or a special
  operator that says 'unused'. What is set in the actual view definition merely
  becomes the default.
