WikiWithProgrammableContent aka MetaWiki
I choose a shorter name, because I think that's the natural next step in the evolution of Wiki and this needs a handy reference.
I don't say that in a non smart Wiki there are no smart people ;-).
Below is a list of this new breed of Wikis, where each user can contribute programs, readily executed/interpreted within the respective WikiEngine or at least the browser client.
-- FridemarPache
- Coldfusion
- Lisp/Scheme
- Smalltalk
- Php
- DTML/Python
- Perl
- Java
Historical note: There was a time when "Smart Terminals" took over the role of "Dumb Terminals". Smart was a synonym for programmable. -- fp
I was skeptical of this idea when it first surfaced. In the meantime, I've watched several sites attempt programmable content, only to fall prey to cross-site scripting attacks. Allowing "smart" content in the form of JavaScript is a dumb idea. -- DaveSmith
Perhaps a Wiki with calculating power could be an intermediary compromise, inspired by
http://members.aol.com/johnp71/javastat.html. -- fp
Yeah, we've already been talking about this. You need a sandboxed language.
[Could someone please AnswerMe?] I'm sure it's just my lack of imagination, but what can you see this being used for? Clearly you need the operation of the wiki itself to be protected from the scripts/programs, so what is it that the programs will be doing?
Imagination is somewhat necessary, certainly. I can imagine doing the following things with a SmartWiki:
- Writing up Interactive Tutorials and Tests on subject matter. Many people learn by doing far more readily than they learn by reading.
- Games and Small Amusements, such as going to a WikiPage to play a little SuDoku or a Pacman or Tetris clone. Given sufficient programming capabilities, interacting with two another player for some Chess wouldn't be out of line. User-extensible InteractiveFiction would also be neat. That said, most of these little amusements wouldn't be able to grow without some very nice soil... a good programming environment is needed.
- Developing a complex structured 'Object' associated with each page, potentially containing links to other objects by page name, that may then be interpreted by an ObjectBrowser or converted by a dedicated WebServer script into an HTML document. This approach would go beyond mere games and small amusements by allowing advanced development to be performed via interpretation client-side (i.e. pages would be accessible content-based rather than display-based, and so could be processed or compiled by external services).
- Creating mashups. Consider QedWiki as an example. Again, this requires some greater programmability than just a little JavaScript. Some semantics are required for accessing external services, setting up communications, building workflows, handling events, etc. Each page is an accessible 'service' rather than a static object to be presented, with much processing occurring server-side or possessing 'official' client-side semantics.
- A WikiIde where programs and libraries are developed as the primary content of WikiPages and are compiled together to create true (and optionally debuggable) services that run on the Wiki's host (or perhaps a distributed cloud of hosts). One might optionally be able to compile for packaged download, as well. Semantics exist for importing components from other pages, and potentially for controlling dependencies by limiting exports from given pages. Pages aren't (necessarily) whole objects, but are instead interpreted or compiled collectively to create the 'objects' and 'services'.
- In its (most) extreme form, a SmartWiki is essentially a full-fledged multi-user OperatingSystem that uses WikiPages for 'files', has NoApplication semantics, and has a builtin webserver and compiler and IDE.
The above require an (approximately) growing degree of programming capability for individual pages. One can also allow for a SmartWiki with a RuntimeUpgradeableCore (i.e. the ability to upgrade the WikiEngine from within the Wiki) and similar features.
A StructuredWiki? needs some sort of scripting to control how records are searched, presented, and validated.
What sort of 'control' are you envisioning? Sorry, I may be confusing your words but 'control', to me, sounds like a safety or security issue... properties that are emergent in nature and that should not be entrusted to WikiNature scripts. In any Wiki, I would imagine that content will necessarily be navigable by following links between WikiPages, and that external services will be able to provide ad-hoc search solutions. If you mean to say that the scripts should have reflective access to the Wiki such that they may be used to provide embedded ad-hoc search, presentation, and vetting-on-edit features, then I'm inclined to agree.
All useful wikis contain SmartFeatures which are programmed to perform an action when called upon by the user in this wiki:
Safe
SmartWikis will utilize similar techniques for additional features via controls which are programmed on the server side. They could include buttons, combo boxes, radio buttons, check boxes, additional text boxes, audio and video players, and many other features.
--DonaldNoyes
See also ReflectiveWiki LukesProgrammableWiki NextGenerationWiki