Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Wikipedia: Wikitech

Alternate/remote editor API?

 

 

Wikipedia wikitech RSS feed   Index | Next | Previous | View Threaded


brion at pobox

May 6, 2011, 10:38 AM

Post #1 of 6 (443 views)
Permalink
Alternate/remote editor API?

Neil spent some time yesterday hacking with the Hackpad guys (
https://hackpad.com/ -- an Etherpad fork) experimenting with embedding the
collaborative editor via an <iframe> into MediaWiki's edit page in order to
use it to do multiuser editing.

Apparently it's pretty cool so far and I'm looking forward to seeing it
stabilized! -- but more forward-looking we're tossing the idea around the
office of having a common protocol for such editor embedding, which we can
then use for other things:

* the contentEditable mode for WikiEditor
* the Ace syntax-highlighter in CodeEditor gadget
* experimental rich text editors etc

Some of Neil & my initial notes:

http://www.mediawiki.org/wiki/Future/Hackpad/Spec


The API between the host window and the (potentially offsite) iframe would
need to handle loading initial text, saving it, and some state checks at a
minimum; depending on how much we want to integrate the WikiEditor's toolbar
portion as a standard we may need to be able to let the toolbar control
things like selection and text insertion, or each editor variant could
manage its own toolbar and that could be a WikiEditor-specific protocol
part.

Thoughts?

-- brion
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


tparscal at wikimedia

May 6, 2011, 11:20 AM

Post #2 of 6 (421 views)
Permalink
Re: Alternate/remote editor API? [In reply to]

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.

- Trevor

On Fri, May 6, 2011 at 10:38 AM, Brion Vibber <brion [at] pobox> wrote:

> Neil spent some time yesterday hacking with the Hackpad guys (
> https://hackpad.com/ -- an Etherpad fork) experimenting with embedding the
> collaborative editor via an <iframe> into MediaWiki's edit page in order to
> use it to do multiuser editing.
>
> Apparently it's pretty cool so far and I'm looking forward to seeing it
> stabilized! -- but more forward-looking we're tossing the idea around the
> office of having a common protocol for such editor embedding, which we can
> then use for other things:
>
> * the contentEditable mode for WikiEditor
> * the Ace syntax-highlighter in CodeEditor gadget
> * experimental rich text editors etc
>
> Some of Neil & my initial notes:
>
> http://www.mediawiki.org/wiki/Future/Hackpad/Spec
>
>
> The API between the host window and the (potentially offsite) iframe would
> need to handle loading initial text, saving it, and some state checks at a
> minimum; depending on how much we want to integrate the WikiEditor's
> toolbar
> portion as a standard we may need to be able to let the toolbar control
> things like selection and text insertion, or each editor variant could
> manage its own toolbar and that could be a WikiEditor-specific protocol
> part.
>
> Thoughts?
>
> -- brion
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


brion at pobox

May 6, 2011, 11:22 AM

Post #3 of 6 (417 views)
Permalink
Re: Alternate/remote editor API? [In reply to]

On Fri, May 6, 2011 at 11:20 AM, Trevor Parscal <tparscal [at] wikimedia>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!).

-- brion
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


jp.posma at gmail

May 8, 2011, 12:07 PM

Post #4 of 6 (409 views)
Permalink
Re: Alternate/remote editor API? [In reply to]

Yeap, building on WikiEditor stuff is always a good idea!

Though, in my experience with the InlineEditor extension, it's quite hard if you want to build a totally different interface. It would be awesome to refactor EditPage sometime to make this easier, and to provide a nice preference with a drop-down to select an editing interface. The relevant bug is 26918 [1] (which has actually been created because of a comment by yourself, Brion :))

The way I solved this was to create a subclass of EditPage with just enough code copy/pasted to suit my needs ;) [2]. For the API some hacking in EditPage has been done, and the class description also talks about a possible refactoring of EditPage [3].

Anyway, just a thought for the backend part of an alternate/remote editor API, for extensions that want to do more than replacing the textbox. :)

Cheers, Jan Paul

[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=26918
[2] http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/InlineEditor/ExtendedEditPage.class.php?revision=83338&view=co
[3] http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/api/ApiEditPage.php?view=co

On 6-May-2011, at 20:22, Brion Vibber wrote:

> On Fri, May 6, 2011 at 11:20 AM, Trevor Parscal <tparscal [at] wikimedia>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!).
>
> -- brion
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


brion at pobox

Jun 13, 2011, 5:37 PM

Post #5 of 6 (357 views)
Permalink
Re: Alternate/remote editor API? [In reply to]

On Fri, May 6, 2011 at 11:22 AM, Brion Vibber <brion [at] pobox> wrote:

> On Fri, May 6, 2011 at 11:20 AM, Trevor Parscal <tparscal [at] wikimedia>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
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


brion at wikimedia

Jun 17, 2011, 2:09 PM

Post #6 of 6 (344 views)
Permalink
Re: Alternate/remote editor API? [In reply to]

(Cross-posting this update to wikitech-l & wikitext-l since this ties into
Visual Editor project)

I've made some more updates to the CodeEditor extension & gadget
demonstrating integration & adaption of the WikiEditor editor & toolbar
framework.

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.

(If you just want to go poke at it, scroll down to the older quoted post and
follow the extension link ;)

There's a few more things I'll want to poke to make it suitable for dropping
the visual editor in:

* 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)

* 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.

* cleaner implementation for toggle switches on the toolbar


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.

-- brion


On Mon, Jun 13, 2011 at 5:37 PM, Brion Vibber <brion [at] pobox> wrote:

> On Fri, May 6, 2011 at 11:22 AM, Brion Vibber <brion [at] pobox> wrote:
>
>> On Fri, May 6, 2011 at 11:20 AM, Trevor Parscal <tparscal [at] wikimedia>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
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Wikipedia wikitech RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.