Wiklets
|
A wiklet is dynamically embedded piece of wiki content. The embedding happens with the help of client side scripting and a small flash pipe that allows the page to have truly asyncronous communications with the server. The flash movie connects the javascript object model with a remote server process.
Contents
So what?
This technique enables you to have a truly dynamic web page that never needs to reload and can change dynamically based on external content. The external content can trigger changes in your current page. In this way the page becomes more of a view or channel rather than the static pages we are used to.
Applicational content
We'd like many of the wiklets to be able to contain applicational content similar to dialog boxes; collections of functionality. The layout and integration of functionality with content can be achieved with the current templates/variables/parser-functions way of working, with CSS being used for the overlayed style aspect like usual.
A simple convension needs to be created which allows functions in wiki articles to be added to the events in both the MediaWiki hooks and the JavaScript environment. Parser functions and templates already have a useful way of handling parameters of both the list or associative kind. A simple means of "commanding" the wiki to return certain content based on dynamic parameters passed in the URL could be to add a new query item called content. This would be used instead of reading content from the article specified by the title item, allowing the current live content to use dynamic parameters too.
# The current way $wgServer?title=Foo&live # New way $wgServer?content=((:Foo|bar=baz}}
Actions
There will be two actions which will be implemented by the livelets extension instead of the current live query-string item. The first is naked which means to return the fully parsed HTML content of the request, but not wrapped into a skin. The second action is plain which also returns the naked content, but it is returned after the templates and parser functions have expanded, but before converting to HTML.
Another MediaWiki feature comes out of the woodwork! I came across a section in the manual called parameters to index.php, which shows that MediaWiki already supports the actions we need.
- render: Using action=render has been available at least as far back as 1.6 and replaces the necessity for action=live in the livelet extension.
- raw: The usual action=raw request comes with some extra parameters, some of them have been commonly used, such as gen and ctype, but another very useful one is templates=expand. This can used by bots requesting code articles or lists etc, it expands the templates but returns the content before parsing any wikitext into HTML. Category links will still be included though because they're processed along with normal links (categories should have been parser-functions I reckon).
Wikilets extension
The wiklets extension adds the JavaScript functions to $wgOut which allow the creation and manipulation of wiklets. Wiklets can be created over any existing content, but we will also be creating a desktop skin especially designed for working with wiklets.
- Wiklet JavaScript functions
- Create/Delete
- Front/Back
- Position/Size
- ProcessMessage (update properties or content of a livelet by id - create new livelet if id non-existent)
Forms
All the supported input types can easily be made from templates and have various parameters passed to manipulate their prperties and id etc. Forms are then just collections of these.
The Wiklets way of "executing" articles with parameters is to use the text item in the query string instead of specifying an article title. Forms could use this method too, by attching JavaScript functions to the forms buttons which use xmlhttp to compose the forms values into a wikitext statement and send it to the wiki.
If an id is sent in the query string, then the response will be returned to the livelet with that id (this could support lists of id's too for one-to-many communications), or will create a new livelet if the id is zero. If no id is sent, the response will be directed to the livelet that requested it.
Events
The event structure reflects change in a node in the tree structure. When an event occurs the event state is communicated to the server in cases where a server response is needed. In cases where this is not required, javascript generated code does client side processing to update the state of the interface.
Some examples of events that would be communicated back to the server.
- dragEnd
- reloadRequest
Data structures
There must be a tree of id's which are navigatable by class, so that each running wiklet can address items within it by class. The items id (guid) is then used by the server to communicate results when ready.
Full P2P can be done with standard browser
It would be useful to allow all the SWF's on a single machine to communicate together to designate one of them to communicate with the server. But if we had that capability, it would make sense to allow each SWF to be connected with a different "server" (peer), and to abstract this to allow the opening of arbitrarily many asyncronous connections
