nicht angemeldet MB
Felix Riesterer
MB
Rolf B
dedlfix
Matthias Apsel
MB
moin,
Einleitung
für user lesbaren Text gibt es Kombinationen die ein Parser nicht als Magic String erkennt und diese Kombination so ohne Veränderung ausgibt.
Beispiel:
HTML Text mit der Kombination {#user#} funktioniert da der HTML-Parser von der Kombination es nichjt als Code sieht. Die Kombination <user> kann der HTML-Parser interpretieren und gibt diese Kombination verändert aus. Also kann man die Kombination die die Delimiter < und > umnschließen im HTML Kontext nicht verwenden.
Frage
Es geht mir um Zeichen-Kombinationen im jeweiligen Kontext einer MarkUp-Sprache die nicht von jeweligen Parser interpretiert werden.
Welche Wissensquellen gibt es überhaupt (z.B. Bücher, Homepages, YouTube-Tutorials), die diese Zeichen-Kombinationen im jeweiligen Sprache Kontext aufzeigen und die als MagicString fungieren können?
Erläuterung
{{{{$DELIMITER_START$:::: und ::::$DELIMITER_END$}}}} als Delimiter für Tokens im HTML-Kontext wäre sicherlich ok aber es wäre auch sehr umständlich wie "mit Kanonen auf Spatzen geschlossen". Es sind Klüger in diesem Kontext nicht < und >zu verwenden und kleine Brote zu Backen wie {#und #}.
lgmb
Rolf B
Lieber MB,
{{{{$DELIMITER_START$::::und::::$DELIMITER_END$}}}}als Delimiter für Tokens im HTML-Kontext wäre sicherlich ok aber es wäre auch sehr umständlich wie "mit Kanonen auf Spatzen geschlossen". Es sind Klüger in diesem Kontext nicht<und>zu verwenden und kleine Brote zu Backen wie{#und#}.
das liest sich für mich wie ... (nicht nette Ausdrucksweise). Was genau willst Du sagen? Willst Du sagen, dass die erste Form der Maskierung für Dich "unschön" ist? Da darf man getrost fragen "na und?" - denn eine Hauptsache ist, dass es funktioniert, und eine andere ist, dass es wartbarer Code ist. Im Übrigen verwende ich {#platzhalter} in meinen Templates. Nur mal so. Weil Du von "kleinen Broten backen" sprichst, so als wäre das etwas Ungenügendes.
Liebe Grüße
Felix Riesterer
moin,
[...]. Es sind Klüger in diesem Kontext nicht
<und>zu verwenden und kleine Brote zu Backen wie{#und#}.
das liest sich für mich wie ...(nicht nette Ausdrucksweise)
sry verstehe ich leider auch nicht 😕.
Was genau willst Du sagen? Willst Du sagen, dass die erste Form der Maskierung für Dich "unschön" ist?
Ja, da es sehr viele Zeichen für einen Delimiter sind.
Da darf man getrost fragen "na und?"
Sry, das verstehe ichj leider auch nicht 😕.
denn eine Hauptsache ist, dass es funktioniert, und eine andere ist, dass es wartbarer Code ist.
Sicherlich, jedoch würde ich anstatt {{{{$DELIMITER_START$:::: eben {# verwenden weil es kurz ist, sich nicht dem HTML-Code bedient und diese Kombination einprägsam ist - finde ich. Es gibt sicherlich weitere Aspekte den Delimiter so zu verwenden, aber die kenne ich nicht. Deswegen mein Thread 😉.
Im Übrigen verwende ich
{#platzhalter}in meinen Templates. Nur mal so. Weil Du von "kleinen Broten backen" sprichst, so als wäre das etwas Ungenügendes.
Sry, ich habe meine letzte die Redewendung "kleine Brote zu Backen" in diesem Kontext verwechselt und anders verstanden als die geläufige Interpretation. Und ich meine mit "Klüger" eher "sinnvoller meines erachtens". Ich habe mich unglücklich und falsch ausgedrückt. Aber ich habe mich ausgedrückt.
lgmb
Hallo MB,
was spricht aus deiner Sicht denn gegen {# und #}? Delimiter einer eingebetten Sprache müssen genau zwei Anforderungen erfüllen:
HTML ist eine Sprache, die - von der ursprünglichen Idee her - in Textdokumente eingebettet wurde. Dafür wurden < und > als Delimiter gewählt. < und > (für lesser than und greater than) sind die Hilfskonstrukte, die man nutzt, wenn < und > im Text benötigt werden.
Du bettest nun in HTML eine weitere Sprache ein: deine Template-Sprache. Die von Dir gewählten Delimiter {# und #} sind gut geeignet. Sie sind kurz, und sie haben in HTML, CSS, JS und PHP keine eigene Bedeutung. In natürlichem Text eigentlich auch nicht.
Andere Systeme verwenden andere Delimiter. Mustache nutzt {{ und }}. ASP verwendet <% und %>. PHP verwendet <?php und ?>. Smarty verwendet sogar nur { und } - was dumm erscheint, aber sie haben den Trick eingebaut, dass ein { oder }, das von Whitespace umgeben ist, von Smarty ignoriert wird.
Kann es sein, dass Du Dich zu sehr selbst in Frage stellst? Es ist okay, wenn man seine Entscheidungen überprüft. Man muss aber auch damit aufhören können. Deine Delimiter sind inhaltlich in guter Gesellschaft. Sie sind nicht falsch. Sie sind richtig genug. Bleib dabei.
Rolf
moin,
was spricht aus deiner Sicht denn gegen {# und #}?
Oh nicht's. Ich will allgemein wissen WIE die Syntax der jeweiligen Template-Sprache und der Zeichenvort der Syntax zu der eigentlichen Sprache gewählt wird.
Sry, wenn das nicht klar geworden ist.
Delimiter einer eingebetten Sprache müssen genau zwei Anforderungen erfüllen:
- sie müssen kompakt sein, damit man sich nicht die Finger wund tippt
- sie sollten im Kontext des Dokuments, in dem sie genutzt werden, selten bis gar nicht vorkommen.
Jepp
HTML ist eine Sprache, die - von der ursprünglichen Idee her - in Textdokumente eingebettet wurde. Dafür wurden < und > als Delimiter gewählt. < und > (für lesser than und greater than) sind die Hilfskonstrukte, die man nutzt, wenn < und > im Text benötigt werden.
Danke für den Geschichtlichen Kontext.
Du bettest nun in HTML eine weitere Sprache ein: deine Template-Sprache. Die von Dir gewählten Delimiter {# und #} sind gut geeignet. Sie sind kurz, und sie haben in HTML, CSS, JS und PHP keine eigene Bedeutung. In natürlichem Text eigentlich auch nicht.
Dankeschön 😀.
Andere Systeme verwenden andere Delimiter. Mustache nutzt {{ und }}. ASP verwendet <% und %>. PHP verwendet <?php und ?>. Smarty verwendet sogar nur { und } - was dumm erscheint, aber sie haben den Trick eingebaut, dass ein { oder }, das von Whitespace umgeben ist, von Smarty ignoriert wird.
Sehe ich - als Laihe - auch so.
Kann es sein, dass Du Dich zu sehr selbst in Frage stellst? […]
Ja sehr, aber nicht bezogen auf meine beiden Threads dieses Tages. Nur die Neugier hat mich getrieben mit möglichen Projekt vorstellungen in meinem Geiste.
[…] Es ist okay, wenn man seine Entscheidungen überprüft. Man muss aber auch damit aufhören können.
Ein weises wort. Ich orientiere mich daran mit schlechttem Erfolg 😕.
Deine Delimiter sind inhaltlich in guter Gesellschaft. […]
THX 😀. Aber nochmal die Eigangsfrage die ich undeutlich fromuliert habe - normal sry 😟. Warum sind beispilweise meine Delimiter gut bezogen auf die Natürliche Sprache mit ihrem dazugehörigen Zeichenvorat?
[…] Sie sind nicht falsch. Sie sind richtig genug. Bleib dabei.
Werde ich keine Sorge 😉.
lgmb
Hallo MB,
deine eigentliche Frage war doch:
Ich will allgemein wissen WIE die Syntax der jeweiligen Template-Sprache und der Zeichenvort der Syntax zu der eigentlichen Sprache gewählt wird.
Und die Antwort ist nur: Da gibt's aus technischer Sicht keine Vorschrift. Nur Nützlichkeitskriterien. Und die habe ich Dir genannt. Innerhalb der Kriterien bist Du frei.
Wenn Du unbedingt magst und eine passende Tastatur hast, kannst Du auch «Guillemets» verwenden, oder völlig abdrehen und spezialisierte Unicode-Symbole nutzen wie ⟦ ⟧, ⟃ ⟄ oder ⸶⸷, ⸤⸥, 〖〗, vielleicht auch ⏩⏪? Oder musikalisch, mit 𝄆 𝄇?
Alles Unicode-Symbole, letztlich Einzelzeichen. Wenn auch im UTF-8 mit 3 oder 4 Bytes codiert...
Diese Zeichen zeigen, dass ich ein Kriterium vergessen habe:
Und natürlich muss die Syntax so sein, dass sie in sich logisch erscheint und gut merkbar ist. Am besten auch so, dass auch derjenige, der dein System gar nicht kennt, beim Lesen des Templates intuitiv eine Ahnung gewinnt, was da passiert. An der Stelle verlässt Du aber den Bereich der Technik, jetzt kommst Du zur Psychologie. Und viel Erfahrung. Ob's da Literatur gibt, tja. Keine Ahnung.
Guck Dir andere Templatesysteme an. Orientiere Dich daran. Dann kannst Du nicht allzu falsch liegen. Und denk dran: egal was du tust, irgendwer motzt immer. Dickes Fell ist da nützlich.
Rolf
moin,
deine eigentliche Frage war doch:
Ja du hast recht.
Und die Antwort ist nur: Da gibt's aus technischer Sicht keine Vorschrift. Nur Nützlichkeitskriterien. Und die habe ich Dir genannt. Innerhalb der Kriterien bist Du frei.
Deswegen meine Vorsicht wenn man alles machen kann.
- Die Syntax muss aus Zeichen bestehen, die man leicht eingeben kann und die in den meisten Fonts verfügbar sind (die Chance steht gut, dass einige Leser dieses Beitrags an Stelle der Zeichen nur Kästchen sehen)
Ist mir auch Untergegangen 😕
Und natürlich muss die Syntax so sein, dass sie in sich logisch erscheint und gut merkbar ist.
check
Am besten auch so, dass auch derjenige, der dein System gar nicht kennt, beim Lesen des Templates intuitiv eine Ahnung gewinnt, was da passiert.[…]
check
[…] An der Stelle verlässt Du aber den Bereich der Technik, jetzt kommst Du zur Psychologie. Und viel Erfahrung. Ob's da Literatur gibt, tja. Keine Ahnung.
Aha, das habe ich aus diesem Blickwinkel nicht betrachtet.
Guck Dir andere Templatesysteme an. Orientiere Dich daran. Dann kannst Du nicht allzu falsch liegen.
Werde ich machen 😀
Und denk dran: egal was du tust, irgendwer motzt immer. Dickes Fell ist da nützlich.
Ich versuchs.
lgmb
Tach!
für user lesbaren Text gibt es Kombinationen die ein Parser nicht als Magic String erkennt und diese Kombination so ohne Veränderung ausgibt.
Der Begriff Magic String steht bereits für etwas anderes. Gemeint sind damit Stringliterale im Code, mit denen ein bestimmter Effekt erreicht werden kann, vorausgesetzt man kennt den Wert. Zudem weiß man nie, ob zwei gleiche Strings an unterschiedlichen Stellen auch dasselbe meinen. Besser ist es, Konstanten zu definieren, denen man einen sprechenden Namen geben kann. Wenn zwei gleiche Strings für unterschiedliche Dinge stehen, kann man das anhand zweier Konstanten sehen. Und falls man einen String ändern muss, ändert man den Wert der Konstanten, statt dass man mit Suchen und Ersetzen auch alle anders gemeinten Bedeutungen ersetzt.
$db = mysqli_connect("127.0.0.1", "test", "test", "test");
In diesem Beispiel gibt es neben der IP-Adresse dreimal den Wert test als Magic Strings. Die Bedeutung ist immer eine andere. Man kann sie nicht aus dem Wert entnehmen. Man muss anhand der Dokumentation der Funktion herausfinden, wofür welcher Wert steht. Mit Konstanten statt Stringliteralen / Magic Strings wird es eindeutig.
define('HOST', '127.0.0.1');
define('USERNAME', 'test');
define('PASSWORD', 'test');
define('DATABASE', 'test');
$db = mysqli_connect(HOST, USERNAME, PASSWORD, DATABASE);
Oder
if ($variable == 'D') { ... }
Es ist aus dem Code nicht zu erkennen, wofür hier das D steht. Man muss den Kontext oder den Anwendungsfall kennen. Eine Konstante mit sprechendem Namen wäre verständlicher als der Magic String.
Abgesehen davon kennt die englischsprachige Wikipedia eine weitere Bedeutung für den Begriff.
Du hingegen hast Platzhalter, wenn die Bezeichner direkt nachgeschlagen werden können, oder Template Expressions, wenn der Wert erst noch berechnet werden muss.
dedlfix.
Hallo dedlfix,
da hast du aber schön aus dem Wiki abgeschrieben 😂.
Ne, ne: Umgekehrt, jetzt auch im Wiki.
Bis demnächst
Matthias
moin,
Tach!
für user lesbaren Text gibt es Kombinationen die ein Parser nicht als Magic String erkennt und diese Kombination so ohne Veränderung ausgibt.
Der Begriff Magic String steht bereits für etwas anderes. […]
Sry. Wie so oft habe ich mich missverständlich ausgedrückt 😕. Danke für die Richtigstellung.
lgmb
Frage
Es geht mir um Zeichen-Kombinationen im jeweiligen Kontext einer MarkUp-> > Sprache die nicht von jeweligen Parser interpretiert werden.
Du hast es hier mit zwei formalen Sprachen zu tun, und zwar mit HTML und deiner Template-Sprache. HTML ist vorgegeben, die Template-Sprache entwickelst du selber. Es gibt verschiedene Arten die beiden Sprachen übereinander zu legen, es gibt grob vereinfacht drei populäre Vorgehensweisen:
Du könntest deine Template-Sprache zu einer Supermenge von HTML machen. Dann würde deine Grammatik alle Regeln der HTML-Grammatik besitzen und zusätzliche Regeln für Template-spezifischen Features.
Du könntest deine Sprache in HTML einbetten. Dann müsstest du dafür sorgen, dass die Sonderzeichen von HTML in den Template-Fragmenten mit HTML-Entities maskiert werden.
Du könntest HTML in deine Template-Sprache einbetten. Dann müsstest du dafür sorgen, dass die Sonderzeichen der Template-Sprache in den HTML-Fragmenten maskiert werden.
Die erste Methode ist recht aufwändig, weil du einen kompletten HTML-Parser in deine Template-Engine integrieren müsstest. Deswegen gehe ich da mal nicht weiter drauf ein.
Für die Methoden zwei und drei ist es eine gute Idee, die Sonderzeichen deiner Template-Sprache so zu wählen, dass sie sich möglichst nicht mit den Sonderzeichen von HTML überschneiden. Auf diesen Gedanken bist du ja rein instinktiv auch schon gestoßen. Je nach gewünschten Features wirst du aber nicht ganz um Maskierungen herum kommen. Ob du nun den zweiten oder dritten Weg wählst, hängt maßgeblich davon ab, ob deine Template-Engine server- oder clientseitig laufen soll. Falls serverseitig, dann ist Option drei eine gängige Wahl.