User Class Refactoring
The User class should be split into a UserBase class, providing access methods, and a UserFile class, which does the file stuff (saving prefs, trail, bookmark, etc as files on disc).
That way it is possible to create UserHash, UserSQL, UserLDAP, ... classes, which use different ways to store the user data.
The password check should also move to extra methods (from load_from_id) to provide a clean interface for user authentication.
-- OliverGraf 2004-02-08 19:33:34
See OliverGraf/HttpAuthentication for some ideas on integrated authentication. -- OliverGraf 2004-02-09 10:08:38
TableOfContents and Include Refactoring
Both TOC and Include need to move nearer to the core. They need special hooks in the formatter to work properly.
For example it is not good that the TOC macro needs to look for wiki markup, cause that renders it useless for headings which come from a different parser. So the best is if the TOC macro would receive the heading calls the formatter gets to gather its information.
The Include is another thing, cause it puts multiple pages, which come perhaps from differen parsers, together. Each page currently gets its own formatter, which is wrong I think, cause the whole page plus includes normally gets formatted into one output format. So the formatter should stay the same. This allows the heading 'gatherer' to work, too.
Execution of TOC:
- parser parse and write markup up to TOC macro
- parser calls macro
- TOC macro call request.startTOC()
- request set a request.toc -one toc per request
- request redirect output to a StringIO - request.pageBuffer
- TOC macro call request.startTOC()
- parser continue to parse as usual- no change in the parser code
- parser finds a heading, call formater.start_heading
- formater print a heading as usual (transparently redirected to request.pageBuffer)
- formatter adds the heading to request.toc - if exists
- parser continue until end of document, working through all included files
- parser call request.flush()
- request check if request.toc exists
- request redirect back output
- request prints request.toc
- request print request.pageBuffer (rest of page)
I don't see startTOC as a request method, cause the formatter is the one which should handle such formatting events. It is also the formatter which knows what a heading is. So for me it belongs into the formatter (the method, the storage should still be a request member as for other stuff the formatter or parser needs to keep request global). -- OliverGraf 2004-08-03 09:50:12
Lets call it enableToc(). I thinks the redirection done by formatter and other code is dangerous. Formater does not have to know where the text is going, it is just a formatter. Maybe what we need is a PageView object, which collects text from macros, formatters and other code, and print it to the user using the current theme. Today request is doing this job, instead of being just a request. -- NirSoffer 2004-08-03 10:01:50
- request check if request.toc exists
Notes
- One parser pass
- Add just one call to parser, call request.flush() on end of work
- Macro TOC is one liner
- Work with any number of includes in any format, cause the toc is done by the formater
Fix automatically the TableOfContensParseCodeMarkup, since this code markup will never call formatter.heading
- Can use multiple formatters, since the toc is saved in the request, and formater knows nothing about the redirection
- Add just few lines to formatter.heading, that add item to request.toc
- Add one trivial function to request
- request shuld ignore multiple calls to startTOC() - one TOC for wiki page, TOC on included page are ignored.
- Fix automatically the very annoying problem, when the document title is the first item in the TOC - the TOC will describe only the part of the page that come after the macro, since the previous page has been formated and sent to the user allready...
Questions:
- How does this work with text_python caching?
Heading ids
The current heading ids are a pain in the @!#! here is the id for this section:
What we want from the heading ids?
- Must be unique
- Must be nice to read - we use them with link!
Here is an option, that will work with the previous method of creating TOC - but can't use caching for included pages, which is true anyway.
Here a compact version for this page:
<a id="section-1" ...> RefactoringProposals</a> ... <a id="section-1.1" ...>User Class Refactoring</a> ... <a id="section-1.2" ...>TableOfContents and Include Refactoring</a> ...
Then the link wil be:
And a more verbose version:
<a id="1_RefactoringProposals" ...> RefactoringProposals</a> ... <a id="1.1_User_Class_Refactoring" ...>User Class Refactoring</a> ... <a id="1.2_TableOfContents_and_Include_Refactoring" ...>TableOfContents and Include Refactoring</a> ...
Then the link wil be: