JScripte im Edit nicht vor </head> sonder nach <head>

Ideen für neue Funktionen in CONTENIDO?
Antworten

Ankerpunkt von "</head>" auf "<head>" ändern

Umfrage endete am Mi 19. Jan 2011, 12:31

Ja, das ist eine gute Idee.
3
43%
Nein, das halte ich für keine gute Idee.
2
29%
Mir egal !
2
29%
 
Abstimmungen insgesamt: 7

OliverL
Beiträge: 870
Registriert: Do 28. Jun 2007, 09:28
Kontaktdaten:

JScripte im Edit nicht vor </head> sonder nach <head>

Beitrag von OliverL » Mo 20. Dez 2010, 12:31

Hallo Leute,

Bei dem einsetzen von JQuery im Edit-Bereich gibt es konflickte da JQuery von Contenido eingebunden wird.
So gibt es fehler im FireFox.

Da Contenido seine Scripts vor den "</head>" setzt ist es nicht mehr möglich nach dem laden von JQuery eine eigenen Funktionen aufzurufen.

Ich würde gerne den Ankerpunkt von "</head>" auf "<head>" ändern.
So kann man seine eigenen Scripte auch noch laden.

Was haltet ihr davon?

mfg
Oliver Lohkemper

Info:
Datei: includes/include.con_editcontent.php
Zeile: 622

kummer
Beiträge: 2423
Registriert: Do 6. Mai 2004, 09:17
Wohnort: Bern, Schweiz
Kontaktdaten:

Re: JScripte im Edit nicht vor </head> sonder nach <head>

Beitrag von kummer » Mo 20. Dez 2010, 15:05

das hier angsprochene problem ist grundsätzlicher natur. eigentlich sollte es gar keine interferenz zwischen den scripten der site und derjenigen des editbereiches geben. erreichen lässt sich das durch die verwendung eines iframes, in welchem die zu editierende seite angezeigt wird.
aitsu.org :: schnell - flexibel - komfortabel :: Version 2.2.0 (since June 22, 2011) (jetzt mit dual license GPL/kommerziell)

Oldperl
Beiträge: 4254
Registriert: Do 30. Jun 2005, 22:56
Wohnort: Eltmann, Unterfranken, Bayern
Kontaktdaten:

Re: JScripte im Edit nicht vor </head> sonder nach <head>

Beitrag von Oldperl » Mo 20. Dez 2010, 15:59

Auser dem von kummer genannten Lösungsansatz mit iFrame, von dem ich persönlich nicht so begeistert bin, da jede JS-Funktionalität im Seitenbereich dann nur umständlich zu implementieren ist, denke ich da an 2 mögliche Ansätze.
  1. Contenido selbst gibt mögliche JS-Frameworks vor. So könnte es im Layoutbereich eine Auswahl für einsetzbare JS-FW wie jQuery, MooTools oder Anderen geben, und man könnte Layout-abhängig Frameworks auswählen. Contenido übernimmt dabei die Prüfung auf Kompabilität der FW untereinander und läßt nur entsprechende Auswahlen zu, bzw. gibt Hinweise wenn es zu Problemen kommen könnte.
  2. Contenido nutz für seine "internen" JS-Geschichten eigene Namespaces für die eingesetzten JS-FW und -Scripte. Eine Überschneidung mit originalen JS-FW würde sich dadurch vermeiden lassen, einem regelmäßigen Update der Frameworks im Backeend stände auch nichts im Wege, nur eine Änderung des Namespace wäre am Originalscript notwendig.
Mein Favorit wäre dabei die 2. Möglichkeit, bei dem sich auch Anpassungen und Änderungen am aktuellen Core im überschaubaren Rahmen halten würden.

Gruß aus Franken

Ortwin
ConLite 2.1, alternatives und stabiles Update von Contenido 4.8.x unter PHP 7.x - Download und Repo auf Gitport.de
phpBO Search Advanced - das Suchwort-Plugin für CONTENIDO 4.9
Mein Entwickler-Blog

kummer
Beiträge: 2423
Registriert: Do 6. Mai 2004, 09:17
Wohnort: Bern, Schweiz
Kontaktdaten:

Re: JScripte im Edit nicht vor </head> sonder nach <head>

Beitrag von kummer » Mo 20. Dez 2010, 19:43

wobei du auch bei der zweiten variante eine injektion in die mandanten-seite machen musst. das wäre bei verwendung eines iframes nicht notwendig. iframe - das bin ich mir durchaus bewusst - sind auf dem index der bösen tags. aber inzwischen weiss kaum jemand mehr, wieso das so ist. neben dem umstand, das kaum ein framework letztlich für gewisse dinge ohne iframe auskommen kann. ich denke da z.b. an einen upload über ajax, der in praktisch allen verfügbaren frameworks über iframes gelöst wird. aber die zweite variante scheint mir durchaus auch in ordnung, wenn es mit der umsetzung dann wirklich klappt. da scheint mir allerdings ein proof of concept empfehlenswert.
aitsu.org :: schnell - flexibel - komfortabel :: Version 2.2.0 (since June 22, 2011) (jetzt mit dual license GPL/kommerziell)

Antworten