On Fri, May 6, 2011 at 11:22 AM, Brion Vibber <brion(a)pobox.com> wrote:
On Fri, May 6, 2011 at 11:20 AM, Trevor Parscal
<tparscal(a)wikimedia.org>wrote;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