On Fri, May 6, 2011 at 11:22 AM, Brion Vibber <[email protected]> wrote:
> On Fri, May 6, 2011 at 11:20 AM, Trevor Parscal <[email protected]>wrote: > >> The way the WikiEditor works right now, the textbox can be replaced with >> anything that can support a few methods, such as getSelection, >> encapsulateSelection, etc. There are some modules that depend on specific >> edit box implementations, such as the current and only alternative to the >> textarea we called "iframe" since it's a contentEditable iframe. >> >> If you take a look at jquery.wikiEditor.iframe.js, you will see what I >> mean. >> It should be pretty straightforward to drop anything in there, and be able >> to take advantage of the toolbar. There are some things, like find and >> replace that may need to be reworked or just turned off, but even things >> like the link dialog should work just fine but just supporting a few >> methods. >> >> The API could be better documented, and re-factored a bit to be even more >> generic, but the basic structure is there, and can be reused without much >> hacking. >> > > 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!). > Finally got around to poking at this recently as practice for the rich editor project. CodeEditor is now implemented as an extension: http://www.mediawiki.org/wiki/Extension:CodeEditor and the gadget pulls in the JS from there -- so if you're using the gadget on mediawiki.org, it should continue to work. 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. We'll probably want to extend that API a bit further, a few offhand notes: * 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. * 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. * 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. * 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. * 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. -- brion _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
