Realized I never sent an announcement here. I think you folks'd be really interested in checking out what we've been working on:
We just did our first general-public software release.
There's lots of cool stuff going on. Having worked on the DavisWiki (http://daviswiki.org) code for many, many years [which was a fork of MoinMoin], we really relished the opportunity to design a new, modern wiki engine without the burden of legacy support.
Cool bits:
* Everything is stored as HTML5. We threw out wiki markup. * Visual editing! And it's consistent and fun! * .. Using a highly-hacked ckeditor. We're hoping to work on the new visualeditor ya'll have been working on. Exciting! * The basis of our work was creating a flexible versioning, diffing and merging framework for Django, called django-versionutils. With this, we can easily version any Django model, diff any Django fields, and create new, custom diff handlers (for, say, GeometryFields or ImageFields :) This allows us to wiki-fy any sort of structured data, too. * this lets us make things like versioned, diffable comments a'la liquidthreads really easily. * Really cool map stuff / really-easy map editing :)
I made this code walkthrough screencast a few months back which you might find interesting: http://vimeo.com/25385510 (though it's a bit long -- sorry!)
& we've got a dev site here: https://dev.localwiki.org
Anyway, would love to work together on anything and everything we can! (WMF folks: we're in SF, too)
-Philip
(Apologies if you're seeing this email twice. My first send was apparently silently rejected)
----- Original Message -----
From: "Philip Neustrom" philip@localwiki.org
We just did our first general-public software release.
- Everything is stored as HTML5. We threw out wiki markup.
I hope that works out well for you.
Cheers, -- jra
On Wed, Dec 14, 2011 at 12:40 PM, Philip Neustrom philip@localwiki.orgwrote:
Realized I never sent an announcement here. I think you folks'd be really interested in checking out what we've been working on:
We just did our first general-public software release.
There's lots of cool stuff going on. Having worked on the DavisWiki (http://daviswiki.org) code for many, many years [which was a fork of MoinMoin], we really relished the opportunity to design a new, modern wiki engine without the burden of legacy support.
Cool -- I really like what you guys are doing with the map-drawing interface! We may wish to steal some of that code at some point. ;)
-- brion
* Philip Neustrom philip@localwiki.org [Wed, 14 Dec 2011 12:40:55 -0800]:
Realized I never sent an announcement here. I think you folks'd be really interested in checking out what we've been working on:
We just did our first general-public software release.
There's lots of cool stuff going on. Having worked on the DavisWiki (http://daviswiki.org) code for many, many years [which was a fork of MoinMoin], we really relished the opportunity to design a new, modern wiki engine without the burden of legacy support.
Cool bits:
- Everything is stored as HTML5. We threw out wiki markup.
I am not so sure that threwing out wiki markup is so good thing. It's more compact (takes less storage space) and allows to format text quite fast to everyone who is familiar to wiki markup. If you are using HTML5, that means the extensions (parser functions) has to be implemented as XML tags, which are quite tiresome to input directly, so the extensions will probably require visual editor addons. Raw text editing simplifies implementation of markup extensions, some developers might do not have enough free time to develop their own visual editor extensions. That's why raw wikitext can be useful and time-saving. Dmitriy
cool idea. i liked the the map part most. can we try to add this on wikipedia?
thanks nasir
On Thu, Dec 15, 2011 at 11:41 AM, Dmitriy Sintsov questpc@rambler.ruwrote:
- Philip Neustrom philip@localwiki.org [Wed, 14 Dec 2011 12:40:55
-0800]:
Realized I never sent an announcement here. I think you folks'd be really interested in checking out what we've been working on:
We just did our first general-public software release.
There's lots of cool stuff going on. Having worked on the DavisWiki (http://daviswiki.org) code for many, many years [which was a fork of MoinMoin], we really relished the opportunity to design a new, modern wiki engine without the burden of legacy support.
Cool bits:
- Everything is stored as HTML5. We threw out wiki markup.
I am not so sure that threwing out wiki markup is so good thing. It's more compact (takes less storage space) and allows to format text quite fast to everyone who is familiar to wiki markup. If you are using HTML5, that means the extensions (parser functions) has to be implemented as XML tags, which are quite tiresome to input directly, so the extensions will probably require visual editor addons. Raw text editing simplifies implementation of markup extensions, some developers might do not have enough free time to develop their own visual editor extensions. That's why raw wikitext can be useful and time-saving. Dmitriy
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, Dec 14, 2011 at 9:41 PM, Dmitriy Sintsov questpc@rambler.ru wrote:
- Philip Neustrom philip@localwiki.org [Wed, 14 Dec 2011 12:40:55
-0800]:
Realized I never sent an announcement here. I think you folks'd be really interested in checking out what we've been working on:
We just did our first general-public software release.
There's lots of cool stuff going on. Having worked on the DavisWiki (http://daviswiki.org) code for many, many years [which was a fork of MoinMoin], we really relished the opportunity to design a new, modern wiki engine without the burden of legacy support.
Cool bits:
* Everything is stored as HTML5. We threw out wiki markup.
I am not so sure that threwing out wiki markup is so good thing. It's more compact (takes less storage space) and allows to format text quite fast to everyone who is familiar to wiki markup. If you are using HTML5, that means the extensions (parser functions) has to be implemented as XML tags, which are quite tiresome to input directly, so the extensions will probably require visual editor addons. Raw text editing simplifies implementation of markup extensions, some developers might do not have enough free time to develop their own visual editor extensions. That's why raw wikitext can be useful and time-saving.
Keep in mind that with our generic versioning framework we can version and diff any structured data, independent of wiki page content. So there's probably no need to stuff extension invocation inside of page content.
Page-content plugins will need editor plugins, yeah (like our "include page" plugin). But I think that's a good thing.
The concerns you raise are probably valid for Wikipedia. We're working with new communities, for the most part. (and our work isn't based on MediaWiki - not sure if I made that clear in my original message).
--Philip
Dmitriy
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
* Philip Neustrom philip@localwiki.org [Thu, 15 Dec 2011 14:50:32 -0800]:
Keep in mind that with our generic versioning framework we can version and diff any structured data, independent of wiki page content. So there's probably no need to stuff extension invocation inside of page content.
Extension invocation inside of page content allows to build very flexible dynamic layout. One can mix output of various extensions (audio, video, forms) to create new functionality.
Page-content plugins will need editor plugins, yeah (like our "include page" plugin). But I think that's a good thing.
How do these plugin work when there is no XML "injection" into page content? How the final layout is being build?
The concerns you raise are probably valid for Wikipedia. We're working with new communities, for the most part. (and our work isn't based on MediaWiki - not sure if I made that clear in my original message).
To the MediaWiki extension I develop, visual editor probably will multiply the amount of code by the factor of two. So, yes, programmer's life is much easier without that. However you are right, end-user will prefer visual editor. Dmitriy
Page-content plugins will need editor plugins, yeah (like our "include page" plugin). But I think that's a good thing.
How do these plugin work when there is no XML "injection" into page content? How the final layout is being build?
We take the HTML5 that's stored and, before rendering it, transform certain bits into functions. Right now we go HTML5 -> Django template, and turn certain specially-registered HTML bits into Django template tags (functions). We can then cache the Django template. We're going to make registering a new page plugin easier (no HTML traversal) soon.
Here's the docstring describing how we've got inside-page plugins working:
Conversion of HTML into template with dynamic parts.
We want to allow some dynamic content that gets inserted as the HTML is rendered. This is done by converting certain HTML tags into template tags. There are two mechanisms to do this: plugin handlers and tag handlers.
Plugins are meant for inserting bits of dynamic content at specific places on the final rendered page marked by a placeholder element. The output can be whatever you like: widgets, bits of JavaScript, anything. Tag handlers, on the other hand, are meant for fixing up the HTML slightly and transparently, i.e., fixing links and adding helpful visual styles and the like. When in doubt, use plugins.
Plugin handlers work with HTML elements that have the class "plugin". When an element has the class "plugin", it will be passed to registered handlers based on the other classes it has.
For example, the following element will be passed to the handler registered for the "includepage" class:
<a href="Navigation" class="plugin includepage">Include Navigation</a>
which will convert it to this:
{% include_page "Navigation %}
to be rendered by the include_page template tag.
Tag handlers work similarly, but they are applied by element tag instead of by class. They are best used for routine processing of content, such as styling.
For example, to mark links to non-existant pages with a different style, this: <a href="My Page">My Page</a> gets converted to this: {% link "My Page" %}My Page{% endlink %} and rendered as appropriate by the LinkNode class.
On 17.12.2011 6:01, Philip Neustrom wrote:
Page-content plugins will need editor plugins, yeah (like our "include page" plugin). But I think that's a good thing.
How do these plugin work when there is no XML "injection" into page content? How the final layout is being build?
We take the HTML5 that's stored and, before rendering it, transform certain bits into functions. Right now we go HTML5 -> Django template, and turn certain specially-registered HTML bits into Django template tags (functions). We can then cache the Django template. We're going to make registering a new page plugin easier (no HTML traversal) soon.
Here's the docstring describing how we've got inside-page plugins working:
Conversion of HTML into template with dynamic parts.
We want to allow some dynamic content that gets inserted as the HTML is rendered. This is done by converting certain HTML tags into template tags. There are two mechanisms to do this: plugin handlers and tag handlers.
Plugins are meant for inserting bits of dynamic content at specific places on the final rendered page marked by a placeholder element. The output can be whatever you like: widgets, bits of JavaScript, anything. Tag handlers, on the other hand, are meant for fixing up the HTML slightly and transparently, i.e., fixing links and adding helpful visual styles and the like. When in doubt, use plugins.
Plugin handlers work with HTML elements that have the class "plugin". When an element has the class "plugin", it will be passed to registered handlers based on the other classes it has.
For example, the following element will be passed to the handler registered for the "includepage" class:
<a href="Navigation" class="plugin includepage">Include Navigation</a>
which will convert it to this:
{% include_page "Navigation %}
to be rendered by the include_page template tag.
Tag handlers work similarly, but they are applied by element tag instead of by class. They are best used for routine processing of content, such as styling.
For example, to mark links to non-existant pages with a different style, this: <a href="My Page">My Page</a> gets converted to this: {% link "My Page" %}My Page{% endlink %} and rendered as appropriate by the LinkNode class.
{%%} syntax looks really "wiki-like". That's a kind of reverse logic, comparing to MediaWiki, where parser functions are converted to HTML output, not opposite. What's really important, parser functions can be nested (and by using proper parser frame parser tags probably can be nested as well - I haven't tried that yet but might try soon). Can LocalWiki template tags be nested as well? Dmitriy
{%%} syntax looks really "wiki-like". That's a kind of reverse logic, comparing to MediaWiki, where parser functions are converted to HTML output, not opposite. What's really important, parser functions can be nested (and by using proper parser frame parser tags probably can be nested as well - I haven't tried that yet but might try soon). Can LocalWiki template tags be nested as well?
The template tags can be nested, yeah. Chaining in templates is usually achived using template filters, though, a'la https://docs.djangoproject.com/en/dev/ref/templates/builtins/?from=olddocs#s....
Our goal with the template representation stuff was to leverage as much of the existing Django ecosystem as possible. For instance, we were able to use a common thumbnailing template tag library without modification. But in general, if you want dynamic bits in pieces inside of a serializable/cachable mostly-HTML document, a Django template kinda makes sense.
We'll likely kill off the explicit {% .. %} syntax and build the template tree manually in order to simplify the process of writing page plugins.
--Philip
- The basis of our work was creating a flexible versioning, diffing
and merging framework for Django, called django-versionutils.
The WYSIWYG document diff with change walk-through looks very nice! How do you identify changes to a document in the visual editor? Do you just compare the output, or do you track touched regions?
Gabriel
wikitech-l@lists.wikimedia.org