1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
|
restindex
crumb: TODO/ISSUES
page-description:
The TODO and ISSUES list for **rest2web**.
/description
/restindex
=============
TODO/ISSUES
=============
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`_.
* Add an extra level of verbosity, errors only.
* Remove the 'unicode' encoding option - this defaults to an output encoding
of template encoding; which is arbitrary.
* Allow overriding of default index and template used with 'force mode'. (And
provide a simpler default template.)
* ``<% path_to_root %>`` doesn't work in gallery files, need a workaround in
plugin if possible. Could sllow path_to_root in the uservalue 'body', or
some other mechanism.
* Better error messages from rendering templates - proper line numbers.
* CSS error in new template for long page titles (squashed in minibar).
* Implement next and previous. (By giving pages access to the section order lists.)
* Add rest2web version to the namespace.
* Provide a better default title for the index pages (using
``self._top_level_name``).
* Handle encodings for dicts (subsections) and list values, when supplied as
uservalues in config file.
* Add a 'guess' option (the default) for encodings supplied in a config file ?
* Ability to set the lineendings of the output. ('``\\n``' or '``\\r\\n``')
* Build a more up to date executable.
* Add test examples of the new ``include`` functions.
* Allow source and target directories to be provided as command line options.
* A standard function to automatically copy (and link to) the text source for
a page.
* Add a 'Generated by rest2web' comment into the HTML of each page.
* Duplicate entries in ``section_pages`` gives an unhelpful error message.
* 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 this, or restindex keyword ?
* Allow setting of docutils options in the config file.
* 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.
* template engines - support for other templating engines like Cheetah
* Better support for multiline and nested macros.
* 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, including up. (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).
* Unittests or doctests. (Probably requires a lot of refactoring to make
rest2web testable.)
* A way of adding a set of standard links to all reST pages.
* Implement more of the config file values as command line options.
* Automatic FTP facility.
* Integrate with Tidy for checking of HTML.
* [madduck] More flexible parsing for restindex. Ideally, it should be
possible to have the restindex anywhere within the document, including
comments. Also, it should be completely removed from the document after
processing.
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`` [#]_
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 [#]_. 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 ?).
* It would be nice to make `Firedrop <http://www.voidspace.org.uk/python/firedrop2/>`_
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.
* 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
=========
.. [#] The default windows encoding.
.. [#] Currently through indextree, a site has access to the whole structure
*above* the current page - but not the *whole* structure.
.. _rest2web: http://www.voidspace.org.uk/python/rest2web
.. _rest2web Mailing List: http://lists.sourceforge.net/lists/listinfo/rest2web-develop
|
