(Cross-posting this update to wikitech-l & wikitext-l since this ties into Visual Editor project)<br><br>I've made some more updates to the CodeEditor extension & gadget demonstrating integration & adaption of the WikiEditor editor & toolbar framework.<br>
<br>The syntax-highlighting mode in CodeEditor can now be toggled on and off; when it's off, any WikiEditor functions that had been patched for CodeEditor fall automatically through to the defaults, and you get the regular textarea view.<br>
<br>(If you just want to go poke at it, scroll down to the older quoted post and follow the extension link ;)<br><br>There's a few more things I'll want to poke to make it suitable for dropping the visual editor in:<br>
<br>* a concept of 'document format' that lets us specify that certain tools are suitable for wikitext pages, while others are suitable for JS/CSS code -- this'll let things like the 'bold' and 'link' buttons hide themselves automatically on regular wiki pages, while the JS/CSS pages can automatically show tools like 'indent/deindent block', 'find declaration', 'syntax cleanup'. (Right now this can be done by manually removing/adding tools in the JS & CSS modes, but we can integrate that better -- just like the browser & RTL compatibility checks currently in some WikiEditor modules)<br>
<br>* An abstraction layer on data type / structure type? For the way tools like text insertions, link dialogs, search & replace etc work we can in many ways treat 'plain textarea', 'wikiEditor iframe with template folding', and 'Ace syntax-highting editor' as equivalent: all are views on a plain text document that can be addressed character by character, and all that needs to be implemented are the pieces to get text in and out, do selection and insert/delete, etc. For the visual editor, we'll have a document structure that's very different, so something that 'makes a section bold' would work differently: operating on a DOM-like model to move some nodes around, rather than dropping bits of text in.<br>
<br>* cleaner implementation for toggle switches on the toolbar<br><br><br>In the meantime though, I should be able to get the ParserPlayground demos more tightly integrated into the editor widget, and will try to hack up some temporary handling for the bold/italic/link etc on the provisional dom structure.<br>
<br>-- brion<br><br><br><div class="gmail_quote">On Mon, Jun 13, 2011 at 5:37 PM, Brion Vibber <span dir="ltr"><<a href="mailto:brion@pobox.com">brion@pobox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">On Fri, May 6, 2011 at 11:22 AM, Brion Vibber <span dir="ltr"><<a href="mailto:brion@pobox.com" target="_blank">brion@pobox.com</a>></span> wrote:<br></div></div><div class="gmail_quote">
<div><div></div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Fri, May 6, 2011 at 11:20 AM, Trevor Parscal <span dir="ltr"><<a href="mailto:tparscal@wikimedia.org" target="_blank">tparscal@wikimedia.org</a>></span> wrote:<br></div><div class="gmail_quote"><div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The way the WikiEditor works right now, the textbox can be replaced with<br>
anything that can support a few methods, such as getSelection,<br>
encapsulateSelection, etc. There are some modules that depend on specific<br>
edit box implementations, such as the current and only alternative to the<br>
textarea we called "iframe" since it's a contentEditable iframe.<br>
<br>
If you take a look at jquery.wikiEditor.iframe.js, you will see what I mean.<br>
It should be pretty straightforward to drop anything in there, and be able<br>
to take advantage of the toolbar. There are some things, like find and<br>
replace that may need to be reworked or just turned off, but even things<br>
like the link dialog should work just fine but just supporting a few<br>
methods.<br>
<br>
The API could be better documented, and re-factored a bit to be even more<br>
generic, but the basic structure is there, and can be reused without much<br>
hacking.<br></blockquote></div><div><br>Spiffy... I'll play with it for CodeEditor, see if I can make the special-char inserts for instance work on it (which would actually be useful for some JS!).<br></div></div></blockquote>
</div></div><div><br>Finally got around to poking at this recently as practice for the rich editor project.<br><br>CodeEditor is now implemented as an extension: <a href="http://www.mediawiki.org/wiki/Extension:CodeEditor" target="_blank">http://www.mediawiki.org/wiki/Extension:CodeEditor</a><br>
and the gadget pulls in the JS from there -- so if you're using the gadget on <a href="http://mediawiki.org" target="_blank">mediawiki.org</a>, it should continue to work.<br><br>I've also got it now working with WikiEditor's formatting toolbar (mostly), special characters list (works great!), and search & replace dialog, implementing most of the same interfaces that WikiEditor's iframe mode does.<br>
<br>We'll probably want to extend that API a bit further, a few offhand notes:<br><br>* Our jquery.textSelection module which implements the fetch-and-encapsulate-text stuff still has a few WikiEditor-specific assumptions, and probably needs to be generalized a little more.<br>
<br>* Various bits of formatting & help text that are suitable for wikitext pages are less useful when you're on a JS or CSS page. We may want to have a concept of moving up from 'generic' editor (a few generic buttons) to having a specific data format ('wiki' pages get the wikitext help; 'js' pages get a MediaWiki JS API help page; 'css' pages get a list of common selectors and a link to CSS documentation). Those should be independent of what actual *editor mode* is being used as well, so we can show JS-relevant help on a JS page even if you don't have some fancy syntax highlighting thing.<br>
<br>* For things that are 'fancy views of plain text' like the WikiEditor iframe mode and CodeEditor, the formatting toolbars etc work fairly straightforwardly; we just need to get at some selection of text, spit back a modified bit of text, and fiddle around the selection or view. This probably won't adapt so well for a rich visual editor; so we may need an adaptor layer to let plain-text and enhanced-text editors fiddle with the wikitext sample fragments while a rich editor has its own adaptor that turns high-level calls like 'wrap in a link' or 'make bold' and does the appropriate AST & view modifications.<br>
<br>* A few of WikiEditor's experimental fields require the iframe mode and force it to switch in; may need something to avoid ambiguity when we're deliberately using a different mode.<br><br>* Probably would be good to add a specific notion of switching editor modes; WikiEditor's preview tab opens up _surrounding_ the editor, but if we switch between plaintext & syntax-highlighting, we probably want a toggle on the toolbar which just swaps the guts around.<br>
<br>-- brion<br></div></div><br>
</blockquote></div><br>