Contenido und Mootools oder JQuery

luzi · Beitrag von **luzi** » Mo 12. Apr 2010, 16:32

Hallo Miteinander

Ich bin vor kurzem auf ein Problem gestossen welches ich nicht für mich behalten möchte.
In meinen Projekten verwende ich immer Mootools für die Javascript implementation. Da ich nicht immer mit Contenido arbeite stellte dies bis anhin auch keine Probleme dar, bis eben vor kurzem.
Das Problem:
Wenn man nun einen Artikel im Editor öffnet enstehen diverse Fehler wegen den 2 verschiedenen Frameworks, Mootools und JQuery sind nicht miteinander kompatibel.
Da dachte ich nun gut, wechseln wir auf JQuery. Aber da enstanden ähnliche Fehler weil die JQuery-Bibliothek 2x geladen wurde und als letzte Lösung habe ich eine Abfrage eingefügt, welche im Layout das JQuery-Lib nicht einbindet.

Muss es wiklich sein dass die Entwickler von Contenido unbedingt auf JQuery zurückgreifen?
Meiner Meinung nach sollte JQuery auf der Editor-Seite nicht eingesetzt werden da es sowieso nur verwendet wird um den RTE einzubinden und dies auch anders möglich wäre.
Für mich stellt dies leider einen weiteren Grund mehr dar um Contenido in Zukunft nicht mehr zu verwenden.

Beitrag von **Dodger77** » Mo 12. Apr 2010, 17:12

Das Problem solltest du auch nicht für dich behalten. Denn so ist es ja evtl. lösbar. Es wäre z.B. recht unproblematisch möglich, die Einbindung des Frontend-Javascripts einfach im Layout so zu gestalten, dass dies mit dem Backend-Javascript gar nicht kollidieren kann. Beispiel:

Code: Alles auswählen

<?php if (!$edit): ?>
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript" src="project-xyz.js"></script>
<?php endif; ?>

luzi · Beitrag von **luzi** » Mo 12. Apr 2010, 17:44

So habe ich es auch gelösst ...

... zumindest ähnlich.
Ich habe ein Modul entwickelt welches Teile des Head-Bereichs ausgeben und nicht blos den Title-Tag so wie imContenido Beispiel. Leider entstanden dadurch Probleme mit der Anordnung der Tags im Head-Bereich. Die Tags die von Contenido im Head-Bereich eingefügt werden erscheinen nun zu unterst, nach denen die von mir eingefügt wurden.

Beispiel der Ausgabe:

Code: Alles auswählen

<head>
<base href="http://meine.domain.ch/client/" />

<title>Galerie -=- Galerie -=- Demo Midi</title>
<link rel="shortcut icon" type="image/x-icon" href="ico/favicon.ico" />
<link rel="stylesheet" href="css/styles.css" type="text/css" media="all" />
<link rel="stylesheet" href="widgets/form/css/Helper.css" type="text/css" media="all" />
<script src="js/mootools/core-comp-yui.js" type="text/javascript"></script>
<script src="js/mootools/more-comp-yui.js" type="text/javascript"></script>
<script src="widgets/form/js/Helper.js" type="text/javascript"></script>

<meta http-equiv="content-type" content="application/xhtml+xml; charset=iso-8859-1" />
<meta name="date" content="2010-02-21 22:19:59" />
<meta name="description" content="Galerie" />

</head>

Beitrag von **OliverL** » Di 18. Mai 2010, 09:20

Moin,

hatte mal das gleiche Problem mit LightBox und habe es wie Dodger77 gemacht.

Info: Die Tags die von Contenido ergänzt werden richten sich am Delimiter-Tag "</head>" aus.

mfg Oli

Beitrag von **Oldperl** » Di 18. Mai 2010, 09:45

Hallo,

hier gehört IMO beim Parsen eine Klasse her, der in den Modulen das jeweilige Script und der Pfad übergeben wird, und welche dann den Einbau im Head vornimmt. Dort könnte man dann auch eine Prüfung von Scriptversionen durchführen und Kollisionen versuchen zu lösen bzw. zu vermeiden.

Gruß aus Franken

Ortwin

Beitrag von **xmurrix** » Sa 22. Mai 2010, 15:18

Hallo zusammen,

solche Kollisionen wird es immer wieder geben, da man sich nie sicher sein kann, wer wann welche Libraries einsetzt.

Lösen könnte man das, indem sämtlicher in Contenido verwendetet JavaScript Code in seinem eigenen Namespace läuft. JS erlaubt es zwar, vorherige Definitionen zu überschreiben, eine erhebliche Hilfe wäre es auf jeden Fall.

Dabei stelle ich mich das folgendermaßen vor:

Code: Alles auswählen

// Create Contenido namespace
if (typeof(Contenido) === "undefined" || typeof(Contenido) !== "object") {
    var Contenido = {};
}

// Add jQuery to Contenido namespace
if (typeof(jQuery) !== "undefined" && typeof(jQuery) === "object") {
    Contenido.$ = jQuery;
    jQuery.noConflict(true);
}

...

// Use jQuery by Contenido namespace
Contenido.$("#foobar").click(function(){
    alert('Hello world!');
});

Danach kann man alles Weitere innerhalb des Contenido namespaces weiter entwickeln und auf das jQuery in dem Contenido Core-Dateien mit Contenido.$() zugreifen. Jeder kann dann seine eigenen Libraries und Funktionen implementieren, solange das nicht innerhalb des Contenido namespaces geschieht, kommt man sich nicht in die Quere.

Die Verwendung von JavaScript und von extern eingebundenen JS-Widgets nimmt immer mehr zu, daher sollte man meiner Meinung nach diesen Weg gehen, um zukünftige Probleme zu minimieren.

Grüße
xmurrix

Beitrag von **Oldperl** » So 23. Mai 2010, 10:57

1. Das ist sicherlich eine gute Idee, dazu muss es aber eine festgelegte Struktur für diese Namespaces geben. Hier gibt es weder einen vernünftigen konzeptionellen Ansatz, noch festgelegte Vorgaben, an die sich in der Entwicklung gehalten wird. Ohne solche Strukturen und Vorgaben kocht dann doch wieder Jeder sein eigenes Süppchen.
Ich habe (leider) den Eindruck, daß in diese zeitintensiven Arbeiten niemand investieren will, genauso wie es im Bereich der Dokumentation ist.

2. Ich sehe im Ansatz der Namespaces aber auch keine Lösung für die Einbindung verschiedener jQuery Versionen, den eigentlich werden gerade dadurch oft Kollisionen ausgelöst, dass Scripte nun gerade nicht mit der aktiven Instanz von jQuery laufen, weil sie Funktionen einer anderen Version nutzen. Hier nutzt das Prinzip der Namespaces im 1. Moment nichts. Entweder man macht klare Vorgaben der eingesetzten jQueryversion, oder es Bedarf einer Zuordnung je nach Version, was ich jedoch für nicht durchführbar halte, da dann nicht nur verschiedene Versionen von jQuery vorgehalten werden (müssen), sondern diese dann auch beim Client instanziert werden, was irgendwann zu einem Overhead im Browser des Client führt.

Gruß aus Franken

Ortwin

Beitrag von **xmurrix** » So 23. Mai 2010, 11:23

Oldperl hat geschrieben:...2. Ich sehe im Ansatz der Namespaces aber auch keine Lösung für die Einbindung verschiedener jQuery Versionen, den eigentlich werden gerade dadurch oft Kollisionen ausgelöst, dass Scripte nun gerade nicht mit der aktiven Instanz von jQuery laufen, weil sie Funktionen einer anderen Version nutzen...

Da hast du recht, die Verwendung von Namespaces ist kein Allheilmittel. Wenigsten können wir so Probleme vermeiden, wenn Artikelseiten im Backend bearbeitet werden. Zusätzliche Features, Scripte, die rein im Backend angesiedelt sind, würden dann als Vorgabe sich an die im Backend vorhandene jQuery Version halten müssen. Im Frontend ist dann der User komplett unabhängig von der Backend jQuery Version und sollte auch seine eigenen Scripte für das Frontend einsetzen. Der dabei entstehende Overhead im Editiermodus ist meiner Meinung nach das kleinere Übel.

Es muss wohl oder übel eine durchdate Lösung hierfür gefunden werden und die Umsetzung könnte man schrittweise integrieren - Es sind mittlerweile viele JS-Snippets, die im Backend hier und da verwendet werden, d. h. die Umstellung braucht Zeit.

Gruß
xmurrix

luzi · Beitrag von **luzi** » Sa 26. Feb 2011, 23:55

ich setzte unterdessen jQuery und Mootools erfolgreich ein.

Bei jQuery gibt's zum Glück den Kompatibilitäts-Modus wessen man nach dem einbinden von jQuery ausführt.

Code: Alles auswählen

jQuery.noConflict();

Damit der im Backend verwendete Inline-Editor verwendet werden kann muss jedoch die Datei "include.con_editcontent.php" ein wenig angepasst werden.
Im Script ab Zeile 170 bis 179 muss die verwendete Selektor-Funktion $() durch jQuery() ersetzt werden.

Code: Alles auswählen

//add tiny to elements which contains classname contentEditable
//tiny toggles on click
jQuery(document).ready( function(){
   jQuery('div[contenteditable=true]').each( function(){
	  jQuery(this).attr('contentEditable', 'false'); //remove coneditable tags in order to disable special firefox behaviour
      jQuery(this).bind( "click", function(){
         {USE_TINY}
      });
   });
});

Ich bin der Meinung dies sollte bereits von Haus aus so geschrieben werden, so wird Contenido noch flexibler und Entwickler-freundlicher.

Grüsse Luzi

kummer · Beitrag von **kummer** » Mo 28. Feb 2011, 14:45

xmurrix hat geschrieben:solche Kollisionen wird es immer wieder geben, da man sich nie sicher sein kann, wer wann welche Libraries einsetzt.

nein, es müsste die nicht geben. eine variante wäre der verzicht auf js im backend, resp. beim editiermodus. ein entscheid, den man vermutlich nicht wird treffen wollen. aber der würde das problem ganz lösen.

die zweite variante ist, auf die injektion in das client-template zu verzichten und die funktionalität ausserhalb desjenigen frames zu lagern, in welchem die die darstellung der seite erfolgt. innerhalb des frames wäre dann javascript, welches für die seite benötigt wird. ausserhalb der code von contenido, der für die editierung benötigt wird. das geht wunderbar und läuft konfliktfrei.

CONTENIDO Forum

Contenido und Mootools oder JQuery

Contenido und Mootools oder JQuery

Re: Contenido und Mootools oder JQuery

Re: Contenido und Mootools oder JQuery

Re: Contenido und Mootools oder JQuery

Re: Contenido und Mootools oder JQuery

Re: Contenido und Mootools oder JQuery

Re: Contenido und Mootools oder JQuery

Re: Contenido und Mootools oder JQuery

Re: Contenido und Mootools oder JQuery

Re: Contenido und Mootools oder JQuery