TiddlyWiki
From ThorxWiki
(Difference between revisions)
(+wiki link) |
m (+pytw link) |
||
| Line 25: | Line 25: | ||
The backend can also be front-end agnostic. For on-a-stick style, flat files makes most sense. On a server, the (to be written, server backend code) can translate to flat files, or DB files, or sql, etc, as it sees fit. |
The backend can also be front-end agnostic. For on-a-stick style, flat files makes most sense. On a server, the (to be written, server backend code) can translate to flat files, or DB files, or sql, etc, as it sees fit. |
||
| − | [[wikipedia:Tiddlywiki]] |
+ | |
| + | == Links == |
||
| + | * [[wikipedia:Tiddlywiki]] |
||
| + | * [http://www.cs.utexas.edu/~joeraii/pytw/ Serverside Tiddlywiki fork with python backend, from which I draw much inspiration] |
||
Revision as of 16:04, 20 April 2009
TiddlyWiki is a hybrid wiki/blog style self-contained CMS.
It is wiki-like in some ways
- Wiki markup (own markup, not mediawiki format)
- massive interlinking is encouraged and made easy
- Pages aren't expicately chronological (though they may be made so by use of date-as-title
It is blog-like in some ways
- Pages are presented in multiple-entries displayed on a page
It is unique in some ways
- The blog view is dynamic, as individual entries (tiddlers) can be displayed and removed again, using ajaxy goodness
Flaws
- It is approx 350K in size, when EMPTY. Any pages increase the size, and backups are accomplished by saving the ENTIRE FILE. This makes it quickly cumbersome for space (esp with auto-backup turned on, which is only logical IMHO), but also cumbersome to view history of an individual tiddler.
- There is no server-side mode, though there are plugins to assist in this
To fix
Tiddlers saved independantly to the core code. Loaded as requested.
This makes it more server-friendly, as the 'loading' can be from filesystem - for on-a-stick variety, or from a server, AJAX style, for server variety
This also makes backups more space friendly, revision history much more possible.
The backend can also be front-end agnostic. For on-a-stick style, flat files makes most sense. On a server, the (to be written, server backend code) can translate to flat files, or DB files, or sql, etc, as it sees fit.
