TODO

This is the TODO and Wish List for rest2web. It includes things that need to be done as well as things that are only included because they could be done.

They are not listed in any order of priority or even desirability. Obviously bug-fixes are the highest priority. If you have any suggestions for this list, or opinions as to the priority of items on this list, or wish to implement any of the ideas yourself, then please get in touch.

Some of the items have (?) at the end of them. This means we are not sure if it desirable to implement the suggestion at all. There is a constant tension between adding more flexibility (extra options) and keeping things simple. Your input is wanted - if it matters to you whether we do this or not then let us know.

For bug reports or feature requests you can use the rest2web Mailing List.

• Get plugins and macro support complete in the executable version.
• The example translation file - links to the same pages in the other languages. Standard function to do it ?
• Render macros in section descriptions.
• Allow easy adding of user functions ? (like macros, currently doable through normal imports in templates)
• markup format - could allow additional markups, like sextile and textile.
• description format - we might want to allow different markups for the description. (Currently reST only - could allow html easily)
• can we extract the page description from the reST format ? (as meta information)
• Use filename as default page title/link title/crumb ? (where none is supplied)
• Build a plugin to use the tags for navigation - so a site needn't just be represented as a tree. Also build a data structure (probably XML) that can be used by a CGI script for dynamically searching for pages with tag combinations.
• Should we allow comments inline with values in the restindex ? (or even multiline comments ?) - this would require a better parser.
• Should be a standard function to generate a table of links to the sections in a page, for use in the index page - which could have several pages in each section. See the example table in the test site.
• Should 'format' or 'encoding' be a default value, when specified in the index file ? (any others ?)
• At the moment you can only have sections you have declared in your restindex 'sectionlist'. Should you be able to assign pages to sections without having to declare them ? FIXME: check this is true
• Develop the index generation stuff so that it can generate 'blue arrows' style Python documentation. (Difficult without support in docutils)
• Contents for a section, or for the whole site.
• Single index page for the whole site (sitemap plus indexes from within pages).
• Cache template files as they are reused, and are currently reread each time. (a dictionary, keyed by filepath)
• Add doctests to everything.
• A way of adding a set of standard links to all reST pages.
• Implement the config file values as command line options. (?)
• Automatic FTP facility.
• Integrate with Tidy for checking of HTML.

ISSUES

Following is a list of 'unresolved issues' with rest2web. They aren't necessarily all bugs, so they may not be fixed. It's probably worth being aware of them.

• Unfortunately, the guess_encoding function can recognise cp1252 [1] as ISO-8859. In this case docutils can choke on some of the characters. We probably have to special case the cp1252 and ISO-8859 encodings - but I wonder if this problem applies to other encodings ?
• If you set include: No for an index page, it works fine except when you are viewing that index page or subpages. In these cases it is included.
• If no crumb is provided, the page-title is supposed to be used instead. Each page needs it's index page in it's list of crumbs (as the 'crumb before' it). In order to work out the title for the index page, we would need to render the body of the page. But to render the body of an index page, you need to render all the other pages first. This means index pages need crumbs. Either that or you can supply an explicit page-title value !
• You probably can't set a target that is outside the current directory tree. (test !) Allow for a way of specifying that the target is an absolute URL (if build is 'No')
• It would be nice for every page to have access to the whole structure of the site [2]. This would allow a sidebar to have links to every page in every section. The only way of doing this is to generate the site in two passes. First pass create the structure. Second pass, render the pages with the pages having access to the index structure. This means parsing the restindex - which also extracts page contents. Unless we are going to parse the restindex twice we would end up with the entire contents in memory. Is this feasible ? (or worthwhile - would anyone use it ?) XXXX Note that because of the data structures we create - it's likely that currently the whole site is being kept in memory anyway.
• Currently a '.txt' file without a restindex won't be built. It's possible that all the defaults are what you want. Should we let a file without a restindex be processed ? (That means if you don't want a text file to be processed you must give it a restindex and set build and include to No - maybe make it an option ?).
• Macros have no access to the environment they are being rendered in. This means that they no nothing about the current page location and encoding. We could provide a 'globaldict' in the macros namespace and populate it with information like this. That would mean that the macros that access files (like include and colorize) could use paths relative to the current page, and the output could be encoded with the right encoding.
• It would be nice to make Firedrop a graphical frontend to rest2web. It would need to be able to handle trees of pages, instead of a list, and effectively have a 'build.ini' file per page (the restindex) rather than for the whole site.
• For a page that has 'include' set to 'No', the indexpage value is None. This is because the current page doesn't have an entry in the indextree structure. This could require some care if you use 'thispage' in your template. Is their some other sensible value it can have ? You can still use indextree without problem.
• If you have an index file with build: no - it still builds the content to get the page title (I presume). So if the content is badly built (which is why you have put build: no) - it still attempts to build and may crash.
• I'm not sure if filename encodings are an issue or not. I don't always decode filenames - so where we are comparing them from the filesystem etc. it's possible we'll have problems.
• Sidebars contain links to pages in sections above. This means that changing one page can affect other pages - so when you change something we have to rebuild the whole site, not just the changed part.

Footnotes