Moodle

Hi, Tim!

You idea with buttons is great as it allow more freedom to the users

It is also targets another issue - constant need to tell the ordinary (not from IT faculty) teachers why their choices dislpayed 'incorrectly'.
The standart Moodle way is: what is entered in line edit will be displayed as it is. So I think that 'normal' - line edit - choices must be displayed as text, and if the user want html - he/she can use htmleditor.

There are two questions with this:
1) using buttons I think there is a point in chagning default behavour: buttons must befault to not use htmleditor to speed up loading of the first page
2) choices can be entered as text of html, but we need to save them in db in one format. I think that this will be html, with conversions done to plain text.

Yes, store HTML in the database as is the case now. - but we have to be careful not to cause dataloss when a teacher using plain text editing edits a question with interesting HTML in the options.

And the state of the buttons should be stored as user preferences, so Moodle remembers how each user has it from one session to the next (the show/hide advanced buttons do this).

Well, following discussion in MDL-17064, since we get a new HTMLEditor in Moodle 2.0 that may (or may not) eliminate the main source of the issue, we must wait until Moodle 2.0 becomes sufficiently stable to test this and decide, what must be done with it.

Tim, I tested new HTMLEditor on the occasion of calculated testing on Pierre site. I'm not happy to say it, but the problem remained with new editor (thought it is slighly less annoyning, but i've not tried really big questions like something we have).

The browser pausing quite much while loading page, and the pause is proportional to the number of HTMLEditors on it. Pressing button to off it not helping at all - it's what's loading on the page that matters. So it should be solved server-side.

However, control for using HTMLEditors in repeated parts must not necessary be part of the question editing screen, if you really don't want it there. It can well be part of question configuration, or even user profile. I can accept any you suggestion on that matter.

Yes, I agree that TinyMCE is horribly slow when you have lots of them.

Before I give up, I have one remaining hope: Apparently there is an option for TinyMCE, so only one instance gets initialised on the page, and then whichever field you edit uses that instance. (It moves and attaches itself to the current text area.)

I saw that in a forum once, but I can't find it again now.

Anyway, before trying anything else, I would like to see how well that option works.

Tim wrote "Before I give up, I have one remaining hope: Apparently there is an option for TinyMCE, so only one instance gets initialised on the page, and then whichever field you edit uses that instance. (It moves and attaches itself to the current text area"

I browsed TinyMCE docs, and found no such option, but some other things to consider:
1) using tinyMCE compressor is recomended to speed up dowloading, but Moodle doesn't seems to use it now (maybe there is a reasons why, but I don't know them)
2) there is an 'ask' option, which converts textareas in TinyMCE instances asking users if they want to do so when they first focus textareas- but this may as well be annoying to the user
3) there is a mode, in which only some classes of textarea get converted (i.e. editor_selector), but docs say nothing about is this working with dinamically changing classes after the page was loaded, and so it probably not
4) instances can be added/removed dynamically by custom scripts using tinyMCE.execCommand with mceAddControl/mceRemoveControl

Is anything of this of particular interest to you?
There is also this forum post, http://tinymce.moxiecode.com/punbb/viewtopic.php?pid=22977, but it address more a problems of AJAX editing where areas may be added/deleted dynamically, which is not the case.

By the way, Tim, would you agree to change

$mform->addElement('htmleditor', 'correctfeedback', get_string('correctfeedback', 'qtype_multichoice'),
array('course' => $this->coursefilesid));
$mform->setType('correctfeedback', PARAM_RAW);

$mform->addElement('htmleditor', 'partiallycorrectfeedback', get_string('partiallycorrectfeedback', 'qtype_multichoice'),
array('course' => $this->coursefilesid));
$mform->setType('partiallycorrectfeedback', PARAM_RAW);

$mform->addElement('htmleditor', 'incorrectfeedback', get_string('incorrectfeedback', 'qtype_multichoice'),
array('course' => $this->coursefilesid));
$mform->setType('incorrectfeedback', PARAM_RAW);

on multichoice form to foreach by array('correctfeedback', 'partiallycorrectfeedback', 'incorrectfeedback')? That would lessen things to modify for both main (that may be eventually) and local modifications. I'll write a patch if it's OK.

I try to edit one of our really big multichoice questions (30 htmleditors on a page) on Moodle 2.0 with TinyMCE.
On IE6 it's pauses for several minutes at least and allocates 103 MB of memory
On Google Chrome it pauses for about 10 seconds only and use 60MB RAM.

Neither of the browser was crashed (or reverted to textarea, as it was in case of too many HTMLEditor instances), which is a good news. It may mean that such strategy may work well: convert desired textarea in TinyMCE instance only when user focuses it (initiating one instance is sufficiently fast). Too many instances by itself is not that problem if there is enough RAM (which usually is).

There are two ways to implement this:
1) easy but somewhat annoying: use "ask" mode of TinyMCE on pages with 5 (number is debatable) or more instances
2) get all fields textarea at first and initialise them later by tinyMCE.execCommand with mceAddControl when user focuses it

That way thefields user don't want to touch will never be initialised, which is generally good, but may be somewhat inconvenient if user want just see a text on some fields - he must focus on it to see it correctly (and may be confused with html if he not a programmer, we must remember not all people are).

Mozilla Firefox 3 (the same question) - 2-3 minutes (loading time mainly - actually much faster than IE6, which pauses for 10 minutes at least after loading) and 109MB of memory consumption.
I can test IE7 tomorrow. I don't have access to Unix/Apple browsers, but may attach question for importing there if anyone will want to repeat the test.

To Pierre and all: basic outline of the problems about HTMLEditors on/off. Let's suppose user X know something about HTML and user Y doesn't know what HTML is. The problem is how to better determine whether to show HTMLEditor and whether not.
One obvious case: empty comment or comment without any tags should be showed without HTMLEditors (with an ability to switch them on one by one or all at once).

Use cases:
A) User Y creates a question with complex HTML in feedback - he will want to set on the feedback fields he actually edits on this question (but maybe not the empty ones),but load time will be better if all will be textarea by default
B) User Y is editing question with some HTML feedback - he should see feedback fields with HTML tags and entities in HTMLEditor mode, to avoid been puzzled by some strange symbols he never entered
C) User X is editing question with some HTML feedback - he could see an HTML code without horror in the eyes, so the best maybe be to show all feedback editors as textarea and allow him to switch them to HTMLEditor later...

So I guess first of all we need a way to have HTMLEditor with such capabilities - hence MDL-21017 was added (Tim, could you please talk about it on hackfest?)

Note that there is more work planned on editor integration in 2.0 that should be done soon. It may be worth waiting a while.

Tim - could you add people doing this integration as a watcher there so they could know about the issue and take it into account?