On 6/1/10 8:24 AM, Roan Kattouw wrote: > 2010/6/1 Conrad Irwin<[email protected]>: > >> The other solution is to use a proper MVC framework, and define >> everything in terms of modifications to the wikitext (and you can then >> constrain what those modifications are to avoid mangling) and run that >> through a parser to generate the html preview. Alternatively, if your >> wikitext modifications are constrained enough, it is possible to >> implement modifications as a pair of functions, one of which edits the >> wikitext and the other edits the HTML (this is the method used by >> English Wiktionary for the translation adding interface - and makes >> undo/redo really easy). Building such a thing is time-consuming - >> particularly if you have to ensure that the wikitext modification and >> the HTML modification are the same - as there's a pretty large number >> of things people would like to do with wikitext. That said, it's >> pretty possible to use a wysiwyg for editing the contents of a >> paragraph, so you could have one action for "change the content of" in >> addition to actions for inserting/deleting and moving things around >> (in a perfect world, a wysiwyg would trigger constrained actions based >> on user-interaction - that is the "hard" part of this - the rest is >> just complicated). As there's already a javascript thing for general >> template arguments modifications (based on xml somehow), so this would >> be extendable to work with templates too. >> >> > This is quite close to the approach we usability devs were throwing > around some time ago: constantly work with the wikitext version of the > article to avoid problems inherent in round-tripping between wikitext > and HTML. Recently, however, Trevor's been playing around with a > different concept called block-level editing; I'll leave it to him to > elaborate on that. > > Roan Kattouw (Catrope) > > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > First off, I try not to get involved in these threads because they are almost always the same circle of "Why not?" -> "Because!" and "What if?" -> "No!", etc.
In Berlin I gave a quick demo in the UX working group of a new parser I've been writing that understands the structure and meaning of Wikitext, rather than just converting it on the fly into HTML like the current parser (actually a hybrid parser/renderer) does. To be fair, the current pre-processor does properly parse things into a node-tree, but only for a small subset of the language, namely templates. My alternative approach parses the entire wikitext document into a node-tree, which can then be rendered into HTML (or any format for that matter) or back to wikitext. By having a unified data-structure for an entire article, we can do all sorts of things that were never before possible. What we need is to be looking at building a first-class wikitext-editor, rather than adapting a buggy HTML editing system (ContentEditable). Wikitext deserves an editor that thinks in wikitext. Wikitext is a round peg, and ContentEditable is a square hole. It doesn't matter how much you try and force it in, it will never fit properly. Google has come to this conclusion after years of struggling with buggy browsers and poorly designed APIs. I would prefer not to go down a long road of hardship and struggles just to come out with a similar conclusion. - Trevor _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
