Noch ne Programmier-Bibliothek - Braucht man das? - Diskussionen nicht zum Thema

[Stefek]

Hallo Thorn,
ja, Du hast mich verstanden.
Danke, wäre aus der Nummer nicht wieder rausgekommen

Gruß,
Stefek

[WebBird]

Wenn Du Dein Beispiel an meines anpassen würdest - oder umgekehrt - wäre der Unterschied schon deutlich geringer.

Code:

$tpl  = new wbTemplate();

$tpl->printTemplate(
    'mytemplate.tpl',
    array(
            'sort_thumbs' => $sort,
            'sort_thumbs_selected' => $settings['sort_thumbs']
    )
);

Edit: Mein Hauptproblem ist wohl, daß ich deutlich besser programmieren als Doku schreiben kann. Ich packe immer möglichst alle Fähigkeiten der Module in die Doku, wie etwa die Möglichkeit, das Sprachmodul zu initialisieren und dem Konstruktor zu übergeben. Dabei unterschlage ich, daß es natürlich auch viel viel einfacher geht, wenn man das nicht braucht oder will. Obiges Beispiel funktioniert genauso und lädt sogar die richtigen Sprachdateien automatisch, wenn sie im Standardverzeichnis liegen. Muß wohl mal die Doku neu schreiben...

[doc]

@Webbird: Da warst du schneller, wollte gerade mal das Beispiel von Thorn in der Syntax Deiner lib posten

Ach ja. Typolight verwendet übrigens einen ähnlichen Ansatz wie Thorn. Templates enthalten PHP Code, was keine Einarbeitung in eine weitere "Pseudo Sprache" notwendig macht, bei kleinen Aufgaben nicht wirklich unübersichtlicher ist als mit "Pseudo-Konstrukten" und den Vorteil hat, dass "prinzipiell" alles möglich ist, was auch mit PHP Möglich ist. Der Nachteil ist halt der dass doch wieder PHP und HTML gemischt wird, wenn auch nur für Sachen wie Loops etc.

Doc

[WebBird]

Ich denke, aus Sicht von WB wäre eine Umstellung auf Savant3 (oder eben ein angelehntes eigenes Modul) gegenüber phpLib tatsächlich ein Quantensprung.

[Stefek]

... den Vorteil hat, dass "prinzipiell" alles möglich ist, was auch mit PHP Möglich ist. Der Nachteil ist halt der dass doch wieder PHP und HTML gemischt wird, wenn auch nur für Sachen wie Loops etc.

Das muß an sich kein Nachteil sein.
Anders als vor etwa 10 Jahren noch, als die ersten Template Engines sich etablierten, beherrscht der Designer heute zumindest rudimentäres PHP, weil er sonst kein Produkt bekommen würde.
Und ehrlich gesagt, ist es mir ziemlich egal, ob ich da Pseudokostrukte verwende oder reines PHP.
Fürs Frontend Beispielsweise verwende ich in den Templates am liebsten direktes PHP (ohne die ganzen xfast super libs), einfach, weil man auch im Body der Templates mit vorangestellten (oder excludierten) Variablen arbeiten kann. Das sorgt für mehr Überblick.

[Stefek]

Ich denke, aus Sicht von WB wäre eine Umstellung auf Savant3 (oder eben ein angelehntes eigenes Modul) gegenüber phpLib tatsächlich ein Quantensprung.

Stimme ich voll mit überein.

Und dann müßte es eben etwas sein, was sowohl für den Coder als auch den Designer gut ist.

Bei den Ansätzen hierfür die Thorn hat, finde ich das ganzheitliche Konzept gut.
Ich meine, dass man das auch in den Layout Feldern (unter Settings meist) der Module selbst verwenden und somit einiges an Logik hineinbringen kann.

Dass es auch mit anderen Ansätzen ginge ist kein Thema.

EDIT: mehr Logik in den Layout Feldern könnte ich mir in vielen meiner Lieblingsmodule gut vorstellen. Nicht zuletzt News, Members oder oder..

Gruß,
Stefek

[WebBird]

Kannst Dir ja mal Savant3 angucken. Nur mal zum Vergleich.

http://phpsavant.com/yawiki/index.php?area=savant3

Edit: Der hier ist besser -> http://phpsavant.com/docs/

[Stefek]

Hallo,
nein,
ich bin nicht im Entwicklerteam.

Ich kenne Savant3 schon. Du hast es bereits an einer anderen Stelle erwähnt gehabt.

Ich habe mich schon genug über die (un)Logik von phpLib geäußert und dass sie "rausgeklopft" werden sollte.
Dass es nicht von heut auf morgen geht, und dass sie eine weile "mitziehen" muss (wie z.B. auch die Kack UI), ist klar.

Gut wäre es einfach, wenn man einer die ganzen Ansätze durchgeht und sich auf eine Sache einigt.

Ob es Savant3, xFastschrimmpack oder GummGimmOldstyle ist, ist mir Gimmick.

Das müßte doch langsam rübergekommen sein?

//Edit: Hauptsache praktisch und dass die Multilanguage Geschichte einfach gehandhabt ist, sodass man während der Entwicklung nicht ständig alles zur Entwicklungszeit gegeneinander angleichen muss (in allen Lang Files).

Gruß,
Stefek

[Stefek]

Hallo Bianka,

nein, nein.
Ich fühle mich nicht angegriffen - im Gegenteil.

Ich finde die Entwicklung der "Debatte" gar nicht schlecht - bis auf die Tatsache, dass Michael einen auf Moses macht und es in Zwei geteilt hat. 

Ansonsten ist es so, dass ich seit langem eine vernünftige und praktische Methode für WB ersehne.
Was da rein kommt, entscheide ich aber nicht.
Für mich ist die hauptsache, dass es praktisch ist.

PMF ist ja an sich mehr als nur ... und verfolgt bestimmte Zwecke.
Aber der Wert einer solchen einfachen Handhabung wird um so deutlicher, wenn man einmal mit logischen Templates gearbeitet hat.

Vielleicht kommt es so ein wenig rüber, als würde ich jetzt für Thorn und seine Herangehensweise "Partei ergreifen".
Nun, ist irgendwie was dran, kann ich nicht leugnen.
Aber nur, weil ich mich schon damit mehr vertraut habe.

Aber ich trenne ganz klar meine persönlichen Wünsche von allgemeiner Notwendigkeit.

Wenn es so wäre, dass ich jeden meiner Wünsche in WB drin haben wollte, müßte ich einen Fork bauen.
Doch dazu fehlt mir die Zeit, die Kenntnis und der Aufwand würde den Nutzen nicht rfertigen.

Es ist auch eine Sache des Publikums und der Menge an Entwicklern.

Für mich ist es also viel einfacher, an Entwickler zu plädieren, als das ganze selbst zu entwickeln und meinen Teil woanders beizutragen - wie z.B. beim Bau von Modulen oder sonst wo.

Fakt ist, dass viele Module einer Überarbeitung bedürfen.
Guidelines werden vielleicht erstellt, doch dann beziehen sie sich wieder auf die phpLib Gurke, wenn es um Templates geht und auch die Mehrsprachigkeit bleibt verworren wie sie ist.

Die Sache ist die:
Du hast mehr Einblick,
Du bist im Dev Team.

Aber obwohl diese Sachen lange bekannt sind, tut sich da nicht viel auf diesem Gebiet.

Und deswegen finde ich diesen Thread gut.

Man sieht auch, wie effektiv die einzelnen Entwickler an einander vorbeidenken, statt am selben Strang zu ziehen, nach dem der Knoten daraus ist, scheint es, als würde der Knoten immer fester und mit immer mehr Schleifen  versehen.
Nicht nur im Dev Bereich.

Bewundernswert.
So viel Power, wie man darauf aufbringt.

Und sag mir nicht, dass nicht auch Du etwas Radikales im Blut hast 

Ich mag viele von Euch wirklich gut leiden.
Und ich wunder mich sehr.
Ich dachte früher, dass Künstler recht eigensinnig sind - aber Programmierer sind einfach nicht zu toppen... 

LG,
Stefek

[WebBird]

Die Sache ist die:
Du hast mehr Einblick,
Du bist im Dev Team.

Aber obwohl diese Sachen lange bekannt sind, tut sich da nicht viel auf diesem Gebiet.

Aus Gründen der Kompatibilität wird sich da in 2.x auch nichts mehr ändern. Daß sich nichts tut, dem widerspricht dieser Thread. Es tut sich vielleicht nichts _im Core_, und das ist, wie gesagt, auch so gewollt.

Man sieht auch, wie effektiv die einzelnen Entwickler an einander vorbeidenken, statt am selben Strang zu ziehen, nach dem der Knoten daraus ist, scheint es, als würde der Knoten immer fester und mit immer mehr Schleifen  versehen.

Das ist mir zu sehr über einen Kamm geschoren. Thorn ist kein Core-Entwickler, und genau genommen bin ich auch keiner, jedenfalls nicht für 2.x. Im Augenblick sind wir nichts weiter als zwei Individuen, die zufällig ähnliche Ideen haben und diese hier vorstellen.

Und sag mir nicht, dass nicht auch Du etwas Radikales im Blut hast 

Ich bin bekennend radikal. Vor allem spreche ich es auch aus. Aber ich glaube, ich bin auch dafür bekannt, sehr gerne Kooperationen einzugehen. Aber, wie gesagt, im Augenblick sprechen wir über zwei zwar vergleichbare, aber dennoch völlig eigenständige Projekte. Nach Deiner Argumentation müßten sich auch alle CMS-Entwickler zusammentun und das Giga-CMS bauen. Ich denke, da ist jedem klar, daß das Utopie ist. Das hat mit Eigennutz, Stolz oder was auch immer nicht viel zu tun, auch wenn das sicherlich auch immer eine Rolle spielt. (Wobei es da ja schon mit der Programmiersprache losgeht.)

Thorn und ich haben scheinbar grundlegend unterschiedliche Ansichten darüber, ob man etwas in OOP oder prozedural umsetzt. Er mag auch scheinbar meinen Programmierstil nicht. Aber offen gesagt ist mir das auch total wumpe, genauso wie ihm vermutlich (hoffentlich) wumpe ist, ob ich seine Lib mag oder nicht. Wir leben halt nicht in einer perfekten Welt, wo alle an einem Strang ziehen - Gott sei dank! Wo bliebe dann die wunderbare Vielfalt?

[Waldschwein]

Hallo,

 jetzt hab ich doch extra die Themen auseinandergefiesel t, diskutiert halt dann da weiter über Dinge, die nichts mit thorns Modul zu tun haben.  sonst macht bloß wieder jemand dicht...

Gruß Michael

[Stefek]

Das Problem ist eben, dass da noch zu viele gegensätzliche Meinungen über die Entwicklung von 2.x gibt.

Wäre es so, dass da nichts mehr für gemacht wird, dann würde sogar noch ein bisschen Rumforken sich lohnen.   
Zumindest ein eigenes Paket, das man eben für die Projekte so braucht.

Aber wenn es nach mir ginge, würde es kein Giga-CMS werden.

Und ja, sicherlich mag ich gerne die Vielfalt.
Die Erde ist schön vielfältig, aber auch hier gibt es grundlegende "Gesätzmäßigkeiten", wie z.B. die Gravitation.
Dass man trotz dieses Erdanziehungsproble ms immer noch viel vielfalt in der Architektur zum Ausdruck kommen lassen kann, ist aber nicht zu übersehen.

Und Liebe hin Liebe her, oder auch die verschiedenen Programmierstile. Es geht um Ergebnisse.

Du schweifst mir einfach zu sehr vom Thema ab.
Und ich kann einfach sehen, dass Du Dich eher in Deinem persönlichen Stolz mehr gekränkt siehst, als Du zugibst.

Thorn ist ein genialer Programmierer.
Wenn Du sein PMF jetzt schon nicht magst, ohne es gesehen zu haben...  hat das mit Kunst und Disziplin  nichts mehr zu tun, sondern mit "Schutzmaßnahmen".

Gruß,
Stefek

[Stefek]

Das tue ich nicht.

Vom Thema abschweifen, ja.

In erster Linie geht es um PMF.
In zweiter Linie haben wir über eine generelle Herangehensweise im Core gesprochen, wie man denn nun die phpLib Gurke rausklopft.

Schön, dass Du Dir den Quellcode angeschaut hast.

Was ich sehen kann, kann ich sehen. Dass ich es selten anspreche, ist eine andere Geschichte.
Soviel Recht nehme auch ich mir schon raus.

Und nein, ich habe nicht viel mit Deiner Lib gespielt, aber was Du da gezaubert hast mit dem Frontend Template war schon verblüffend.

Was mir einfach zu schade ist, dass Du sagst, Du willst nicht, dass das mal im Core landet.
Wenn Du so davon überzeugt bist, wäre es doch nicht weiter schlimm, sich dafür einzusetzen.
Was spricht dagegen?
Genau: der Knoten.

Jeder für sich glaubt oft, dass er genau DAS Teil jetzt hat und dann wird nicht mehr genau aussortiert.
Drum bildet sich dieser Knoten.

Wenn ich falsch liege, dann hast Du vielleicht eine Erklärung dafür, warum so viele an einander vorbeientwickeln?

[Stefek]

Michael, kann man die hier nicht hingehörenden Beiträge in den anderen Thread verschieben?

Warum immer alles Splitten, das hat der ganzen Unterhaltung mehr geschadet, als geholfen.
Aber los... spielt Mose

[WebBird]

Was ich sehen kann, kann ich sehen. Dass ich es selten anspreche, ist eine andere Geschichte.

Dummerweise siehst Du was, das nicht existiert. Dummerweise willst Du Dich in dieser Hinsicht nicht aufklären lassen. Daß das verletzend ist, weißt Du aber, ja?

Was mir einfach zu schade ist, dass Du sagst, Du willst nicht, dass das mal im Core landet.

Wieder so eine Interpretation. Ich sagte, das ist nicht mein Ziel. Bin ich hier die Einzige, die zwischen "Mitglied im Core Team" und "stinknormaler Entwickler wie jeder andere" eine Trennlinie ziehen kann? Muß ich denn jetzt alles, was ich entwickle, mit dem Ziel entwickeln, daß es im Core landet? Wie krank ist das denn?!?

Wenn Du so davon überzeugt bist, wäre es doch nicht weiter schlimm, sich dafür einzusetzen.

Ich hätte auch kein Problem damit. Ich möchte nur nicht bevorzugt behandelt werden, nur weil ich zufällig im Core Team bin. Auf der anderen Seite habe ich auch kein Problem damit, wenn sich die anderen Mitglieder im Core Team dagegen entscheiden, weil es ihrer Meinung nach etwas Besseres gibt. Ich bin der Meinung, die anderen sind kompetent genug, sich da ein eigenes Bild zu machen, und zu gegebener Zeit werden sie es auch tun. Dann mag wblib ein Thema sein oder nicht. Oder auch PMF. Oder auch Schnutzelwutz. Jetzt ist einfach nicht die Zeit, darüber zu diskutieren.

Ich finde es im Übrigen total verwirrend, daß mir verletzter Stolz vorgeworfen wird, wo ich doch klipp und klar sage, daß ich nicht das Ziel verfolge, daß meine Arbeit im Core landet. Wenn ich jetzt darauf drängen würde, daß das passieren soll, und es würde dagegen argumentiert, dann könnte ich das verstehen. Aber so? Kapier' ich wirklich nicht.

Wenn es soweit ist und die Kernentwicklung von WB NextGen losgeht, wenn da die notwendigen Grundsatzentscheidu ngen getroffen sind, _dann_ werde ich einen selbstkritischen Blick auf wblib werfen und mich entscheiden, ob ich es gegenüber dem Team vertrete oder nicht. Bis dahin muß leider jeder hier mit meiner Entscheidung leben, daß wblib zwar das WB im Namen hat, aber nicht (nur) für WB entwickelt wurde. wblib ist und bleibt eine unabhängige Entwicklung, und ich werde über diesen Punkt auch nicht weiter debattieren.

[Stefek]

Gut, sei es Dir überlassen...

Wie ich sehe, vertrittst Du die Ansicht, dass all die Spreu erst für die NextGeneration vom Weizen abgeklopft werden soll.


Dann viel Erfolg für die Next Generation und ich hoffe, Du wirst mit Deinen Ideen nicht auf verschloßene Ohren stoßen.

Du sollst wissen, dass ich von Deiner Arbeit viel halte.
Die Programmierstile usw. spielen für mich keine große Rolle.
Hauptsache, das alles kann nachvollzogen werden.


Bis es dann soweit ist, ja warum nicht noch ein paar Libs?
Ist doch schick.


Danke für Dein Statement.

[WebBird]

Wie ich sehe, vertrittst Du die Ansicht, dass all die Spreu erst für die NextGeneration vom Weizen abgeklopft werden soll.

Das ist richtig, jedenfalls in Bezug auf phpLib. Hunderte Module bauen darauf auf, da kann man es nicht einfach wegschmeißen. Die Modulentwickler würden die Core-Entwickler lynchen. Bei einem neuen Major-Release dagegen kann man harte Schnitte vorsehen. (Und phpLib dann wiederum als optionales Modul anbieten.)

[Stefek]

Bei einem neuen Major-Release dagegen kann man harte Schnitte vorsehen. (Und phpLib dann wiederum als optionales Modul anbieten.)

Aber das könnte man jetzt ja schon.

Ich habe mich einmal mit Ralf (B) unterhalten und so wie er meinte (oder wenn ich ihn richtig verstanden habe), könnte man auch für ein Next-Gen was schaukeln, dass die gegenwärtigen Module passen.
Kann aber sein, dass es einfach zu lange her war und wir uns über prozedural aufgebaute Module im Allgemeinen unterhalten haben.

Wie dem auch sei.
Ich persönlich gehe davon aus, dass die Vielfalt an WB Modulen nicht einfach so mit einem neuen Release untergehen sollte und dass es da zumindest ein paar leicht zu überwindenden Krücken geschaffen werden sollten (sodass man ein bestehendes 2er Reihe Modul, ohne viel Aufwand umprogrammieren kann).

Für diesen Fall wäre es gut, schon bald mit einem Template/Language Paket aufzuwarten (in der 2er), und die Module nach und nach anzupassen.
Bekanntlich wird es noch an die x Jahre dauern können, bis ein NextGen WB fertig ist.

Wir können doch jetzt nicht so "arbeitslos" da sitzen und auf phpLib weiterhantieren...

Da die WB Lib auch ohne WB läuft, wäre es vermutlich eine der Libs in engerer Auswahl.

Wobei das hier nun wirklich nicht zum Thread passt.

Aber ich denke, Du verstehst was ich meine.

LG,
Stefek

[doc]

Hi,

... den Vorteil hat, dass "prinzipiell" alles möglich ist, was auch mit PHP Möglich ist. Der Nachteil ist halt der dass doch wieder PHP und HTML gemischt wird, wenn auch nur für Sachen wie Loops etc.

Das muß an sich kein Nachteil sein.
Anders als vor etwa 10 Jahren noch, als die ersten Template Engines sich etablierten, beherrscht der Designer heute zumindest rudimentäres PHP, weil er sonst kein Produkt bekommen würde.

Dieser Ansatz gerät nur dann zum Nachteil, wenn entweder zuviel Logik ins Template gepackt wird, oder der "Designer" die Möglichkeiten von PHP für eigene "Codeausgaben" misbraucht. Bei Projekten, in denen man alleine oder in einer kleiner Gruppe arbeitet, ist ne Mischung aus PHP und HTML für kleinere "dynamische" HTML Ausgaben (z.B. Platzhalterersetzun g, Tabellen- oder Listenausgaben aus einem Object, Array etc.) völlig ausreichend. Vorteil, keine neue Programmiersprache, kein zeitaufwändiges "suchen & ersetzen", halt normales PHP + HTML.

Bei grossen Projekten mit vielen Leuten in verschiedenen Teams mit klar festgelegten Aufgabenverteilunge n würde ich dann lieber ne "Templateengine" verwenden, damit z.B. keine unnötigen Sicherheitslücken (PHP ist mächtig) entstehen.

Denke bei Anynews würde der erste Ansatz die Flexibilität des Snippets erweitern. Die include.php wertet die Parameter aus, generiert die MySQL Query, führt die DB Abfrage durch und speichert die "validierten und gefilterten" Ergebnisse in einem Objekt oder Array. Das Template (die View) kann auf alle verfügbaren Datensätze zugreifen und das ausgeben, was gebraucht wird.

Edit:
Ich persönlich verwende z.B. die phpLib, weil sie mit WB einherkommt und ich keine "Modulabhängigkeiten" für meine Module gewollt habe (also nix installier erstm mal a und b dann geht auch c). So schlimm wie einige hier tun, ist die phpLib auch nicht, nur etwas antiquiert und auch etwas langsam. Aber die anderen Lösungen sind auch nicht der heilige Gral

So, denke es wurde nun genug über "Template" Engines geredet. Mich würde mal interessieren welche anderen Funktionen man sinnvoll in eine WBLib zusammenfassen könnte

Doc

[WebBird]

Es gibt mittlerweile 4 (?) Libs, die sich als Module installieren und nutzen lassen. Niemand muß mit der phpLib vorlieb nehmen. Im PEAR-Modul ist sogar Savant3 enthalten, obwohl das eigentlich kein PEAR-Modul ist. Aber ich glaube, wir drehen uns da im Kreis.

Die Entscheidungen bezüglich 2.x oder auch NextGen Core werden woanders getroffen, nicht hier. Wobei es da bekanntlich jedem frei steht, ein Feature-Request-Ticket aufzumachen und z. B. die Integration einer "besseren" (=einfacheren, flexibleren, whatever) Template Engine in den Core zu fordern.

Auch den NextGen Entwicklern ist klar, daß man nicht alle vorhandenen Module über Bord schmeißen kann und darf. Deshalb sagte ich ja, daß man beispielsweise phpLib dann als "normales" Modul mitliefern könnte, so daß es weiterhin verfügbar ist. Aber das ist nur eine Möglichkeit von vielen, und auch das wird woanders besprochen und entschieden.

In Sachen Template wäre auch die Integration der (gleichermaßen geliebten wie gehaßten) Smarty Engine denkbar. Aber auch das... (siehe oben)

Immerhin, angeregt durch die Debatte habe ich angefangen, die wblib Doku zu überarbeiten. Diesmal gleich in Englisch. Wer mag -> http://www.webbird.de/wblib/en

Vielleicht (hoffentlich) sind jetzt ein paar Dinge verständlicher beschrieben. Ansonsten stehe ich für Fragen und Anregungen zur Verfügung.

Zurück zum Thema: Meine persönliche Wunschliste ist lang. Das ist ja mit ein Grund, warum es wblib gibt. Ein paar Dinge, die es dort nicht gibt (und auch nicht geben wird), die ich mir wünschen würde:

* Eine einfache Methode, den WYSIWYG-Editor in Modulen zu verwenden
* Eine zentrale Dateiupload-Funktion
* ... äh ... hab den Faden verloren *g*

[Stefek]

Hallo Bianka,

Die Entscheidungen bezüglich 2.x oder auch NextGen Core werden woanders getroffen, nicht hier. Wobei es da bekanntlich jedem frei steht, ein Feature-Request-Ticket aufzumachen und z. B. die Integration einer "besseren" (=einfacheren, flexibleren, whatever) Template Engine in den Core zu fordern. Wink

Das kann nicht Sinn und Zweck sein...
irgendwie hast Du meine ganzheitliche Idee hinter dem letzten Beitrag nicht gekriegt...

Auch den NextGen Entwicklern ist klar, daß man nicht alle vorhandenen Module über Bord schmeißen kann und darf. Deshalb sagte ich ja, daß man beispielsweise phpLib dann als "normales" Modul mitliefern könnte, so daß es weiterhin verfügbar ist. Aber das ist nur eine Möglichkeit von vielen, und auch das wird woanders besprochen und entschieden.

Eben nicht als Modul.
Die YUI ist immer noch im Include Ordner, obwohl sie als deprecated gilt.
Aber sie muss da halt noch drin stecken, weil noch einiges von ihr abhängt.
Die 35kB phpLib auf deprecated gesetzt...

Als Beispiel: Der Addon File Editor ist eines der meist eingesetzten Admin-Tools.
Frage an Doc: wenn eine logischere Template Engine im Core steckte, würdest Du dann immer noch auf phpLib rumwursteln? Ich glaube kaum, da es wenig effizient und sehr verlangsamend ist - selbst wenn man sehr vertraut damit ist, hat es seine grenzen.
Also wäre ein besseres "Toolkit", wie Martin es hübsch umschreibt, sinnvoll.
Vor allem wenn es mit Rücksichtnahme auf spätere Implementierung der Module in xGenWB geschieht.


Gruß, Stefek

[WebBird]

ich fände ne Datenbankabstraktio n nicht schlecht, um verschiedene Datenbanken mit einer einheitlichen Syntax nutzen zu können (wie z.B. SQlLite etc.).

Steht auch ganz oben auf meiner Wunschliste, aber ich hab es nicht genannt, weil es eine größere Baustelle ist, die man erst mit NextGen angehen sollte. Stichwort PDO.

[doc]

Hi,

Als Beispiel: Der Addon File Editor ist eines der meist eingesetzten Admin-Tools.
Frage an Doc: wenn eine logischere Template Engine im Core steckte, würdest Du dann immer noch auf phpLib rumwursteln?

Ja. In AFE werde ich wohl keine "neuen Features" mehr einbauen, ausserdem sollen alle WB Versionen ab WB 2.7 ohne weitere "Eingriffe" unterstützt werden. Der Nachfolger csFileManger braucht hingegen keine phpLib und ist objektorientiert programmiert

Denke mein letztes Statement zu "Template Engines" in diesem Thread

Doc

[Stefek]

Hi,

Als Beispiel: Der Addon File Editor ist eines der meist eingesetzten Admin-Tools.
Frage an Doc: wenn eine logischere Template Engine im Core steckte, würdest Du dann immer noch auf phpLib rumwursteln?

Ja. In AFE werde ich wohl keine "neuen Features" mehr einbauen, ausserdem sollen alle WB Versionen ab WB 2.7 ohne weitere "Eingriffe" unterstützt werden.

Du hast meine Frage nicht verstanden.
Es war eine theoretische Frage.
Wenn von vornherein eine logischere TplEngine drin wäre, hättest Du wohl eher nicht auf phpLib gesetz, oder?

[doc]

Hi,

Du hast meine Frage nicht verstanden.

Naja, Du hast sie nicht vernünftig formuliert. Die Frage im zweiten Ansatz hätte ich sofort verstanden
Neue Antwort brauchts trotzdem nicht, da bereits beantwortet (Abwärtskombatibilität) und csFileManager.

Doc