###template marker### der hochkomma enthält in js var einlesen

[chhalpha]

Sehr geehrte Community,

Ich weiß nicht ob es überhaupt eine Lösung für mein Problem gibt aber nachfragen kostet ja nichts :)

Ich habe eine Template Datei mit Template Markern wie z.b. ###PRODUCT_IMAGE###

es handelt sichhierbei um tt_products und Typo3.

Wird das Template ganz normal ausgegeben und ich sehe mir den Quelltext an wird ###PRODUCT_IMAGE### durch z.b. <img src="lol.jpg"/> ersetzt.

ich MUSS aber unbedingt den Dateinamen auslesen und ausgeben also hier lol.jpg

wenn ich nun versucht in meinem Template folgenden einzubauen:

<script>
var string = "###PRODUCT_IMAGE###";
alert(string);
</script>

funktioniert das nicht da nach der ersetzung ja im prinzip folgendes dasteht:

<script>
var string = "<img src="lol.jpg"/>";
alert(string);
</script>

so und eigentlich müsste es aber heißen

<script>
var string = "<img src="lol.jpg"/>";
alert(string);
</script>

dann könnte ich damit weiterarbeiten.

Gibt es da irgend ne Lösung dafür wenn der String schon Hochkommas enthält dass die irgendwie mit ner Funtkion oder so automatisch in " umgewandelt werden?

Wäre für jede Hilfe dankbar!!

Grüße

[suit]

Gibt es da irgend ne Lösung dafür wenn der String schon Hochkommas enthält dass die irgendwie mit ner Funtkion oder so automatisch in " umgewandelt werden?

Das ist ein Template, der Ausgabekontext ist HTML, das du das missbrauchen willst, dafür kann die Engine nix - das ist sicher in diesem Fall so in tt_products so programmiert (hab' grade keine Lust mir Anzusehen, was Franz Holzinger da wieder zusammenschustert :) - aber ich gehe davon aus, dass es zumindest halbwegs vernünftig ist).

Dein Problem ließe sich mit etwas Grundlagenwissen einfach lösen - zum Beispiel das wissen um verschiedene Stringbegrenzer in JavaScript. Oder wenn du einfach mit DOM-Methoden an den Attributwert gelangst, anstatt derart unglücklich auf andere weise.

Aber dein eigenliches Problem ist wohl eher ein PHP oder TypoScript-Problem - du willst nur den Filenamen? Bzw: was willst du eigentlich genau erreichen?

Ich gehe davon aus, dass ###PRODUCT_IMAGE### nicht der einzige Marker ist - es gibt vermutlich auch ###PRODUCT_IMAGE_URL### oder ähnliches - ein Blick in die Doku oder den Quelltext wirkt oft wunder.

Das Bild wird ziemlich sicher mit cObjGetSingle oder ähnlichem erzeugt und ist vom Typ IMAGE - du willst aber IMG_RESOURCE (oder etwas ganz anders, welches du nicht genau erklärt hast).

[chhalpha]

Dein Problem ließe sich mit etwas Grundlagenwissen einfach lösen - zum Beispiel das wissen um verschiedene Stringbegrenzer in JavaScript. Oder wenn du einfach mit DOM-Methoden an den Attributwert gelangst, anstatt derart unglücklich auf andere weise.

»»

Ich kenne nur einfachhochkomme und doppelhochkomme und ich hab mal gelesen dass es für verschiedene Sprachen nochmal andere Begrenzer gibt aber was bringt mir das jetzt ? mit einfachhochkomma habe ich es auch schon versucht leider ohne erfolg!

Aber dein eigenliches Problem ist wohl eher ein PHP oder TypoScript-Problem - du willst nur den Filenamen? Bzw: was willst du eigentlich genau erreichen?

»»
Ich will aus dem Template Marker der diese Hochkommas enthält einen Teilstring auslesen! da es sich um ein Listentemplate handelt will ich das für alle produktbilder machen und sie mir in einem array merken und erst wenn alle Produkte durch sind  will ich sie dann mit document.write() ausgeben und zwar ganz am ende des listentemplates.

Hier wenn du noch mehr Infos möchtest:
http://www.typo3forum.net/forum/tt_products/53709-mehrere-listenansichten-seite.html

Ich gehe davon aus, dass ###PRODUCT_IMAGE### nicht der einzige Marker ist - es gibt vermutlich auch ###PRODUCT_IMAGE_URL### oder ähnliches - ein Blick in die Doku oder den Quelltext wirkt oft wunder.

»»
Nein gibt es nicht! Es gibt noch andere die auch Hochkammas enthalten ändert nix am ursprünglichen Problem da es z.B. kein PRODUCT_IMAGE_URL gibt leider! das ist ja das dumme...

Das Bild wird ziemlich sicher mit cObjGetSingle oder ähnlichem erzeugt und ist vom Typ IMAGE - du willst aber IMG_RESOURCE (oder etwas ganz anders, welches du nicht genau erklärt hast).

ich will nicht im php des shops rumpfuschen, verstehe eh nicht was das mit meiner Frage zu tun hat.

Danke für deine Antwort!

[suit]

http://www.typo3forum.net/forum/tt_products/53709-mehrere-listenansichten-seite.html

Crosspostings sind großer Mist.

ich will nicht im php des shops rumpfuschen, verstehe eh nicht was das mit meiner Frage zu tun hat.

Deine Frage ist völlig am eigentlichen Problem vorbeigestellt - hättest du gleich dein Problem nachvollziehbar beschrieben (so wie du es bei typo3forum.net gemacht hast), wäre das Problem schon lange gelöst.

Deine "klapp mir eine detailansicht aus" ist ein reines JavaScript-Problem, dafür musst du nichts (gar nichts) zusätzlich ins HTML-Template von tt_products packen so wie du es jetzt gemacht hast.

Es reicht, dass du auf jedes der kleinen Bildern die hover-Methode (jQuery verwendest du ja) anwendest und dort dein Ding durchziehst.

• jeweilige Detailseite per Ajax abholen
• Inhalte parsen
• Code zusammenbauen und ins DOM einhängen
• (Schritt 1 bis 3 entfallen, wenn da schon mal gemacht wurde)
• anzeigen
• ???
• PROFIT!

[dedlfix]

Hi!

wenn ich nun versucht in meinem Template folgenden einzubauen:
var string = "###PRODUCT_IMAGE###";
funktioniert das nicht da nach der ersetzung ja im prinzip folgendes dasteht:
var string = "<img src="lol.jpg"/>";
so und eigentlich müsste es aber heißen
var string = "<img src="lol.jpg"/>";
dann könnte ich damit weiterarbeiten.

Kontextwechsel beachten. Immer. Das Problem hast du nicht nur bei den Dateinamen sondern auch für andere Dinge. Beispielsweise beendet </ theoretisch einen Script-Bereich. Dass es in einem Javascript-String notiert ist, erkennt der HTML-Parser nicht. Manche Browser sind jedoch fehlertolerant. Wenn du HTML-Code in Javascript-Code in HTML-Code einbettest, musst du die Verschachtlungsregeln berücksichtigen.

Gibt es da irgend ne Lösung dafür wenn der String schon Hochkommas enthält dass die irgendwie mit ner Funtkion oder so automatisch in " umgewandelt werden?

Nein, da du hier nur Teile beachten willst. Ansonsten gibt es in Javascript nur encode() und encodeURIComponent(), was aber für den URL-Kontext gedacht ist.

Lo!

[molily]

Hallo,

Beispielsweise beendet </ theoretisch einen Script-Bereich.

Ja, das ist die HTML-4-Theorie und steht m.W. sogar gegen SGML-Theorie. Praktisch hat das nie ein Browser umgesetzt.

Dass es in einem Javascript-String notiert ist, erkennt der HTML-Parser nicht. Manche Browser sind jedoch fehlertolerant. Wenn du HTML-Code in Javascript-Code in HTML-Code einbettest, musst du die Verschachtlungsregeln berücksichtigen.

HTML5 kodifiziert das Verhalten, das die Browser schon lange (schon immer?) gezeigt haben, nämlich dass ein </script> ein <script> beendet und alles dazwischen Textinhalt des script-Elements ist.

http://www.w3.org/TR/html5/tokenization.html#script-data-end-tag-name-state
http://www.w3.org/TR/html5/tree-construction.html#scriptTag
http://www.w3.org/TR/html5/tree-construction.html#scriptEndTag

Mathias

[dedlfix]

Hi!

HTML5 kodifiziert das Verhalten, das die Browser schon lange (schon immer?) gezeigt haben, nämlich dass ein </script> ein <script> beendet und alles dazwischen Textinhalt des script-Elements ist.

Das heißt aber immer noch, dass ein </script> innerhalb einen Javascript-Strings den Script-Bereich beendet. Oder ist etwa auch festgelegt, dass der HTML-Parser den Javascript-Code zu parsen hat?

Lo!

[molily]

Das heißt aber immer noch, dass ein </script> innerhalb einen Javascript-Strings den Script-Bereich beendet.

Richtig.

Mathias

[suit]

Das heißt aber immer noch, dass ein </script> innerhalb einen Javascript-Strings den Script-Bereich beendet.

Richtig.

Aber das lässt sich ja einfach umschiffen indem man halt '</sc' + 'cript'> anstatt '</script>' notiert.

[Der Martin]

Hi,

Das heißt aber immer noch, dass ein </script> innerhalb einen Javascript-Strings den Script-Bereich beendet.
Richtig.
Aber das lässt sich ja einfach umschiffen indem man halt '</sc' + 'cript'> anstatt '</script>' notiert.

das ergibt dann "</sccript>". Nicht schön. ;-)
Abgesehen davon finde ich das Maskieren als "</script> immer noch übersichtlicher als das Auftrennen.

Ciao,
 Martin

[dedlfix]

Hi!

Das heißt aber immer noch, dass ein </script> innerhalb einen Javascript-Strings den Script-Bereich beendet.
Richtig.
Aber das lässt sich ja einfach umschiffen indem man halt '</sc' + 'cript'> anstatt '</script>' notiert.

Ja, wobei die HTML4-Theorie-kompatible Lösung, die auch einfacher zu notieren geht, '</script>' lautet.

Lo!

[molily]

Hallo,

Aber das lässt sich ja einfach umschiffen indem man halt '</sc' + 'cript'> anstatt '</script>' notiert.

Das Problem lässt sich noch einfacher umschiffen, indem man Scripte per JavaScript lädt, am besten asynchron, und nicht versucht, sie mit document.write ins Dokument zu schreiben – das ist nämlich der häufigste Fall, in dem man überhaupt in die Versuchung kommt, HTML in JavaScript in HTML zu verschachteln. ;)

Mathias

[Kai345]

[latex]Mae  govannen![/latex]

Beispielsweise beendet </ theoretisch einen Script-Bereich.

Ja, das ist die HTML-4-Theorie und steht m.W. sogar gegen SGML-Theorie. Praktisch hat das nie ein Browser umgesetzt.

Du kennst das Verhalten _aller_ Browser?

Stur lächeln und winken, Männer!
Kai

[molily]

Ja, das ist die HTML-4-Theorie und steht m.W. sogar gegen SGML-Theorie. Praktisch hat das nie ein Browser umgesetzt.

Du kennst das Verhalten _aller_ Browser?

Gegenfrage, ist das mehr als ein rein formaler Einwand?

Antwort, nein, aber das Verhalten der verbreiteten Browser der letzten 10 Jahre. Mir ist kein Browser bekannt, der streng gemäß SGML und diesen Zusatzregeln arbeitet. Lynx hatte mal einen optionalen SGML-Parser eingebaut. Der hat in der Praxis natürlich keine Website anzeigen können.

Wenn man abwärtskompatibel mit der HTML-4-Theorie sein will, kann man </ in eingebetteten JavaScript-Strings weiter mit </ umschreiben. Ich wüsste aber nicht, dass das Browser betrifft, zu denen man heutzutage in anderen Bereichen noch kompatibel ist.

Mathias

[suit]

Antwort, nein, aber das Verhalten der verbreiteten Browser der letzten 10 Jahre. Mir ist kein Browser bekannt, der streng gemäß SGML und diesen Zusatzregeln arbeitet. Lynx hatte mal einen optionalen SGML-Parser eingebaut. Der hat in der Praxis natürlich keine Website anzeigen können.

Das ist auch einer der Gründe warum XML überhaupt geschaffen wurde - eben weil SMGL so unhandlich und schwierig zu parsen ist und den Sonderschmafu den das Monster kann eigentlich eh niemand braucht.

[Kai345]

[latex]Mae  govannen![/latex]

Antwort, nein, aber das Verhalten der verbreiteten Browser der letzten 10 Jahre. Mir ist kein Browser bekannt, der streng gemäß SGML und diesen Zusatzregeln arbeitet.

Ob die verbereiteten Browser das nie gemacht haben, sollte für eine vernünftige Programmierung völlig unerheblich sein. Es _könnte_ unter den zig dutzend nicht großflächig verbreiteten Browsern durchaus welche geben, die genau diesen Fehler machen, und die stehen dann auf dem Schlauch. Klar kann man sich auf den Standpunkt stellen, daß diese Browser nicht interessant sind. Aber weshalb sollte man nicht durch ein simples </ statt </ den Fehler direkt von vornherein ausschließen, statt es darauf ankommen zu lassen? Das ist für mich einfach ein Grundsatz sauberen Programmierens.

Stur lächeln und winken, Männer!
Kai

[molily]

Hallo,

Es _könnte_ unter den zig dutzend nicht großflächig verbreiteten Browsern durchaus welche geben, die genau diesen Fehler machen

Ich habe nichts dagegen, zur Sicherheit </ zu notieren. Schließlich gab es einmal einen einflussreichen Standard, der das so vorgeschrieben hat, auch wenn dieser Teil aus bekannten Gründen geflissentlich ignoriert wurde und mir kein relevanter aktueller UA bekannt ist, der das erfordert.

Im Allgemeinen halte ich es aber für nicht hilfreich, so zu argumentieren. Man kann bei browserübergreifender Programmierung nicht auf rein hypothetische Fälle reagieren. Würde man das konsequent tun, müsste man sämtliche theoretisch möglichen Fehlerfälle abdecken. Das würde zu absurdem Code führen.

Wenn man Sites so bauen will, dass ein konformer HTML-4- bzw. SGML-Parser sie verarbeiten kann, so wäre der Code tatsächlich absurd und inkompatibel mit realen Browsern. Der W3C-Validator war so ein SGML-Parser. Man hat sich auf den Kopf gestellt, um dessen Ansprüchen an die Syntax zu genügen, oftmals zu Ungunsten der Kompatibilität mit tatsächlichen UAs. Diese Regeln von HTML 4 und die Basierung auf SGML war nun einmal ein historischer Fehlschlag.

Mathias