(This App now exists: http://wiki.colorstudy.net )
OtherWikisFeatures -- cool things found elsewhere that we should steal^H^H^H^H^Hbe inspired by.
Zope has ZWiki, why don't we have a WikiKit? We could write one from scratch or make a stub interface to one of the existing Python wikis (Twiki is working well here; there's also PikiPiki, MoinMoin, PikiePikie, Pyle). Using an existing one would, of course, allow us to leverage its features and development, but it requires kludging since none of the existing wikis were intended to be embedded thus. We could also tackle some existing problems in the wiki world, such as providing an XML DTD as a common base format for converting one wiki server's syntax to another's, and scripts for importing wiki data to/from other server's data stores.
MikeOrr - 07 Nov 2001
If we go ahead and make this, the backend should be completely independent of Webware. Only the interface should be tied to it.
Also, I prefer the names WebwareWiki and WWiki to WikiKit, but that's probably because I dislike the *kit naming scheme as whole.
-- TavisRudd - 05 Nov 2001
If you seperate out the concepts, it can be a more managable/reusable/aproachable project.
For instance, there is the WikiSyntax, which is similar to StructuredText -- but it's only societally important to the Wiki, not technically. Some Wikis use straight HTML anyway.
Then there's the editing interface. This is vaguely what I did in ComfyEdit , which is more notable to say that part isn't that hard either. Most Wikis that aren't built on object databases of some sort are actually just a set of text files that get edited. TWiki is clever enough to add RCS recording to that process as well -- but then it's just a bunch of .txt and .txt,v files.
The third important part of a Wiki is the naming and linking mechanism. Personally, I like the notion of named links ala Wiki much better than HREFs for internal links anyway. The WikiName syntax can be awkard, but the essential flat namespace could be mapped to from different syntaxes -- that's more a text formating issue.
Each of these really has a lot of value on its own. Easy text editing is nice (maybe an appropriate format for WebwareDocumentation even). Editing pages/files/objects is generally useful -- it could even be considered a subset of something that includes FTP and WebDav. The named links are also a very interesting linking idea (including backlinks); it provides an interesting alternative to hierarchical namespaces.
The lesson of WikiWiki isn't so much one of cool technologies -- it's of putting together a set of useful ideas into something that is much more than its parts. There might be other combinations that lead to other cool stuff -- if the parts are all orthogonal, we might stumble on something great.
-- IanBicking - 07 Nov 2001
Here's some ideas for possible enhancements to existing Wikis such as TWiki:
firm up the StructuredText syntax (see http://structuredtext.sf.net)
auto-syntax coloring of code listings (starting with Python, but extending to other langs)
multi-topic search and replace tool
make it possible to have non-web interfaces, along the same lines as WebDav. Think of a WikiMode for Emacs! (already kind of possible, seeing as Emacs has a web browser and speaks HTTP)
make it possible for the Wiki to understand several different WikiSyntax styles
provide conversion and import tools, like Mike suggested above
make the web interface prettier and more functional:
edit-box that spans 90% of window width rather than a fixed width _(Not possible, as far as I know)_
provide a more functional WebChanges page, or simply use a WebCVS script
make the homepage of the Wiki prettier (TWiki's is rather ugly) _(Simply because I haven't changed the templates -- not really TWiki's fault)_
make it possible to roll-back changes (to an abritrary rev. number) _(You can do this in TWiki)_
make it possible to use Subversion rather than CVS. _(Why? What is Subversion?)_
extend TWiki's concept of 'webs' to allow nesting of 'webs' (like Python's package structure. ... blends the flat namespace of traditional Wiki's with a hierarchical structure like Zope's folders.
use something other than basic HTTP authentification for logging in.
allow tight integration with the other AppIdeas that we've floated. In particular:
WebwareZope / WebwareSourceforge -- huge potential here!
WebwareForum
WebwareSlash
make it possible to embed editable regions in otherwise write-protected wiki pages (There's another Wiki that does this, but I can't remember which one)
make it possible to view/preview the contents of one WikiTopic inside another. This would be enabled via either a button on each topic or a user setting. The view/preview bit could be done in-place or via a separate frame (preferable). Think of it like the view pane in an email client. Each WikiName link would be followed by a * or some other symbol when this feature was active. Clicking on the * would display the contents of that WikiName in the view frame.
make it possible to use Templates (like Cheetah's object-orientated ones) for individual WikiTopics.
make it possible to drop in 'user interface components' such as ready built forms, surveys, etc. into a WikiTopic
make it possible to store custom meta-informational fields about WikiTopics.
-- TavisRudd - 07 Nov 2001 _(IanBicking)_