Rough retroactive design notes from my whiteboard, aiming to summarize zwiki design & functionality at the time of writing.
See also WikiWikiWeb:WikiDesignPrinciples, BigThemesForZwiki?, RefactoringZwikiArchitecture, FunctionalOverview, ZwikiInANutshell, OriginalZopeWikiProposal
User Stories
- user can create a wiki page zope object which can be viewed through the web
- wiki pages display a standard header & footer
- wikinames are displayed as links or page-creation links based on zope folder contents
- wiki pages are auto-formatted as html when viewed
- dtml is evaluated
- a page may be one of several types, which allow different combinations of the above, or different rules
- header includes title, which brings up a list of backlinks when clicked
- footer includes an edit link, which brings up a form to make changes to the page
- page creation links bring up a form which creates a new page (of same type)
- page hierarchy is tracked; new pages are children of the page they were created from; parent pages are listed in the header
- a page's parents can be changed in backlinks. Multiple parents are allowed
- contents link in the header displays the whole hierarchy, centered on the current page
- permissions supported: change text, append text, change page type, reparent, create, delete, file upload
- permissions affect options displayed
- embedded dtml can be disallowed or locked down. Admin can limit the powers of embedded dtml via permissions/ownership/proxy roles.
- complete wikiwebs may be easily created from a list of templates
- JumpSearch?
- RecentChanges?
- UserOptions?
- page renaming, page deletion
- file upload
- RemoteWikiLinks
- BlockList
a few which may be incomplete but would like to be in zwiki 1.0: - SisterSites
- header/footer are not added when a zwiki page is called programatically or from within another page or when noheaders=1; zwiki pages can be used wherever you would use a dtml method
- there is a page type/render method/markup tag or other solution for safely displaying html source, dtml code etc. pretty-printing would be nice.
- a zwiki page can work like or be equivalent to a zope presentation template. I don't quite know what I'm saying here but I like it.
Classes
need an easy way to format these CRC cards. (Neat - wiki first came from Ward's attempt to represent CRC cards in hypercard). Any improvements to my OO analysis would be more than welcome.
ZWikiPage
responsibilities:
- render itself
- provide edit/create forms, backlinks, table of contents
- accept edit/create requests, with authentication
- store metadata such as permissions, time, last author, parents etc
collaborators: Zope, Folder, Request, Response, WikiNesting?, WWML
WikiNesting?
responsibilities:
- help generate table of contents
collaborators: ZWikiPage
WWML
responsibilities:
- help render structured text
collaborators: ZWikiPage
Tests
responsibilities:
- store zunit tests
- allow zunit to invoke doc tests
collaborators:
Zope
responsibilities:
- handle communications, storage, transactions, etc.
- provide time of day
- other misc. services
collaborators: ZWikiPage
Folder
responsibilities:
- report children
- store permissions
collaborators: ZWikiPage
Request
responsibilities:
- carry data from client to us
collaborators: ZWikiPage
Response
responsibilities:
- carry data from us back to client
collaborators: ZWikiPage