glob() case insensitive - welche variante

[frankx]

Ahoi alle

      $this->_fileNames = array_merge(glob($folderName . "/*.pdf"), glob($folderName . "/*.PDF"));
      $this->_fileNames = glob($folderName . "/*.[pP][dD][fF]");
      $this->_fileNames = glob($folderName . "/*.{pdf,PDF}", GLOB_BRACE);
 

welche der drei varianten wäre warum zu bevorzugen, wenn man alle ".pdf" und ".PDF" einsammelne will? vermutlich geschmackssache, oder? "funzen" alle drei ...; s.a. http://php.net/manual/de/function.glob.php

Dank und Gruß,

bob from berlin

[Sven Rautenberg]

Moin!

Ahoi alle

      $this->_fileNames = array_merge(glob($folderName . "/*.pdf"), glob($folderName . "/*.PDF"));
      $this->_fileNames = glob($folderName . "/*.[pP][dD][fF]");
      $this->_fileNames = glob($folderName . "/*.{pdf,PDF}", GLOB_BRACE);
 

welche der drei varianten wäre warum zu bevorzugen, wenn man alle ".pdf" und ".PDF" einsammelne will? vermutlich geschmackssache, oder? "funzen" alle drei ...; s.a. http://php.net/manual/de/function.glob.php

Die letzte.

Warum? Weil die nur einmal durch das Verzeichnis geht (die erste geht zweimal), und weil sie nicht ".pDf" findet (wie es die zweite tut).

Grüße Sven

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

      $this->_fileNames = array_merge(glob($folderName . "/*.pdf"), glob($folderName . "/*.PDF"));
      $this->_fileNames = glob($folderName . "/*.[pP][dD][fF]");
      $this->_fileNames = glob($folderName . "/*.{pdf,PDF}", GLOB_BRACE);
 

welche der drei varianten wäre warum zu bevorzugen, wenn man alle ".pdf" und ".PDF" einsammelne will? vermutlich geschmackssache, oder? "funzen" alle drei ...; s.a. http://php.net/manual/de/function.glob.php

Die letzte.

Warum? Weil die nur einmal durch das Verzeichnis geht (die erste geht zweimal), und weil sie nicht ".pDf" findet (wie es die zweite tut).

War da jetzt der "lesen wir mal bewusst nicht zwischen den Zeilen und nehmen wir alles wörtlich"-Clown-Filter eingeschaltet, oder wie soll man die Antwort bewerten?

Spirituelle Grüße
Euer Robert
[e-mail]

[Sven Rautenberg]

Moin!

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

      $this->_fileNames = array_merge(glob($folderName . "/*.pdf"), glob($folderName . "/*.PDF"));
      $this->_fileNames = glob($folderName . "/*.[pP][dD][fF]");
      $this->_fileNames = glob($folderName . "/*.{pdf,PDF}", GLOB_BRACE);
 

welche der drei varianten wäre warum zu bevorzugen, wenn man alle ".pdf" und ".PDF" einsammelne will? vermutlich geschmackssache, oder? "funzen" alle drei ...; s.a. http://php.net/manual/de/function.glob.php

Die letzte.

Warum? Weil die nur einmal durch das Verzeichnis geht (die erste geht zweimal), und weil sie nicht ".pDf" findet (wie es die zweite tut).

War da jetzt der "lesen wir mal bewusst nicht zwischen den Zeilen und nehmen wir alles wörtlich"-Clown-Filter eingeschaltet, oder wie soll man die Antwort bewerten?

Ich verstehe deine Frage nicht.

Aber du darfst frankx' Frage gerne selbst beantworten.

Grüße Sven

[frankx]

Ahoi Sven

War da jetzt der "lesen wir mal bewusst nicht zwischen den Zeilen und nehmen wir alles wörtlich"-Clown-Filter eingeschaltet, oder wie soll man die Antwort bewerten?

Ich verstehe deine Frage nicht.

Aber du darfst frankx' Frage gerne selbst beantworten.

"Robert" tuts auch und ja, das hätte ich schon fast in die Frage reingeschrieben, pDf und PdF und so weiter ist ja garnicht sinnig bei Variante 2.

Dank und Gruß,

bob from berlin

[Jörg Reinholz]

Moin!

War da jetzt der "lesen wir mal bewusst nicht zwischen den Zeilen und nehmen wir alles wörtlich"-Clown-Filter eingeschaltet, oder wie soll man die Antwort bewerten?

Du darfst Dich da nicht wundern. Programmierer müssen einen Katalog von Aufgaben (oft "Pflichtenheft" genannt) genau abarbeiten. Gefordert war, durch ein Programm *.pdf und *.PDF zu erkennen. Halbwegs begnadete Programmierer fangen irgendwann an auf eine Weise zu "denken", wie es ein Automat auch tun würde. Denn wenn ein Programmierer anfangen würde, die Aufgabe zu interpretieren, dann würde dieses früher oder später zu einem bedenklichen Chaos führen.

Man muss also bei der Definition der Aufgabe bedenken, dass

1. die gestellte Aufgabe regelmäßig auch die Dokumentation des Moduls || der Funktion || des Objektes ist;
2. Module wieder verwendet werden wenn die gleiche Aufgabe nochmals zu lösen ist;
3. bei komplexen Programmen, die von großen Organisationen gefertigt werden, der einzelne Programmierer das gewünschte Gesamtprogramm nicht mal kennt, woraus resultiert, dass er, mangels Anhaltspunkten, gar nichts interpretieren kann;
4. bei jenen, die Aufgabe interpretierenden "Lösungen" die Dokumentation nicht mehr zutreffend ist, das Programm also nicht das macht, was es soll - was mindestens in sporadisch auftretenden Fehlern resultiert, deren Ursache zu finden unerhört schwierig sein kann;
5. sich niemand wundern darf, wieso eigentlich ein Programm einen Ziegelstein als gültiges Brot anerkennt, wenn man im Pflichtenheft fordert, dass ein gültiges Brot einzig anhand der Kantenlänge erkannt wird.

Herangehensweise: Behandle einen Programmierer wie einen Autist, beschreibe zu lösende Aufgaben genau - und, das gilt hier, stets vollständig.

In diesem Sinne ist übrigens die Antwort von Sven,

und weil sie nicht „.pDf“ findet (wie es die zweite tut).

durchaus als Ironie und Hinweis auf die wahrscheinlich fehlerhafte Aufgabe zu verstehen.

Jörg Reinholz

[Gunnar Bittersmann]

@@Jörg Reinholz

Halbwegs begnadete Programmierer fangen irgendwann an auf eine Weise zu „denken“, wie es ein Automat auch tun würde.

Um den Turing-Test zu bestehen?

Vollends begnadete Programmierer haben diesen Schritt hinter sich gelassen oder gleich übersprungen.

Man muss also bei der Definition der Aufgabe bedenken, dass 1. 2. 3. 4. 5.

TL;DR: … dass Programmierer Scheuklappen aufhaben und nicht mitdenken, schon gar nicht über ihren Tellerrand hinaus.

Mitunter traurige Wahrheit. Das sollte aber nicht so sein.

2. Module wieder verwendet werden wenn die gleiche Aufgabe nochmals zu lösen ist;

Nicht das Problem von dem, der die Aufgabe (in Form einer user story) definiert; sondern von dem, der sie umsetzt, d.h. des Programmierers.

5. sich niemand wundern darf, wieso eigentlich ein Programm einen Ziegelstein als gültiges Brot anerkennt, wenn man im Pflichtenheft fordert, dass ein gültiges Brot einzig anhand der Kantenlänge erkannt wird.

Das zeugt von mangelhafter Zusammenarbeit und Kommunikation zwischen Produktmanager und Programmierer. Daran sollten beide arbeiten.

Herangehensweise: Behandle einen Programmierer wie einen Autist

Wenn es ein solcher ist: ja.

Ansonsten: nein. Verlange vom Programmierer, dass er sich nicht wie ein solcher verhält.

LLAP

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Herangehensweise: Behandle einen Programmierer wie einen Autist

Wenn es ein solcher ist: ja.

Kam gerade übern Ticker: Briefe an einen zehnjährigen Autisten

LLAP

[Jörg Reinholz]

Moin!

Kam gerade übern Ticker: Briefe an einen zehnjährigen Autisten

By the way: Manchmal lese ich (nicht nur) hier Zeug und verstehe - obwohl mir die Bedeutung jedes einzelnen Wortes wohlbekannt ist, kein solches und wundere mich sehr darüber, dass andere a) darauf antworten und b) (wenngleich längst nicht immer) der Autor der Schüttelsätze sich für die richtige Antwort bedankt - während ich mir dann mühsam aus den Antworten zusammenreime, was wohl sein Problem gewesen sei ...

Und obwohl ich, ausweislich des vorstehenden Kastensatzes, keiner sein kann frage ich mich dann immer, ob ich nicht vielleicht doch ... ?

Jörg Reinholz

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Das zeugt von mangelhafter Zusammenarbeit und Kommunikation zwischen Produktmanager und Programmierer. Daran sollten beide arbeiten.

Desöfteren sprechen sie ja wirklich eine verschiedene Sprache. Ein Frontend-Entwickler dürfte der sein, der da übersetzen kann, weil er beide Sprachen versteht. Zum einen sollte er sich mit Produktmanagern und Designern über IA (information architecture), IxD (interaction design), UX (user experience) und visuellem Design austauschen können (d.h. darin auch etwas bewandert sein). Zum anderen die logische Denkweise haben, das in Code umzusetzen, sich also auch mit (Backend-)Programmierern verständigen können.

Der Frontend-Entwickler sollte der sein, der den Backend-Entwicklern sagt, was sie zu tun haben. Damit das Backend genau das liefert, was man im Frontend haben will. Um das System auf den Nutzer abzustimmen. Nicht auf die Technik dahinter. Leider oft anzutreffen: Die Systemlogik wird dem Nutzer übergestülpt (obwohl der ganz anders denkt), und der Frontend-Entwickler soll das mal eben „hübsch“ machen.

Dummerweise lässt sich das basisdemokratisch kaum durchsetzen, dass Frontend-Entwickler in der Sytementwicklung den Ton angeben, weil die Backend-Entwickler meist in der Mehrzahl sind. Das müsste also „von oben“ kommen. Nun ist es aber so, dass der CTO auch meist einen Programmierer-Hintergrund hat … Ihr versteht das Dilemma. Das eigentliche Problem ist mitunter nicht das Nichtverstehen zwischen Produktmanagern/Designern und Entwicklern, sondern zwischen Frontend-Entwicklern und Backend-Entwicklern/CTO.

Das Unverständnis, was denn die Arbeit eines Frontend-Entwicklers ausmachen sollte, zeigt sich übrigens auch in Stellenanzeigen:

• „Frontend-Entwickler … Angular“ – Nein, ihr sucht keinen Frontend-Entwickler, sondern einen (Backend-)Programmierer. Angular ist nichts für Frontender; „one could describe it as a front-end framework by non-front-enders for non-front-enders.“ (Peter Paul Koch)

• „Frontend-Entwickler … Bootstrap“ – Nein, ihr sucht keinen Frontend-Entwickler, sondern einen Werkstudenten. Bootstrap ist nichts für Frontender; „Bootstrap ist das Ikea der Webentwicklung.“ (Peter Kröner) „Bootstrap (noun): a CSS library applied to a site when the developer has lost heart in their profession.“ (@iamdevloper)

LLAP

[Jörg Reinholz]

Moin!

Der Frontend-Entwickler sollte der sein, der den Backend-Entwicklern sagt, was sie zu tun haben. Damit das Backend genau das liefert, was man im Frontend haben will.

Ist das nicht der Job des Projektmanagers?

Jörg Reinholz

[Gunnar Bittersmann]

@@Jörg Reinholz

Der Frontend-Entwickler sollte der sein, der den Backend-Entwicklern sagt, was sie zu tun haben. Damit das Backend genau das liefert, was man im Frontend haben will.

Ist das nicht der Job des Projektmanagers?

Nein.

Zum einen ist es nicht Job des Projektmanagers/Produktmanagers zu sagen, wie der HTML-Code aussehen soll. Sein Job ist es zu sagen: Ich will eine Seite, die von allen bedient werden kann: schnell, responsiv, barrierefrei.

Da Backend-Entwickler oft nur ein HTML-Element kennen, nämlich div, ist es Aufgabe des Frontend-Entwicklers zu sagen, wie das generierte HTML auszusehen hat.

Zum anderen entsprang die Diskussion ja gerade daran, dass Backend-Entwickler manchmal nicht verstehen, was der PM will. Und wie ich schon sagte, sehe ich es auch nicht als seine Aufgabe, das so zu spezifizieren, dass die Backend-Entwickler das ohne selbst zu denken umsetzen können.

LLAP

[MudGuard]

Hi,

Da Backend-Entwickler oft nur ein HTML-Element kennen, nämlich div, ist es Aufgabe des Frontend-Entwicklers zu sagen, wie das generierte HTML auszusehen hat.

Nein. Der Frontendentwickler hat ein Template zu liefern mit den gewünschten Variablen.

Der Backendentwickler hat dann dafür zu sorgen, daß die Variablen entsprechend ersetzt werden. Das Backend sollte kein HTML generieren.

(daß dabei natürlich abgesprochen wird, wie die Variablen im Template syntaktisch ausgezeichnet werden, und welche Variablen welche Werte enthalten sollen - soweit sich das nicht aus dem Namen ergibt - ist klar.)

cu,
Andreas a/k/a MudGuard

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

Da Backend-Entwickler oft nur ein HTML-Element kennen, nämlich div, ist es Aufgabe des Frontend-Entwicklers zu sagen, wie das generierte HTML auszusehen hat.

Nein. Der Frontendentwickler hat ein Template zu liefern mit den gewünschten Variablen.

Der Backendentwickler hat dann dafür zu sorgen, daß die Variablen entsprechend ersetzt werden. Das Backend sollte kein HTML generieren.

Wie geht das bei Tabellen, Listen und anderen n-mal zu wiederholenden Wertausgaben (also Datensätze), bei denen n vom Backend bestimmt wird? Darüber sinniere ich nun schon ein Jahr, wie man das richtig™ macht, also die totale Trennung von Auszeichnungssprache, Daten und Datenverwaltenden Algorithmen zu gewährleisten. Dabei sollte man HTML morgen auch leicht gegen MEAS austauschen können, indem man einfach die Templates wechselt. Ach und ja: von den Templates darf keinerlei Einflussnahme auf die datenliefernden Algorithmen ausgehen können!

Spirituelle Grüße
Euer Robert
[e-mail]

[MudGuard]

Hi,

Der Backendentwickler hat dann dafür zu sorgen, daß die Variablen entsprechend ersetzt werden. Das Backend sollte kein HTML generieren.

Wie geht das bei Tabellen, Listen und anderen n-mal zu wiederholenden Wertausgaben (also Datensätze), bei denen n vom Backend bestimmt wird?

ein gutes Template-System stellt natürlich auch Konstrukte für Schleifen zur Verfügung.

cu,
Andreas a/k/a MudGuard

[Christian Kruse]

Hallo MudGuard,

ein gutes Template-System stellt natürlich auch Konstrukte für Schleifen zur Verfügung.

Das sieht die Logicless-Templates-Bewegung anders ;) (wohlgemerkt, ich widerspreche nicht)

LG,
CK

[MudGuard]

Hi,

ein gutes Template-System stellt natürlich auch Konstrukte für Schleifen zur Verfügung.

Das sieht die Logicless-Templates-Bewegung anders ;) (wohlgemerkt, ich widerspreche nicht)

Ich bin Pragmatiker, kein "die Theorie ist wichtiger als das brauchbare Ergebnis."-Anhänger

cu,
Andreas a/k/a MudGuard

[Gunnar Bittersmann]

@@MudGuard

Da Backend-Entwickler oft nur ein HTML-Element kennen, nämlich div, ist es Aufgabe des Frontend-Entwicklers zu sagen, wie das generierte HTML auszusehen hat.

Nein. Der Frontendentwickler hat ein Template zu liefern mit den gewünschten Variablen.

Ja doch. Templates sind eine Möglichkeit „zu sagen, wie das generierte HTML auszusehen hat.“

Das Backend sollte kein HTML generieren.

Ja. Tun Backend-Entwickler aber mitunter doch. Wobei man das dann kaum HTML nennen kann, sondern HTMüll.

LLAP

[1unitedpower]

Das Backend sollte kein HTML generieren.

Könnt ihr mal genauer erläutern, was ihr unter Backend und Frontend versteht? Ein Backend kann so vieles sein, die Admin-Oberfläche von Typo3 bezeichnet man gemeinhin als Backend, in Client-Server-Anwendungen bezeichnet man den Server als Backend und in SPAs wird das JS-Framework häufig als Backend bezeichnet. Ich fürchte, ich kann euch hier nicht ganz folgen und mir kommt es so vor, als redet ihr auch aneinander vorbei.

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

Das Backend sollte kein HTML generieren.

Könnt ihr mal genauer erläutern, was ihr unter Backend und Frontend versteht? Ein Backend kann so vieles sein, die Admin-Oberfläche von Typo3 bezeichnet man gemeinhin als Backend, in Client-Server-Anwendungen bezeichnet man den Server als Backend und in SPAs wird das JS-Framework häufig als Backend bezeichnet. Ich fürchte, ich kann euch hier nicht ganz folgen und mir kommt es so vor, als redet ihr auch aneinander vorbei.

Insbesondere ist hier keiner von den Vortragenden bisher mal konkret geworden.

Wenn ich mit HTML-Muster-Template arbeite, dann haben alle später darin befindlichen Elemente bereits drin zu sein, so dass ich ein "Look & Feel" durchführen kann, die Validität prüfen kann und ein Styling per CSS durchführen kann. Das einzige, was fehlt, sind die echten Daten.

Das Backend oder das Zwischengesicht können dieses Template nun expandieren oder komprimieren, d.h. Elemente hinzufügen oder entfernen und selbstverständlich die echten Nutzdaten an den richtigen Stellen einsetzen. Und genau HIER greift die Forderung von der strikten Trennung nicht mehr. Das Backend oder besser das Interface müssen nun sehr wohl wissen, an welcher Template-Sprache sie zu operieren haben. Alternativ muss das Template eine eigene Aufbereitung erhalten, durch die es aber i.d.R. seine Validität im Rohzustand verliert.

Deshalb steht immer noch meine Frage im Raum, wie man denn die bestmögliche Trennung erreichen kann?

Spirituelle Grüße
Euer Robert
[e-mail]

[1unitedpower]

Wenn ich mit HTML-Muster-Template arbeite, dann haben alle später darin befindlichen Elemente bereits drin zu sein

Du machst es mir schwer dir zu folgen, du verwendest Template mehrdeutig für das rohe Template - die Schablone - und offentlich auch für das fertig gerenderte Produkt. Ein Template kann selbstverständlich Platzhalter für generischen Inhalt bereitstellen, im fertigen Produkt sollten diese dann ersetzt worden sein und nicht mehr vorkommen. Das fertige Produkt ist meistens eine Komposition von vielen Templates gefüllt mit Daten aus aus vielen ViewModels, da kann man schlecht vorhersagen, welche Elemente letztendlich wirklich hineinfließen.

so dass ich ein "Look & Feel" durchführen kann, die Validität prüfen kann und ein Styling per CSS durchführen kann. Das einzige, was fehlt, sind die echten Daten.

Templates können in ganz unterschiedlichen Kontexten wiederverwendet werden, DAS "Look & Feel" und DAS "Styling" für ein Tempate existiert nicht. Ein Template für sich genommen kann nur in einem sehr eingeschränkten Rahmen getestet und gestaltet werden. Um zu sehen, wie sich ein Template in verschiedenen Umgebungen verhält, muss man Integrationstests durchführen. Wenn man noch keine Originaldaten zum Testen hat, oder wenn man aus anderen Gründen nicht mit den Originaldaten testen möchte, dann kann man Prototypen entwickeln, die verschiedene Umgebungen "mocken".

Das Backend oder das Zwischengesicht können dieses Template nun expandieren oder komprimieren, d.h. Elemente hinzufügen oder entfernen und selbstverständlich die echten Nutzdaten an den richtigen Stellen einsetzen. Und genau HIER greift die Forderung von der strikten Trennung nicht mehr.

Meinst du mit Backend die Templating-Engine? Dann verstehe ich nicht, wo du hier die strikte Trennung von Daten und Präsentation verletzt siehst, beides kann getrennt voneinander entwickelt werden und ausgetauscht werden ohne den jeweils anderen Bereich zu tangieren. Irgendwann kommt natürlich der Punkt an dem Daten und Schablone mal zusammengeführt werden müssen, aber das passiert ja automatisch. Da sehe ich also keine Mischung der Verantwortlichkeiten.

Das Backend oder besser das Interface müssen nun sehr wohl wissen, an welcher Template-Sprache sie zu operieren haben.

Auch du müsstest mal bitte konkretisieren, was du mit Backend eigentlich meinst, Interface ist da auch nicht viel aufschlussreicher. Und auch was du in diesem Zusammenhang mit Tempalte-Sprache meinst erschließt sich mir nicht. Hier kommt es mir er so vor, als redest du von dem finalen Ausgabeformat (zum Beispiel HTML), als von der Templatingsprache (zum Beispiel mustache). Korrigiere mich, wenn ich damit falsch liege.

Alternativ muss das Template eine eigene Aufbereitung erhalten, durch die es aber i.d.R. seine Validität im Rohzustand verliert.

Das verstehe ich nun wirklich nicht, wann ist ein Template denn valide?

Deshalb steht immer noch meine Frage im Raum, wie man denn die bestmögliche Trennung erreichen kann?

Tipp ins Blaue: Du suchst du nach etwas wie Databinding, also nach einer Möglichkeit Daten und Views möglichst elegant miteinander zu synchronisieren ohne dabei ins Datenmodell oder ins Tempalte eingreifen zu müssen.

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

Meinst du mit Backend die Templating-Engine?

Das Backend ist hier die Datenverwaltung inklusive Zugriffsrechten, Logging, Ergebnismengen, usw. von Queries auf das Datenmodell.

Dann verstehe ich nicht, wo du hier die strikte Trennung von Daten und Präsentation verletzt siehst, beides kann getrennt voneinander entwickelt werden und ausgetauscht werden ohne den jeweils anderen Bereich zu tangieren. Irgendwann kommt natürlich der Punkt an dem Daten und Schablone mal zusammengeführt werden müssen,

genau!

> aber das passiert ja automatisch. 

Und wie funktioniert das? Um die Auflösung dieses kleinen Satzes drücken sich immer Alle.

Da sehe ich also keine Mischung der Verantwortlichkeiten.

Ich schon! Hier wird im datentechnischen Wortsinne gemischt. Und es wird repetitiv gemischt. Das hat schon zu Zeit en der guten alten Reportgeneratoren zu Problemen geführt, die bis heute nie wirklich gelöst wurden.

Das Backend oder besser das Interface müssen nun sehr wohl wissen, an welcher Template-Sprache sie zu operieren haben.

Auch du müsstest mal bitte konkretisieren, was du mit Backend eigentlich meinst, Interface ist da auch nicht viel aufschlussreicher.

Vokabeln lernen?

Ich freue mich auf weitere Anregungen um den Knoten zu lösen. Wenn ich auf einzelne Punkte noch nicht geantwortet habe, dann sind die in meinem großen Topf der gegenseitigen Unverständnisse gelandet und harren noch meiner Deutung.

Ich habe hier "Template" im Sinne von "Schablone" oder "Maske" benutzt, in die dann später die Daten eingesetzt werden müssen. Zu Zeiten von System-36 oder ähnlichen "Anlagen der mittleren Datentechnik" gab es noch fäufig die Feststellung: Die Bildschirmmaske ist eingebrannt. Die Maske wurde also getrennt von den Daten übertragen (vorausgeschickt) und stand oft den ganzen Tag, oft auch leer (also ohne Daten) auf dem Bildschirm. Erst durch "Ansi-Daten-Strom" (gemeint war das mixen von Bildschirmdaten und Steuerzeichen) und viel später dann eben HTML als Inline-Formate wurde das geändert. Außerdem kamen mehrere Bildschirmseiten, Videoadatper mit Grafikfunktionlaität, Apple und Commodore mit grafischen Workbenches, Windows usw.

Dazu war aber am Client schon mehr Rechenpower notwendig.

Der Begriff des "Templates" oder der "Maske" ist also älter, als heute gerne gedacht wird.

Und die Ideen, was alles noch an reduzierter Hardware kommen wird, sind auch schon sehr alt.

Spirituelle Grüße
Euer Robert
[e-mail]

[1unitedpower]

Meinst du mit Backend die Templating-Engine?

Das Backend ist hier die Datenverwaltung inklusive Zugriffsrechten, Logging, Ergebnismengen, usw. von Queries auf das Datenmodell.

Also alles außer die Templating-Engine? Dann lass uns den Teil doch einfach ausklammern und stattdessen isoliert über die TE sprechen.

> aber das passiert ja automatisch. 

Und wie funktioniert das? Um die Auflösung dieses kleinen Satzes drücken sich immer Alle.

Du meinst, wie aus Daten und Template letztlich das fertige Produkt gerendert wird? Das ist natürlich stark von der jeweilige TE selbst abhängig und auf diesem abstrakten Niveau kaum zu beantworten. Es ist schwierig hier ein allgemeingültiges Rezept für alle Templating-Enginges anzugeben, weil die Unterschiede untereinander schon so groß sind. Von logic-less TEs wie Mustache bis hin zu full-logic Templatesprachen wie PHP, über textbasierte TEs wie Ember.js und DOM-basierte TEs wie in Angular.js. Ich glaube nicht, dass es zielführend sein kann, diese Unterschiede irgendwie auf einen gemeinsamen Nenner zu bringen.

In irgendeiner Form wird es wohl meistens ein ausgezeichnetes ViewModel geben, aus denen die Daten stammen, und ein ausgezeichnetes Template, die zusammengenommen den Anfang für den Rendering-Prozess bilden. Dann werden nach den Produktionsregeln der TE die Platzhalter-Ausdrücke im Template durch Daten aus dem ViewModel ersetzt. Dieser Schritt kann Rekursion erfordern, das Einbetten eines Datum aus dem ViewModel kann also wiederum einen Rendering-Prozess mit einem Template erfordern.

Das wird sicher auch nicht allen Templating-Systemen gerecht, aber es ist ein Versuch.

Da sehe ich also keine Mischung der Verantwortlichkeiten.

Ich schon! Hier wird im datentechnischen Wortsinne gemischt. Und es wird repetitiv gemischt. Das hat schon zu Zeit en der guten alten Reportgeneratoren zu Problemen geführt, die bis heute nie wirklich gelöst wurden.

Am besten illustrierst du deine Gedanken mal an einer Templating-Engine deiner Wahl. Vielleicht hast du ja recht, und bei der TE, die dir gerade in Gedanken vorschwebt, ist wirklich keine strikte Trennung gewährleistet. Für den allgemeinen Fall, kann ich dir bescheinigen, dass es genügend Vertreter gibt, die eine klare Trennung von Daten und Präsentation realisieren. Schau dir zum Beispiel mal {{mustache}} an, das Rendering wird dort einfach von einer Funktion mit zwei Argumenten Template und ViewModel realisiert.

Das Backend oder besser das Interface müssen nun sehr wohl wissen, an welcher Template-Sprache sie zu operieren haben.

Auch du müsstest mal bitte konkretisieren, was du mit Backend eigentlich meinst, Interface ist da auch nicht viel aufschlussreicher.

Vokabeln lernen?

In der Softwaretechnik kannst du so vieles mit Interface bezeichnen, deswegen ja die Nachfrage, worauf du dich genau beziehst.

Ich habe hier "Template" im Sinne von "Schablone" oder "Maske" benutzt, in die dann später die Daten eingesetzt werden müssen.

Zu Zeiten von

Das wird mir hier zu ausschweifend...

[frankx]

Ahoi Jörg

Herangehensweise: Behandle einen Programmierer wie einen Autist, beschreibe zu lösende Aufgaben genau - und, das gilt hier, stets vollständig.

In diesem Sinne ist übrigens die Antwort von Sven,

und weil sie nicht „.pDf“ findet (wie es die zweite tut).

durchaus als Ironie und Hinweis auf die wahrscheinlich fehlerhafte Aufgabe zu verstehen.

Die Aufgabenstellung ist in dem Fall meine eigene. Ich hatte vorher nur mit "pdf" gearbeitet, und dann hat mein Scanner aber, ohne dass ich es gemerkt habe, ".PDF" ausgespuckt. Und erst vom Steuerberater kam die Rückmeldung, es fehlten Rechnungen. Ich dachte erst, es läge beim Zusammenführen der PDFs mit PHP/ZendFramework an dem PDF selbst. Und erst beim Radeln kam ich plötzlich drauf, es könne ja auch die Endung sein.

Meine Frage war übrigens im Grunde genau an Sven gerichtet, weil ich weiß, dass er sich tagaus tagein mit PHP und ZendFramework beschäftigt und mir bei dieser eher "krümelkackerischen" Frage bestimmt genau die richtige Begründung für den Weg geben könnte (da steht im Manual u.a. auch, dass gewisse Funktionen bei gewissen BS nicht funzen ...). Die Antwort war perfekt und es ist auch richtig, dass ich den Fall "pDf" oder so nicht brauche. Das war mir schon beim Beispiel im Manual (da mit [cC][sS][vV]) schon aufgefallen, dass das mehr Fälle einschließt als benötigt (und irgendwie auch "komisch" aussieht).

Jörg Reinholz

Dank und Gruß,

bob from berlin

[robertroth]

Lieber Bob, liebe Mitdenker, liebe Wissende, liebe Neugierige,

In diesem Sinne ist übrigens die Antwort von Sven,

und weil sie nicht „.pDf“ findet (wie es die zweite tut).

durchaus als Ironie und Hinweis auf die wahrscheinlich fehlerhafte Aufgabe zu verstehen.

Dann gib mir doch bitte die Punkte, die mir die Anderen schon wieder weggenommen haben, weil sie scheinbar ihre Ironie-Detektoren ausgeschaltet hatten :-P

Sven hat die Punkte mMn jedenfalls nicht verdient, weil er einfach am Thema vorbei gepostet hat und seinen eigenen Spaß-Thread daraus gemacht hat...

Spirituelle Grüße
Euer Robert
[e-mail]

[Jörg Reinholz]

Moin!

Dann gib mir doch bitte die Punkte, die mir die Anderen schon wieder weggenommen haben, weil sie scheinbar ihre Ironie-Detektoren ausgeschaltet hatten :-P

Nana! Nach Punkten betteln ist sowas von verpönt (Ich war es übrigens nicht.)

Sven hat die Punkte mMn jedenfalls nicht verdient, weil er einfach am Thema vorbei gepostet hat und seinen eigenen Spaß-Thread daraus gemacht hat...

Nö. Er hat absolut exakt auf die Frage geantwortet und sogar das in der Frage liegende Probleme aufgegriffen.

Jörg Reinholz

[Jörg Reinholz]

Moin!

Ich hatte vorher nur mit "pdf" gearbeitet, und dann hat mein Scanner aber, ohne dass ich es gemerkt habe, ".PDF" ausgespuckt. Und erst vom Steuerberater kam die Rückmeldung, es fehlten Rechnungen.

Naja ... und was ist, wenn jemand beim manuellen Ablegen einer Datei mal .Pdf tippt? Ich persönlich würde deshalb auf jeden Fall zu einem Regex greifen, der GROSS und klein erfasst.

Jörg Reinholz