BottleTalk Project
"It's lucky for your First Amendment rights that I've got my Twenty-First Amendment rights."
Should be said in a vaguely threatening way ...
A full featured Python blog/wiki that is small and quick enough to run as a simple CGI script in any shared hosting environment.
Basic Features
- CGI Server
- Bottle uFramework running as CGI on Apache.
- Bottle Templates.
- Template Macos.
- Apache htpasswd security.
- Blog
- Order is historical.
- Basic creole edit.
- Multipage, presentation, slide.
- Wiki
- Order is hierarchical.
- Creole.
- Macros.
- Wiki Names
- Name to table mappings.
- Hierarchical namespaces.
- Enhanced interwiki.
- Like TracLinks, only more so ...
- Needs to be a separate functional module.
- May be adapter pattern or part of database.
- Relations
- RDF like
- 5-way associations.
- meta-types, like presentation.
- Relation Definitions
- Simple inverse.
- List weight.
- Display name.
- Templates
- Template macros.
- Emit HTML and what else ?
- Type Templates
- Too much ?
- Automatic InputForm generation, maybe output from template generator is form for type: instances.
- The type/template can also be for an 'edit' page, maybe a literal 'jinja' template generator
- Links
- Simple post/edit.
- Extend from URL to media types, file, xml, pdf, mp3, etc.
- Parallel namespace for talking about resources, such as 'file:', 'xml:', 'html:', etc.
- Features like collections of attachments mapped to wiki page ?
- Tags
- Edits or not ?
- Search terms.
- Tag relations, like association-weight.
- Security
- Generate as static site as HTML
- Site lockdown using linux user permissions, via FTP.
- Clear Mapping from Bottle CGI to a Tornado App .
- As Bottle WSGI.
- As native Tornado app.
- Sqlite DB
- RDF++ functionality
- Views, triggers, the works.
- Better performance and tunability.
- Python functions, like wiki name
- Python apps like SQLAlchemy
- Using as Publishing Site
- need something like site specific config for suppressing admin paths, main page content, etc.
- Better to use DB synch mechanism ?
Database
Realm names above ( such as wiki: ) are usually mapped to a table with the same name, with minor exceptions like mapping blog: to a generic page table.
Major exceptions might be 'sub-realms' such as section: which would be a collection of references from relation: back to !wiki: and have no direct mapping to a specific table row.
The section: concept seem to be extremely useful. The idea is to leverage the natural addressability of HTML #anchors into a sort of floating reference between wiki pages/sections/sub-ages, much like #meta-tag or perhaps even a facet. Allows specific capture of information like Workflow#Python with #Python meta-tag.
Not quite the same as ordinary tags with python-workflow <=> workflow-python conventions. The Workflow#Python connection is explicitly discovered rather than asserted by convention. Will probably be worth the effort to implement.
The basic design for entities and relations should powerful and general enough to provide a good foundation for the design of the Semantastic database as well.
Wiki Paths
- hierarchy ( ex. ParentPage/SubPage/SubSubPage )
- reference resolution by breadth, then by depth
- Page#Anchor is an entity, roughly a section: sub-realm
- maybe an 'auto include', use in search like meta-tag, editable ?
Why not use for non-wiki relationships ?
See Wikis#WikiPathRules, Wikis#MoreAboutSections
Probably need <<Section>> macro.
Wiki Macros
Needs edit behavior ( preview, save ) and render behavior ( normal )
| <<PageOutline>> | pass page name as parameter |
| <<TitleIndex>> | with current page default or parameter |
| <<HTML>> | What for ? Is insecure for sure. Do I really need ? |
| <<Section>> | definition versus query/report, #SectionName as meta-tag ? |
| <<Backlinks>> | inverse of link, need section level matching in queries. |
| <<RecentChanges>> | How does versioning fit in ? Does it need to fit in ? |
| <<InterWiki>> | very useful, outside database for 'hard link' paths ? |
| <<Search>> | extended for sections, embeddable in wiki page. |
| <<InfoBox>> | basic driver for values: table |
| <<Include>> | primarily from values: via InfoBox import |
| <<Presentation>> | uses context and outline level to refer back to parent presentation to provide multi-page outlines and prev/parent/next navigation |
| <<FreeTags>> | page/section level blocks, can provide direct relation: triples beyond defined relationdef: |
Example of Freetags such as:
| wiki:TestPage | author: | value:Person/BillB |
Similar to self defining InfoBox, like type:Dict ?
Template Macros
Similar to Trac 'formatters' ? Passed via dictionary to rendering template ?
'Templates' used by macros for content rendering. General purpose 'value template' forms would be an ideal for elaborate template macros.
Almost all have an associated template, either:
- wiki template
- type template
- unique page template ( such as section_edit ).
In addition to view, need to provide edit, preview and save behaviors.
BottleTalk Battle Plan
- Bottle to the max
- deploy as CGI
- Database database database
Bottle Talk SubPages
