Thema: Mehrere mootools Scripte wollen nicht miteinander...

Hi,

ich habe für mein Registrierungsformular 2 mootools scripte benutzen wollen, die nicht so recht miteinander wollen. Ich bin kein Profi in JS, aber das Problem was ich hier habe erschließt sich mir nicht ganz und ist total "komisch", von daher hoffe ich dass ich etwas ganz einfaches übersehe. Manch einer kann auch den Text überspringen und nur den fetten Absatz lesen.

Die Klassen:

- einmal die FormCheck-Klasse von hier: http://mootools.floor.ch/en/ (wobei ich woanders eine von einem User an die Mootools 1.3 angepasste Version benutze)
- und die MooTabs-Klasse von hier http://3dolab.github.com/MooTabs/

Die Formcheck-Klasse ist dafür gedacht als Parameter die ID der <form> mit paar Optionen zu erhalten. Durch eine "bestimmte" Aufteilung des Formulars (siehe http://3dolab.github.com/MooTabs/) kann ich das Formular in Tabs aufteilen, zwischen denen ich mit Buttons hin- und herwechseln kann. Da ich nur ein <form> element haben kann, habe ich probiert anstatt des <form>'s einfache DIVs an die FormCheck-Klasse zu übergeben, was auch wunderbar funktioniert (dies ist wohl so, weil die Klasse innerhalb des übergebenen Elements einfach nach Elementen mit der bestimmten Klasse sucht [this.form.getElements("*[class*=validate]")]).

Jetzt möchte ich nachdem ich das Registrierungsformular in Tabs aufgeteilt habe vor dem Wechseln von einem Tab zum nächsten den ersteren Tab validieren. Es gibt eine Methode innerhalb der FormCheck-Klasse (isFormValid()), welche ich benutze um die einzelnen Instanzen (=Tabs) zu überprüfen.

Das Problem ist, dass sobald der erste Tab valide ist und er auf den zweiten wechselt, er im zweiten Tab (was ja eine andere Instanz der FormCheck-Klasse ist) sofort die Elemente überprüft, was garnicht gewollt ist da ja noch nichts eingegeben wurde. Noch schlimmer wird das ganze weil dieser Übergang von einem Effekt begleitet wird, welcher "zerschossen" wird. Da der zweite Tab eine andere Instanz ist und ich diese zu diesem Zeitpunkt garnicht "angerührt" habe, wundere ich mich warum dort dennoch sofort alle Elemente überprüft werden.

Hier mein JS Code (siehe Kommentare):

Code:

window.addEvent('domready', function() {

	var tabs = $$('.tabs');
	var contents = $$('.tabcontent');
	var tabView = new MooTabs(tabs, contents, {
		autoPlay : false,
		loop : false
	});
	var anzahlSteps = $('tabcontent').getChildren().length; // damit weiß ich wieviele Tabs ich insgesamt habe, da es variieren kann
	var formchecks = new Array(anzahlSteps - 1);

	for (i = 0; i < anzahlSteps; i++) {

		formchecks[i] = new FormCheck('step' + (i + 1), { // erstelle ein Array mit allen FormCheck-Instanzen (=Tabs), die Tabs mit den Inhalten haben immer die id=step1, step2, etc
			// submit : false,
			// onValidateSuccess : function() { // mit diesem Event könnte ich nur was anfangen, wenn ich mehrere <forms>-hätte und alle Elemente per AJAX absenden würde
				// tabView.nextSlide();
			//	console.log('validatesuccess');
			//}
			
		});

	}

	$$('.next').each(function(button, i) { // in jedem Tab (=DIV) gibt es einen Satz "next" und "previous" Buttons, mit denen ich blättern kann.
		button.addEvent('click', function(e) {
			e.stop();
			if (formchecks[i].isFormValid()) {
				if (tabView.currentIndex == anzahlSteps - 1) {
					$('regform').submit();
				} else {
					tabView.nextSlide();
				}
			}
		})
	})
	
	$$('.previous').each(function(button, i) {
		button.addEvent('click', function(e) {
			e.stop();
			 if(tabView.currentIndex != 0) {
				 tabView.previousSlide();
			 }
		})
	})
});

Wie man am Code (zumindest geht es mir so) sehen kann, "kann es garnicht sein" (tut es aber, also doch ^^) dass der Wechsel von einem Tab zum anderen das Validieren des nächsten Tabs "triggert" (das passiert nur mit der isFormValid-Methode).

Lange rede, kurze Frage:
Weiß jemand warum?

Danke

Link?

Ansonsten:

Code:

[...]
	$$('.next').each(function(button, i) {
		var moep = i;
		button.addEvent('click', function(e) {
			e.stop();
			if (formchecks[moep].isFormValid()) {
[...]

+ ich wuerde auf die standard validierung zurueckgreifen und standard tabs verwenden (hidden field => if invalid => tab prevent default / click)
edit: eh, vergiss was ich sagte, es geht gar nicht um joomla, oder ?!

Hi, danke für die Antworten.

ich wollte eben ein Beispiel für euch konstruieren damit ihr das in Action seht (ich weiss mit dem Code oben ist das ganze recht dürftig, ich dachte nur vielleicht fällt euch was auf) und habe dabei den Fehler gefunden.

Problem war, dass ich noch eine Instanz von FormCheck auf die gesamte Form hatte (war leider extra gelöscht aus dem Codeschnipsel oben um euch nicht zu verwirren, dabei lag der Fehler dort ). Da es sich bei den Buttons um Buttons vom Typ submit handelt, wurde bei jedem Klick immer auch die Validierung von dieser Instanz getriggert, was dann zu dem Problem geführt hat.

Buttons haben jetzt den Typ button und eine spezielle Klasse (von der FormCheck-Klasse) mit der die Buttons doch zum Absenden geeignet sind.

@ Matrikular, ja es handelt sich um Joomla. Ich finde nur das meiste was in Joomla mit Mootools umgesetzt wurde, würde noch besser gehen. Diese Validierungsklasse z.B. ist in vielerlei Hinsicht besser als die in Joomla integrierte, ich habe auch einen besseren Datepicker gefunden, und die Tabs-Lösung finde ich auch besser als Accordions (wobei das eher Geschmacks- bzw Anforderungssache ist). Aber das ist ne andere Geschichte

Guten Rutsch

Edit: falls es jemanden interessiert, hier der Link zum Datepicker:
http://aryweb.nl/projects/mootools-datepicker/Test/

Ich habe für mich (also nicht gerade schön etc, aber vielleicht kann es jemand gebrauchen) eine JFormField-Klasse gebastelt.
Klasse:

PHP-Code:

<?php
defined('JPATH_PLATFORM') or die ;

jimport('joomla.html.html');
jimport('joomla.form.formfield');
jimport('joomla.form.helper');
JHtml::_('behavior.mootools');

class JFormFieldEhCalendar extends JFormField {
    public $type = 'EhCalendar';
    

    protected function getInput() {
        $time = $this->element['time'] == "true" ? "true" : "false";
        $locale = $this->element['locale'];
        
        $class = $this->element['class'];
        $doc = JFactory::getDocument();
        // Add Js
        $doc->addScript(JURI::base(true) . '/components/com_eh/assets/js/datepicker/Locale.'.$locale.'.DatePicker.js');
        $doc->addScript(JURI::base(true)  . '/components/com_eh/assets/js/datepicker/Picker.js');
        $doc->addScript(JURI::base(true)  . '/components/com_eh/assets/js/datepicker/Picker.Attach.js');
        $doc->addScript(JURI::base(true)  . '/components/com_eh/assets/js/datepicker/Picker.Date.js');
        $doc->addScriptDeclaration("
        window.addEvent('domready', function(){
            Locale.use('$locale');
            new Picker.Date($$('input[id=$this->id]'), { 
                timePicker: $time, 
                positionOffset: {x: -10, y: 0}, 
                pickerClass: 'datepicker_dashboard', 
                useFadeInOut: !Browser.ie 
            });    
        });    
        ");
        
        // add css
        $doc->addStyleSheet(JURI::base(true)  . '/components/com_eh/assets/css/datepicker/datepicker_dashboard/datepicker_dashboard.css');
        
        $input ='<input type="text" value="'.$this->value.'" autocomplete="off" name="'.$this->name . '" id="'.$this->id.'" class="'.$class.'" />';

        return $input;
    }

}

Benutzt wird sie dann so (in der JForm-xml):

HTML-Code:

<field name="datum" type="ehcalendar"
				label="LABEL" description="DESC" required="true"
				format="%d.%m.%Y" locale="de-DE" time="false" class="validate['required']" />

Die css-Klasse ist nicht nötig, ist für die FormCheck-Klasse. Wenn time="true" gesetzt wird, dann gibts noch nen Picker für die Uhrzeit.

Ich hatte geplant das ganze noch um das Attribut "format" (wie man in der XML sieht) zu erweitern, aber bin nicht mehr dazu gekommen.

Zitat von EuerAbi

Ich finde nur das meiste was in Joomla mit Mootools umgesetzt wurde, würde noch besser gehen. Diese Validierungsklasse z.B. ist in vielerlei Hinsicht besser als die in Joomla integrierte, ich habe auch einen besseren Datepicker gefunden, und die Tabs-Lösung finde ich auch besser als Accordions (wobei das eher Geschmacks- bzw Anforderungssache ist).

Ich würde ja mal eher behaupten, du hast nur die Standard-Joomla!ausgabe der Scripte angeschaut. Ich sehe jetzt bei deinem Datepicker und bei deiner Validierung nichts, was man nicht auch mit dem Joomla!zeugs machen könnte. Der Slider ist auch recht einfach mit Coremittel machbar, aber das ist wohl meistens das Problem beim Programmieren...niemand schaut in die Doku und in den Code, sondern läd sich lieber zusätzlich X externe Scripte rein.

CSS/JS/Image-Dateien sollten nebenbei bemerkt ab 1.6 in den "media" Ordner rein, damit man diese per Override veränderbar machen kann...

Zitat von bembelimen

Ich würde ja mal eher behaupten, du hast nur die Standard-Joomla!ausgabe der Scripte angeschaut. Ich sehe jetzt bei deinem Datepicker und bei deiner Validierung nichts, was man nicht auch mit dem Joomla!zeugs machen könnte. Der Slider ist auch recht einfach mit Coremittel machbar, aber das ist wohl meistens das Problem beim Programmieren...niemand schaut in die Doku und in den Code, sondern läd sich lieber zusätzlich X externe Scripte rein.

CSS/JS/Image-Dateien sollten nebenbei bemerkt ab 1.6 in den "media" Ordner rein, damit man diese per Override veränderbar machen kann...

Ich konnte keinen Hinweis im Code finden, dass der J! Datepicker auch zum auswählen der Zeit geeignet ist. Außerdem ist er bei mir regelmässig zerschossen (layoutmässig) weil die Klassen/CSS so unglücklich gewählt sind, dass sie oft mit anderen Code in Konflikt kommen.

Die Joomla Validierungsklasse kann soviel ich weiß keine Tips anzeigen und ist mit Sicherheit generell nicht so flexibel wie die andere, z.B. kann man (soviel ich weiß) kein per JS hinzugefügtes Element mit in die Validierung aufnehmen (nachträglich).

Ja, man kann mit Joomla Bordmitteln alles machen, schließlich ist Mootools mit dabei und die ganzen Klassen basieren darauf. Es ist aber eine Frage der Zeit ob ich das alles anpassen möchte wenn ich es durch etwas besseres/passenderes ersetzen kann. Vor allem die Validierungsklassen kann man meiner Meinung nach überhaupt nicht miteinander vergleichen.

Bembelimen hat bereits ein wenig ausgeführt worauf ich mit meinem Kommentar hinaus wollte. Aber du hast nicht unrecht, zeitgemäß sind die UI-Elemente in Joomla! nicht unbedingt. Ich denke jedoch, das müssen sie auch nicht zwingend sein, so lange sie funktionell sind. Dazu später mehr,...

Der Hintergrund: Die Einbindung von zusätzlichen externen Scripten bedeutet fast immer einen Mehraufwand verglichen mit der Nutzung oder besser, einer Anpassung von Core-Mitteln. Es ist sehr wahrscheinlich, dass zukünftige Joomla! Versionen eine ebenso aktualisierte Version der Mootools Bibliothek verwenden werden (Wer weiß, vielleicht ja irgendwann auch mal JQuery/UI). Das bedeutet, dass alle externen Scripte gepflegt oder über die Zeit vielleicht sogar angepasst werden müssen um weiterhin zu funktionieren.

Nehmen wir als Beispiel deine Validierungs-Klasse (die ich selbst auch gut finde und vor einiger Zeit für andere Projekte auch benutzt habe)
Joomla! 1.7.3 benutzt Mootools 1.3.2 wenn ich mich nicht irre, ab Version 2.5 wird es Mootools 1.4 werden. Du bist also darauf angewiesen, dass das jeweilige Script entweder weiterentwickelt wird, die Funktionalität über einen Kompatibilitätsmodus gewährleistet ist, oder "du" in der Lage bist das Script selbst hinreichend anzupassen (ausgehend von einer stets aktuellen Erweiterung). Jetzt ist die Form-Validate Klasse aber für Mootools 1.2 und wenn ich es recht in Erinnerung habe, gänzlich an Form.Validate vorbei geschrieben (letzteres hat eine aktivere Unterstützung durch die Community => Weiterentwicklung). Gut, das ist die Validate Funktion von Joomla! auch, aber es gibt keinerlei Abhängigkeiten und über die Möglichkeit wirklich sehr einfach Custom-Validate Regeln hinzuzufügen, gibt es was die Darstellung von Fehlermeldungen betrifft soweit ich das beurteilen kann, kaum Grenzen (zu der Validierung von dynamisch erzeugten Feldern kann ich zu diesem Zeitpunkt wenig sagen).

Der Datepicker und die oben erwähnte Funktionalität
Das Script ist modular, style"bar" und mehrsprachig, also durchaus gut. Aber auch hier das Thema der Abhängigkeit einer weiteren Klasse + Ressourcen und Mootools 1.3 als Basis. Joomla! stellt diesen Datepicker bereit welcher in dieser Version auch die Zeit darstellen kann. Dafür müsste man lediglich das Script selbst initiieren oder einen JHtml-"Override" schreiben und so die vermissten Funktionen anzusprechen (ich habe das selbst für ein Projekt bereits getan => funktioniert).

Was die Tabs/Slider betrifft, so lässt sich damit eigentlich jeder Schabernack anstellen. Aber, das weißt du alles und ich denke es geht im Allgemeinen eher um den Aufwand. Ich würde hier schon im Vorfeld stark abwägen. Erstelle ich die Erweiterung für "mich" - für einen Kunden, für die Community usw. Sobald man von der Standardausgabe abweicht und etwas eigenes oder ... schöneres implementieren möchte, entsteht meiner Erfahrung nach nicht selten ein schwer zu kalkulierender Mehraufwand.

Im Hinblick auf ein Kundenprojekt: Wer weiß schon was der Kunde sich irgendwann für ein Template ins Haus holt. Passen dann die Validate-Tooltips noch? "Sie haben mir das gebaut, warum geht das nicht mehr?" ... ist nur eins der denkbaren Szenarien.
Wir, die wir täglich Stunden am PC verbringen wissen es gibt Software, in der man sich auch dann zurecht findet, selbst wenn man zuvor nie mit dieser gearbeitet hat. Sobald ein Programm oder Eingabemaske jedoch von der vertrauten Struktur abweicht (ein vielleicht treffendes Beispiel ist das Grafikbearbeitungsprogramm „Gimp”) kommen wir ins straucheln. So ist das auch bei Webseiten.
Bei einem CMS wie Joomla!, in dem über die Zeit eine ganze Reihe unterschiedlicher Erweiterungen installiert werden können, sollte man darauf achten das Design sowie die Bedienung für den Besucher so einheitlich und konstant wie möglich zu gestalten. Sei es in der Administration, aber auch bei unterschiedlichen Formularen im Frontend, wo der Einsatz abweichender Scripte wie das der Form-Validierung oder des Datepickers den Benutzer, wenn auch nur unbewusst, verwirren könnte.

Bedienelemente sollten sich innerhalb einer Anwendung nicht unterscheiden oder ändern. Nicht in der Funktionsweise oder deren Ausgabe. Die sich zu stellende Frage also: Nehme ich für ein einheitliches Erscheinungsbild und die Pflege von externen Scripten den Aufwand in Kauf und kann ich zusätzlich anfallende Arbeiten dem Kunden gegenüber rechtfertigen? Habe ich dieses Problem oder ... diesen Anspruch überhaupt? POLA/PLA/POLS

Nun, du hast bereits einige Gründe genannt warum du den Weg gegangen bist und ich möchte dich auch nicht eines besseren belehren.
Vielleicht kann die Ausführung dem ein oder anderen eine kleine Entscheidungshilfe sein,...

Gruß
Sven

Hallo Sven,

ich kann dir eigentlich nur zustimmen. Ich bin grundsätzlich immer darauf aus Core-Mittel zu benutzen/erweitern, und die von dir angesprochenen Fallgruben habe ich teilweise sogar selbst schon erlebt.

Aktuell habe ich einerseits nach der "schnellsten" Lösung gesucht und andererseits war mir einiges unbekannt, wie z.B. dass der Joomla Datepicker auch fürs auswählen der Zeit nützlich ist (auch wenn mir dafür die Zeit im Vergleich zur anderen Klasse eh gefehlt hätte).

Der Punkt mit der etwas "veraltenen" UI von einigen Core-Elementen fällt besonders im Frontend negativ auf, und das anpassen stelle ich mir aufwändiger vor das einbinden anderer Klassen. Wobei man natürlich hier abwägen muss, wenn die von dir angesprochenen Fallgruben "wahrscheinlich" sind, sollte man natürlich stets zu der "saubereren" Lösung greifen.

Dafür müsste man lediglich das Script selbst initiieren oder einen JHtml-"Override" schreiben und so die vermissten Funktionen anzusprechen (ich habe das selbst für ein Projekt bereits getan => funktioniert).

Schon im Wiki?

Extra für dich aufgehoben das Thema. Eventuell findest du ja auch die Zeit die Core-Scripte auf JQuery umzuschreiben und ein Switch-Plugin bereitzustellen, inkl. Patch fürs Core Team.
Guten Rutsch
Sven

Würde mich jetzt doch interessieren, wie die Vorgehensweise ungefähr wäre Sliding Tabs + Validierung der einzelnen Tabs nur mit J!-Bordmitteln zu erreichen. Man könnte hier etwas fachsimpeln und dann ins Wiki damit.

Edit: was sind die Stichpunkte zum JHtml-Override?

Edit2: gibt es Ansätze um so wie in dem FormCheck-Script bei fehlerhaften Feldern ToolTips neben dem Feld anzuzeigen?

Edit3:

PHP-Code:

protected static function _loadBehavior($group, $params = array())
    {
        static $loaded = array();

        if (!array_key_exists($group, $loaded))
        {
            // Include MooTools framework
            JHtml::_('behavior.framework', true);

            $options = '{';
            $opt['onActive']            = (isset($params['onActive'])) ? $params['onActive'] : null ;
            $opt['onBackground']        = (isset($params['onBackground'])) ? $params['onBackground'] : null ;
            $opt['display']                = (isset($params['startOffset'])) ? (int)$params['startOffset'] : null ;
            $opt['useStorage']            = (isset($params['useCookie']) && $params['useCookie']) ? 'true' : null ;
            $opt['titleSelector']        = "'dt.tabs'";
            $opt['descriptionSelector']    = "'dd.tabs'";
            foreach ($opt as $k => $v)
            {
                if ($v) {
                    $options .= $k.': '.$v.',';
                }
            }
            if (substr($options, -1) == ',') {
                $options = substr($options, 0, -1);
            }
            $options .= '}';

            $js = '    window.addEvent(\'domready\', function(){
                        $$(\'dl#'.$group.'.tabs\').each(function(tabs){
                            new JTabs(tabs, '.$options.');
                        });
                    });';

            $document = JFactory::getDocument();
            $document->addScriptDeclaration($js);
            JHtml::_('script', 'system/tabs.js', false, true);

            $loaded[$group] = true;
        }
    } 


In tabs.php wird beim instanziieren der (mootools)JTabs-Klasse kein Variablenname vergeben, somit kann ich einzelne Tabs nicht direkt ansprechen, um z.B. mit einem Button gezielt zu einem Tab zu springen, oder?
Wenn ich beim starten des Panel das config-array mitgebe um z.B. ein console.log() beim Event "onActive" auszuführen funktioniert zwar der output, aber die Tabs funktionieren nicht mehr, auch kein Fehler in der Console.

PHP-Code:

echo JHtml::_('tabs.start', 'tabs', array(
    'useCookie'=>1,
    'onActive' => "console.log(this.JTabs)"
    )
); 


Ne Idee? Dachte ich könnte vielleicht über dieses Event (oder onBackground()) das mit der Validierung angehen.