Safari en Moodle werken niet goed samen

Safari en Moodle werken niet goed samen

door Henk Visser -
Aantal antwoorden: 16
Ik ben een tevreden iMac gebruiker. Voor Moodle ben ik overgestapt van Safari naar Firefox.

In Safari hebben de vragen die ik maak ineens een "code editor" en niet de wyswyg editor. Als ik iets wil nakijken werkt ook de editor niet echt soepel.

Ik zou echter liever Safari gebruiken.
Is het misschien een instelling die ik over het hoofd heb gezien?


Gemiddelde van de beoordelingen:  -
Als antwoord op Henk Visser

Re: Safari en Moodle werken niet goed samen

door Ger Tielemans -

Heel veel Amerikaanse Moodle gebruikers hebben Macs maar raden als Mac gebruiker het gebruik van Safari af, omdat dat te weinig ondersteunt: ook de Safari versie onder Windows is beperkt: ook hier geen WYSIWYG. (al valt afspelen van Multimedia en embedded filters wel mee: alleen .avi en .wmv van embedded filter doet het niet, maar ja dat is Micorsoft formaat..)

advies van hen: gebruik Firefox (doen zij ook.)

Gemiddelde van de beoordelingen:  -
Als antwoord op Ger Tielemans

Re: Safari en Moodle werken niet goed samen

door Henk Visser -
Ger,
Bedankt voor je advies. Ik was er al bang voor maar wilde het toch even checken.

Gemiddelde van de beoordelingen:  -
Als antwoord op Henk Visser

Re: Safari en Moodle werken niet goed samen

door Hans de Zwart -
Hoi Henk,

De huidige HTML editor in Moodle is HTML Area. Dit is een stukje software waar al tijden niet meer aan gewerkt is. Er is daarom besloten om voor Moodle 2.0 een nieuwe HTML editor te implementeren: TinyMCE. Deze is veel moderner en werkt ook perfect op Safari en Opera.
Martín Langhoff heeft net voor Moodle op de XS (van OLPC) TinyMCE gebackport naar 1.9. Als je dus haast hebt moet je even zoeken in de Engelstalige forums.

Succes!

Hans
Gemiddelde van de beoordelingen:  -
Als antwoord op Hans de Zwart

Re: Safari en Moodle werken niet goed samen

door Ger Tielemans -

Bespaar je de moeite van het downloaden: TinyMCE zit al jaren in je eigen distributie als tweede editor. Er is wel sinds kort de eerste patch voor TinyMCE, reden waarom ik er opnieuw naar gekeken heb, maar weer heb laten varen vanwege het ontbreken van support voor de andere plugins.

(Kijk bijvoorbeeld maar eens je eigen 1.6, 1.7 of 1.8 na: \lib\editor\tinymce
Ik vermoed trouwens al eerder, maar die heb ik hier niet snel bij de hand.)

Maar de meeste mensen gebruiken Moodle zoals het gedistribueerd wordt en dat is met overal htmlarea ingeschakeld.

Zolang het geen "switch" wordt die je even omzet als admin zullen de meeste gebruikers htmlarea blijven gebruiken EN zullen de meeste plugins zoals mijn twee favorieten: de audiorecorder NANOGONG en de LEGO-formule editor DRAGMATH eerst voor die htmlarea editor geschreven worden.

je moet Safari ook in het licht zien van de quasi-haat van Apple jegens Microsoft om de klant zogenaamd vrije keuze te laten, zo ook hun "onafhankelijk image" bij de keuze van support.

Ik zeg quasi: wie is immers aandeelhouder en sinds jaar en dag hofleverancier met bijvoorbeeld Powerpoint dat eerst door het Mac-team van Microsoft voor de Mac geschreven is en later pas terug geport naar Windows?
(jongelui, ik praat hier wel over 1988 glimlach)

P.S. Ik heb nu ook een nieuw laptop met zo'n nutteloos logo in de achterklant van mijn scherm, dus ik zie het zelf nooit als het aan is. Zonde van de accustroom. In mijn geval geen apple maar het logo van een op uiterlijk vertoon concurrerende firma.


Er is ook een grote kloof tussen wat Martin en de Moodle partners wensen en de echte gebruikers doen:

  • Na versie 1.3 zou er geen tussenversie meer komen maar zou er een remake 2.0 komen, we zitten nu op 1.9.dinges
  • Kijk in de moodle.org forums wat de mensen gebruiken: ik zie een heel druk forum voor HTML editor, maar voor TINYmce bestaat nog niet eens een eigen forum (de vragen zitten verstopt tussen de vragen van het html editor forum)
  • Kijk ook in de distributie waar de makers op aansturen: standaard staat journal gedimd in de 2.0 distributie, dus die moet verdwijnen, vinden ze.. enz

Gemiddelde van de beoordelingen:  -
Als antwoord op Ger Tielemans

Re: Safari en Moodle werken niet goed samen

door Ger Tielemans -

Als Moodle ECHT Object Oriented was gebouwd, had je gewoon kunnen zeggen: roep overal voortaan de tinyMCE aan ipv de HTMLarea.

Het enige onderdeel dat object oriented "oogt" is het overal in de cursus-sections kunnen initialiseren van nieuwe instances van activiteitmodules - waar andere ELO's vaak moeten verwijzen naar bestaande activiteiten - en dat is een godsgeschenk!  

Gemiddelde van de beoordelingen:  -
Als antwoord op Ger Tielemans

Re: Safari en Moodle werken niet goed samen

door Christian Bokhove -
Een andere modulaire aanwinst zijn de question types.
Gemiddelde van de beoordelingen:  -
Als antwoord op Christian Bokhove

Re: Safari en Moodle werken niet goed samen

door Ger Tielemans -
Mee eens, maar ook dat is meer plug&play - vergelijkbaar met het toevoegen van modules en blokken - dan echt Object Oriented.
Gemiddelde van de beoordelingen:  -
Als antwoord op Ger Tielemans

Re: Safari en Moodle werken niet goed samen

door Hans de Zwart -
Hoi Ger,

In principe kun je al zeggen dat voortaan overal tinyMCE in plaats van HTML area aangeroepen moet worden. Dat is de reden waarom het voor ontwikkelaars makkelijk was om te experimenteren met meerdere editors voor Moodle 2.0. Dit heeft eigenlijk niets met Object Oriented te maken: het aanroepen van de editor gebeurt in een paar functies en die zijn makkelijk over te zetten.
Het probleem zit meer in het de integratie van de editor met andere Moodle functionaliteit: bij het invoegen van plaatjes en links moet er gecommuniceerd worden met de cursus bestanden. Dat is maatwerk en dat moet voor elke editor opnieuw geïmplementeerd worden.
Overigens is er in Moodle tegenwoordig heel veel object-geörienteerde code (in de vorm van classes) te vinden. Als je bijvoorbeeld een nieuw database veld wil aanmaken kun je dat doen door maar een paar methoden van een klasse te overschrijven. Dit is ook de reden waarom PHP5 versie 2.0 een vereiste zal zijn.
Moodle heeft meer last van het feit dat het niet volgens een MVC architectuur is opgezet. Die drie aspecten lopen bij Moodle op veel pagina's nog door elkaar waardoor je bijvoorbeeld niet heel flexibel met de vormgeving om kunt gaan.

Vr. groet,

Hans
Gemiddelde van de beoordelingen:  -
Als antwoord op Hans de Zwart

Re: Safari en Moodle werken niet goed samen

door Ger Tielemans -

..het aanroepen van de editor gebeurt in een paar functies.

 bekijk de code eens echt goed.. Dat aanroepen gebeurt op wel erg veel plaatsen en onnodig vaak ook nog: laat ik één voorbeeld geven:

Elke mod-form.php (óók nog steeds in de actuele CVS van versie 2.0) van een module bevat meestal tweemaal de aanroep van de HTML editor:

$mform->addElement('htmleditor', 'summary', get_string('summary'));

en

$mform->addElement('htmleditor', 'description', get_string('description', 'assignment'));

Op zich mooi, dezelfde functie met verschillende parameters aangeroepen, maar...

Met 20 modules (maar een beetje Moodle telt er meer..) moet je dus 20x2 deze code in dit ene formulier vervangen..

Was de editor een OO object geweest, dan zou ik IN dat editor-object htmlarea kunnen veranderen in tinymce ZONDER dat ik het  verschillende gebruik in de aanroepen elders zou hoeven wijzigen. En het afhandelen van de plaatjes en links zou in dat ene object al universeel geregeld zijn, En ja.. dat kan echt.

Ik ga nog een stap verder: was mod_form zelf een echt OBJECT ORIENTED object geweest dan zou ik ook de andere elementen van dat mod_formulier niet op 20 plaatsen hoeven te wijzigen (zoals ons aanvink-veldje dat we nu overal, dus 20x bij elke update, los moeten toevoegen.


MVC is door de makers van Smalltalk80 van Xerox parc (Adele Goldberg en Alan Kay) in de jaren 70 en 80 in het begin omarmd als een ontwerp hulmiddel, maar later als te beperkt weer verlaten. (Persoonlijk vind ik het nog steeds een mooi concept voor ontwerpers van userinterfaces, maar daar gaat het hier niet om.) Handiger is het om te praten over zelfstandige objecteRebecca Wirffsn die contracten met elkaar sluiten: lees bijvoorbeeld het boek van Rebecca Wirffs-Brock over object oriented design.

Gemiddelde van de beoordelingen:  -
Als antwoord op Ger Tielemans

Re: Safari en Moodle werken niet goed samen

door Hans de Zwart -
Hoi Ger,

In het formulier wordt met jouw code een HTML editor aangeroepen en niet HTML Area. Dit wordt gedaan binnen de formulier klasse. In de formulier klasse wordt (neem ik aan zonder de code na te pluizen) eerst gekeken of de persoon in het profiel wel een HTML editor aan heeft staan en op basis daarvan wordt een HTML editor geladen. Op die plek zou je dus HTML Area vervangen door TinyMCE. Als je dat in alle formulieren x 2 doet ben je niet handig bezig.
Als er in Moodle een formulier wordt gebruikt, dan is dat een instantie van het formulier object. Je kunt daar dus compleet object oriented mee omgaan.

MVC is op dit moment trouwens de manier om heel snel uiterst functionele webapplicaties te maken. Het ligt bijvoorbeeld aan de basis voor het succes van Ruby on Rails en is ook het kloppend hart van het Zend PHP Framework.

Vr. groet,

Hans
Gemiddelde van de beoordelingen:  -
Als antwoord op Hans de Zwart

Re: Safari en Moodle werken niet goed samen

door Ger Tielemans -

Mmm, slimme redenering, ik ga dat even napluizen. (Al kan ik daar mijn aanvinkvakje niet op die manier kwijt.)

MVC lijkt handig bij je eerste ontwerp van webinterfaces, maar al snel lopen zaken door elkaar: bijvoorbeeld, een visuele knop waarvan de functie "uit" staat, is zowel onderdeel van de control als van de view (hij moet er gedimd uitzien). Voor het echte functionele ontwerp is UML toch de belangrijkste tool geworden.

P.S. Hans, is de plugin voor het aanroepen van edustandaard al weer nagegeken? 

Gemiddelde van de beoordelingen:  -
Als antwoord op Ger Tielemans

Re: Safari en Moodle werken niet goed samen

door Hans de Zwart -
P.S. Hans, is de plugin voor het aanroepen van edustandaard al weer nagegeken?
Helaas nog niet. Ik ga hier intern eens overleggen of we hier prioriteit van gaan maken. De ontwikkelingen rondom Edurep hebben namelijk niet stil gestaan en er gebeuren daar interessant dingen.

Vr. groet,

Hans
Gemiddelde van de beoordelingen:  -
Als antwoord op Ger Tielemans

[OT] Moodle Object Classes

door Ger Tielemans -

Hans, we dwalen in deze discussie wel erg af van de Safari vraag: off topic

..ik heb wat je suggereerde opgezocht. Dit lijkt de plaats waar de switch tussen de htmlarea en de textarea wordt gemaakt.
(De check of de html-editor gebruikt kan worden is dan al gedaan.)

Hier zou je dus ook de plugin-ruimte/keuze-switch verwachten voor TinyMCE, maar ik zie hem niet, jammer, zou veel werk schelen. (ik neem als leek aan dat die technische check voor TinyMCE straks hetzelfde is en ook de gebruikers-keuze in het profiel identiek zal verlopen: in het profiel van de gebruiker zou je de keuze tussen beide editors als derde optie verwachten, zo ook in de algemene instellingen van de admin-pagina's.) 

Dat lijkt me echt werk voor de echte ontwikkelaars, die wellicht een plaats weten waar het nog beter kan worden ingevoegd. Op dit moment zie ik geen code, vriendelijk op één plaats, wel zie ik erg veel code herhaling:

in jouw lijn redenerend zou ik een objectklasse verwachten voor mod-form.php dat aangeroepen wordt door de modules, in werkelijkheid zie ik steeds dezelfde regels code herhaald worden in alle mod-forms (en bij een CVS update collectief gecorrigeerd worden, beseffend dat daar wel een programmeur bezig geweest moet zijn om op al die 20 plaatsen die code aan te passen.)

Er kan natuurlijk altijd een andere reden voor zijn, bijvoorbeeld performance, omdat object oriented in het verleden zelden tot de snelste code leidde.. 


Dit is wat ik vond in /lib/form/htmleditor.php van 1.9.2:


class MoodleQuickForm_htmleditor extends MoodleQuickForm_textarea{
    var $_type;
    var $_canUseHtmlEditor;
    var $_options=array('canUseHtmlEditor'=>'detect','rows'=>10, 'cols'=>45, 'width'=>0,'height'=>0, 'course'=>0);
    function MoodleQuickForm_htmleditor($elementName=null, $elementLabel=null, $options=array(), $attributes=null){
        parent::MoodleQuickForm_textarea($elementName, $elementLabel, $attributes);
        // set the options, do not bother setting bogus ones
        if (is_array($options)) {
            foreach ($options as $name => $value) {
                if (isset($this->_options[$name])) {
                    if (is_array($value) && is_array($this->_options[$name])) {
                        $this->_options[$name] = @array_merge($this->_options[$name], $value);
                    } else {
                        $this->_options[$name] = $value;
                    }
                }
            }
        }
        if ($this->_options['canUseHtmlEditor']=='detect'){
            $this->_options['canUseHtmlEditor']=can_use_html_editor();
        }
        if ($this->_options['canUseHtmlEditor']){
            $this->_type='htmleditor';
            //$this->_elementTemplateType='wide';
        }else{
            $this->_type='textarea';
        }
        $this->_canUseHtmlEditor = $this->_options['canUseHtmlEditor'];
    }
...

Gemiddelde van de beoordelingen:  -
Als antwoord op Ger Tielemans

Re: [OT] Moodle Object Classes

door Hans de Zwart -
Hoi Ger,

Ook daar wordt niet bepaald welke HTML editor gebruikt wordt. Dat zit namelijk in use_html_editor() functie in lib/weblib.php.

De object klasse wordt bij elk formulier geladen. Door de code:

class mod_assignment_mod_form extends moodleform_mod {

function definition() {
global $CFG;
$mform =& $this->_form;

wordt er een subklasse van de klasse moodleform_mod gemaakt. Die regelt dat allemaal zaken makkelijk gedeeld kunnen worden (bijv. de manier waarop velden gevalideerd worden). Dat elke veld in de code wordt toegevoegd is logisch: alle formulieren doen toch iets anders?

Vr. groet,

Hans
Gemiddelde van de beoordelingen:  -
Als antwoord op Hans de Zwart

Re: [OT] Moodle Object Classes

door Ger Tielemans -

Klopt! Daar zie ik inderdaad de mogelijkheid om een alternatieve editor in te pluggen: dus hier zou je met een pennestreek de TinyMCE kunnen invullen?

Ik kijk normaal liever niet zo diep in de code: voor je het weet ga je het veranderen. nZijn er meer van die "op een plek aanpassen opties?"


Op het punt van mod_form.php (en herhalingen van code elders) blijf ik van mening dat er meer overeenkomsten dan verschillen zijn tussen de invulschermen van de modules, waarbij de aanroep al vast ligt in de naam van de module: helpknop bij assignment roept uiteraard help voor assignment aan, enz.

Het stoort me daarom vooral omdat men "ergens" de structuur van de module ingrijpend gewijzigd heeft: je zit nu met twee soorten modules:

  • de oudere met mod.html
  • de nieuwere met mod_form.php

Zou men de functionaliteit dieper wegstoppen in de klassen/objecten, dan zou de aanroep op module niveau hetzelfde gebleven zijn, en zou de verandering alleen in het object zelf hebben plaats gevonden, onzichtbaar voor de gebruiker van de objecten omdat die slechts de diensten van het object aanroept.

Gemiddelde van de beoordelingen:  -
Als antwoord op Henk Visser

Re: Safari en Moodle werken niet goed samen

door Henk Visser -
Bedankt voor julle altijd weer rappe reactie.
Inmiddels heb ik een andere browser gevonden die wel erg goed met moodle werkt, n.l. CAMINO.
Alles wat Safari niet doet, doet Camino wel.
Hoewel ik in den beginne een Netscape gebruiker was en om die reden naar Firefox heb gegerepen, vind ik hem een beetje " log" en zwaar. Dit kleine Caminootje bevalt mij nu al beter dan Firefox.

Probleem opgelost.smile


Gemiddelde van de beoordelingen:  -