WebsiteBaker Community Forum
WebsiteBaker Support (2.8.x) => 
Hilfe & Support (deutsch) => General Help & Support => Diskussion über WB (closed) => Topic started by: Stefek on August 13, 2012, 05:12:03 PM
-
Hallo,
Norbert (User NorHei) hat mich auf eine interessante Idee gebracht.
Er hat in seinem privaten Derivat den Core so umgebaut, dass Admin-Tools eine include.php mitbringen können und dass diese include.php Dateien genau so verarbeitet werden wie eigenständige Module vom Typ Snippet.
Das ist eine gute Idee und ich würde es gut finden, wenn es so etwas fest in WebsiteBaker gäbe.
Man könnte es auch so machen, dass die include.php Dateien in Page-Type Modulen integriert werden können.
Gruß,
Stefek
-
Ich würde ja eher die Snippets komplett abschaffen.
-
Übrigens möchte ich noch zu bedenken geben, daß WB die include.php's der Snippets blind einbindet, egal ob sie auf der Seite gebraucht werden oder nicht. (Kann der Core ja auch nicht wissen.) Drum bin ich auch gegen allzu viele Snippets. Da wird dann viel unnötiger Ballast geladen.
-
Übrigens möchte ich noch zu bedenken geben, daß WB die include.php's der Snippets blind einbindet, egal ob sie auf der Seite gebraucht werden oder nicht. (Kann der Core ja auch nicht wissen.) Drum bin ich auch gegen allzu viele Snippets. Da wird dann viel unnötiger Ballast geladen.
Ja, diese Problematik ist bekannt.
Ich könnte mir auch ein alternatives System vorstellen, welches Funktionen anderweitig zur Ausführung bereitstellt und vielleicht mit Droplets kombiniert.
An was hättest Du da gedacht?
-
Snippets im herkömmlichen Sinn werden sehr bald Vergangenheit sein.
(@Bianka: die blinde Laderei ist tatsächlich unsäglich)
Der zukünftige Ersatz für die 'Snippets' werden spezielle Klassendateien sein. In Verbindung mit dem Autoloader werden dann wirklich nur noch die Dateien geladen, die auf der jeweiligen Seite auch tatsächlich benötigt werden.
Dann heist's beispielsweise anstelle von <?php anynews(....); ?> eben <?php m_AnyNews_View::show(....); ?> oder <?php \vendor\AnyNews\View::show(....); ?> je nachdem ob bis dahin echte oder emulierte Namespaces im Einsatz sind.
-
Das hört sich schon mal gut an.
Aber: wann wird es soweit sein?
Bald (und auch "sehr" bald) sind dehnbare Begriffe.
Es scheint, als würde die Entwicklung still stehen und da kommt der eine oder andere auf "neue Ideen" (falls Du verstehst, was ich meine).
Zusätzlich zum Technischen:
es werden ja im Moment noch die CSS Dateien der Snippets automatisch geladen.
Wird es bald eine neue Methode geben, CSS in den Head zu schreiben, oder wie?
Die gegenwärtige funktion "CSS to Head Filter" ist nicht gut genug. Sie schreibt die CSS Files direkt vor dem Body End-Tag.
Aber manchmal muss diese CSS Datei VOR Javascripten geladen werden, sonst wird das Javascript zerschoßen (kommt z.B. bei einigen jQuery Plugins vor).
Gruß,
Stefek
-
Das hört sich schon mal gut an.
Aber: wann wird es soweit sein?
Das wird bereits ab der 2.8.4 funktionieren. Eine Erklärung, wie das genau funktioniert stelle ich dann rechtzeitig online.
Es scheint, als würde die Entwicklung still stehen und da kommt der eine oder andere auf "neue Ideen" (falls Du verstehst, was ich meine).
Seit heute sind die Ferien vorbei und meine Frau 'darf' wieder arbeiten. Folglich bleibt auch mir jetzt wieder deutlich mehr Zeit. ;-)
Ich selbst hab die Ferien über erst mal wieder 'Windeln wechseln' geübt... bei meiner jüngsten Enkeltochter. :-D Da blieb für WB verständlicherweise nicht allzuviel Zeit übrig.
Zusätzlich zum Technischen:
es werden ja im Moment noch die CSS Dateien der Snippets automatisch geladen.
Wird es bald eine neue Methode geben, CSS in den Head zu schreiben, oder wie?
Die gegenwärtige funktion "CSS to Head Filter" ist nicht gut genug. Sie schreibt die CSS Files direkt vor dem Body End-Tag.
Aber manchmal muss diese CSS Datei VOR Javascripten geladen werden, sonst wird das Javascript zerschoßen (kommt z.B. bei einigen jQuery Plugins vor).
Da muss ich Dich/Euch leider noch etwas vertrösten. Es steht eine Menge Arbeit auf der Liste. Nur alles gleichzeitig schaffen wir nicht.
-
Schön, freut mich zu hören.
Da muss ich Dich/Euch leider noch etwas vertrösten. Es steht eine Menge Arbeit auf der Liste. Nur alles gleichzeitig schaffen wir nicht.
Na, keiner erwartet Zauberkünste. Reicht, wenn man sieht, dass sich was tut.
2.8.4. bald wäre echt gut.
Gruß,
Stefek
-
Zum Thema CSS gibt es hier im Forum eine uralte Lösung von Aldus. Ansonsten könnte man auch beim ungeliebten Fork abgucken. *hüstel* Ist nicht sooo schwierig. :-D
Das Verfahren ist in der Tat simpel: Anstatt erst in page_content() nachzugucken, welche Module auf der Seite eingebunden sind, tut man es schon bei page_header() oder einer analogen Funktion. Diese kann dann alle CSS, JS und whatever einsammeln.
Dazu eine nette kleine Konfigdatei für dynamische Header, und fertig.
-
Zum Thema CSS gibt es hier im Forum eine uralte Lösung von Aldus. Ansonsten könnte man auch beim ungeliebten Fork abgucken. *hüstel* Ist nicht sooo schwierig. :-
Das Teil von Aldus kenne ich wohl nicht und wenn es das ist, was ich meine, dann tut es nicht das, was mir vorschwebt.
Den Fork selbst habe ich nie heruntergeladen. (Warum in die Ferne schweifen, wenn das Gute ist so nah?)
Aber auch Thorn hatte mit seinem OpF Dashboard eine Funktion bereitgestellt, die CSS/JS an die gewünschte Position gebracht hat.
An sich hätte ich kein Problem mit der jetzigen Brüselfunktion des Filters. Man müßte nur ausklügeln, dass die CSS Files vor den JS Files im Head geschrieben werden.
Und ein zusätzliches Makro/Droplet, um gewünschte CSS/JS Files auch aus Templates heraus nachzuladen (aus den jetzigen, sogenannten Layoutfields der Module - Du weißt schon, MeinSectionModul/Settings/Layout; oder in Modultemplates die mit einer TE ausgegeben werden).
Die header.php Datei, die Du BB schon mal beschrieben hast, ist zwar OK, aber man müßte die auch noch mit der DB koppeln, sodass man Files über das Backend des Moduls angeben kann (wenn z.B. ein CSS File nur für eine bestimmte Section/Seite vorgesehen ist - da will ich dann nicht in der PHP Datei rumfummeln müßen).
Das ganze wird dann too much.
Das ganze ist nicht als Kritik gemeint. Mir ist es ziemlich egal wer sich wie was zurechtgabelt.
Wichtig ist, dass die Funktion/Methode leicht zu gebrauchen ist und auch korrekt eingesetzt werden kann.
In meiner Analyse ist es IMMER CSS Dateien vor den JavaScripts.
Gruß,
Stefek
-
"Immer CSS vor JS" macht LA, aber das ist auch nicht immer richtig. Sagen jedenfalls die User.
Nachträgliches Herumschieben von Dateien, die eigentlich in den Header gehören, ist Mumpitz. Im Moment macht "man" es so, weil es nicht anders geht, aber es bleibt trotzdem Mumpitz. Drum wäre ein Output Filter IMHO auch der falsche Ansatz.
Seitenbasierte CSS/JS sind auch sehr leicht zu lösen, ganz ohne DB und Backend. Wozu hat 'ne Seite 'ne ID? ;)
Ich glaube, Ihr denkt einfach alle viel zu kompliziert. :-D
Edit: Den Fork selbst habe ich nie heruntergeladen. (Warum in die Ferne schweifen, wenn das Gute ist so nah?)
Wäre auch erst in Version 2.0.
-
Auch wenn es eigentlich OT ist, nochmal der Ansatz:
* Header-Lade-Funktion (Name egal) ermittelt die Liste der zu ladenden Module (macht jetzt page_content(), da isses für den Header zu spät)
* Funktion sucht je nachdem frontend.css/backend.css bzw. frontend.js/backend.js
* Funktion sucht im pages-Verzeichnis (bevorzugt mit Unterverzeichnis "css" bzw. "js") und/oder Template-Verzeichnis nach <PAGE_ID>.css und <PAGE_ID>.js
* Funktion schmeißt das Ergebnis raus, von mir aus sortiert nach erst CSS dann JS
SEHR einfach. Brauchst Du seitenbasiertes CSS? Legst Du <PAGE_ID>.css hin, bissu fertig. Nix Gefummel in PHP, nix Einstellung im Backend, einfach Datei hinlegen und das war's. Desgleichen für JS.
Kann man bei PmWiki abgucken. ;)
-
Hallo BiBi
SEHR einfach. Brauchst Du seitenbasiertes CSS? Legst Du <PAGE_ID>.css hin, bissu fertig. Nix Gefummel in PHP, nix Einstellung im Backend, einfach Datei hinlegen und das war's. Desgleichen für JS.
Das ist nicht komfortabel genug.
Was, wenn ich das gleiche CSS File bei PAGE_ID == 15 und 18 und vielleicht auch noch 23 brauche?
3 mal hochladen ist 2 mal zu viel. Und überdies entfällt dann die Möglichkeit des Cachens dieser Datei.
Zu früh zu spät ist eigentlich kaum ein Thema, da wir ohnehin mit dem Buffer arbeiten (für Droplets und andere Outputfilter).
Gruß,
Stefek
-
Was, wenn ich das gleiche CSS File bei PAGE_ID == 15 und 18 und vielleicht auch noch 23 brauche?
3 mal hochladen ist 2 mal zu viel.
Unsinn! Einmal das richtige und die anderen mit @import(). :-D
Edit: Zu früh zu spät ist eigentlich kaum ein Thema, da wir ohnehin mit dem Buffer arbeiten
Irgendwo sagte DV, die Bufferung soll eingeschränkt bzw. ganz abgeschafft werden.
-
Irgendwo sagte DV, die Bufferung soll eingeschränkt bzw. ganz abgeschafft werden.
Der soll sich mal nicht zu weit aus dem Fenster lehnen mit seinen Erfindungen :wink:
-
Wieso, wenn er gute Argumente hat...
-
Wenn er Argumente hat.
-
Irgendwo sagte DV, die Bufferung soll eingeschränkt bzw. ganz abgeschafft werden.
So in der Art etwa sagte ich tatsächlich was. ;-)
Genauer:
Generell auf Bufferung verzichten geht nicht, da sonst beispielsweise Dinge wie OutputFilter fast unmöglich würden.
Jedoch wird die Bufferung über die ob_xxxx() Funktionsgruppe zumindest von Seiten des Core step by step abgeschafft. Sie wird durch ein globales View-Objekt ersetzt, das getrennte Queues für z.B. Metatags, CSS, Header-JS, Body-JS, Content usw. usw. hat.
Dadurch kann der Core und auch jedes Modul etc. seine Daten jederzeit in die entsprechende Queue schieben.
Erst am Ende wird dann per ::sendPage() o.ä. alles richtig zusammengesetzt und zum Client geschickt.
So 'Gimmiks' wie PageHeader, seitenbezogenes CSS etc. wird dadurch auch wesentlich einfacher realisierbar.
Ps: CSS-Dateien per PageId einbinden find ich persönlich nicht besonders optimal. Zumindest nicht für die ursprüngliche WB-Zielgruppe. Das hantieren mit derartigen Dateien ist da eher etwas für Leute, die sich etwas besser im System auskennen. Aber ich bin mir sicher, dass wir auch dafür noch eine passende, einfache Lösung finden.
-
Jedoch wird die Bufferung über die ob_xxxx() Funktionsgruppe zumindest von Seiten des Core step by step abgeschafft.
Das heißt aber nicht, dass ich in meinem Billigmodul komplett auf die Verwendung von den PHP eigenen output Funktionen verzichten muss, oder?
Also wenn ich jetzt zum Beispiel Lust hätte, ein Billigmodul zu schreiben, das so etwas tut:<?php
ob_start();
?>
bla bla bla bla
<?php
$dasBlaDesTages = ob_get_contents();
ob_end_clean();
echo $dasBlaDesTages;
?>(Dafür gäbs keine Argumente :x)
Das mit den Queues für verschiedene Bereiche hört sich gut an.
Doch das ist eher für einen komplett neuen WB Zweig angedacht, oder willst Du das noch in der 2.8.x Reihe implementieren?
So 'Gimmiks' wie PageHeader, seitenbezogenes CSS etc. wird dadurch auch wesentlich einfacher realisierbar.
Klar. Aber das ist Zukunftsmusik. Wir kriegen ja nicht mal ein Feld für REWRITE_URL vom Dev Team spendiert (obwohl es seit 5 Jahren gewünscht wird).
-
Ich dachte mit meinem Vorschlag auch eher daran, mich vom Einfachen zum Komplizierten zu bewegen. Das, was ich oben beschrieb, ist mit wenigen Handgriffen in 2.8.3 implementiert. Das kann ich mit Sicherheit sagen, denn ich hab's schon mal gemacht. :-D Stefeks Datenbankvariante wäre dann Schritt 2, _etwas_ komplizierter und aufwendiger, weil man dafür die Seitenadministratio n aufbohren muß, aber immer noch im Rahmen.
Das, was DV beschreibt, ist ein wesentlich tieferer Eingriff. Womit wir wieder bei der Frage wären, WANN denn wohl damit zu rechnen ist. Zumal es schon vor... hm... ist das nicht schon 3 Jahre her? ...eine Ankündigung gab, 2.9 sei "in Kürze" fertig. Ich müßte mal suchen, aber das war im März 2009 oder 2010.
Das mit dem seitenbasierten CSS hab ich übrigens von PmWiki abgeschaut. Das hat nämlich überhaupt keinen Backend-Bereich, da gibt es kein Klicki Klacki. Und die Leute kriegen es trotzdem ganz wunderbar hin. Klar muß man ETWAS mehr mitdenken, als wenn ich bei den Seiteneinstellungen einfach sage "nimm dieses CSS" oder "nimm diese CSS-Datei" - auf der anderen Seite fällt die Datei so oder so nicht vom Himmel. Also kann ich genauso gut sagen "schreib Dein CSS in eine Datei, benenn sie nach der Seite, und kopier' sie in das Template-Verzeichnis, alles andere geht dann automatisch". (Oder ins media-Verzeichnis, da könnte man dann zumindest den integrierten Upload benutzen.) Wo soll da das Problem sein? Genau genommen spar ich mir sogar einen administrativen Schritt.
Aber gut, das ist sicher Ansichtssache, und ich kann nur für meine persönlichen Erfahrungen sprechen. Und die beschränken sich eben nicht nur auf den WB-Benutzerkreis.
-
Erst am Ende wird dann per ::sendPage() o.ä. alles richtig zusammengesetzt und zum Client geschickt.
Das würde dann aber bedeuten, daß auch alle Templates umgeschrieben werden müssen. Richtig?
-
da gibt es kein Klicki Klacki.
Ohne Klicki Klacki entfernen wir uns von "einfach".
Warum nicht die CSS mit Klick anlegen und sogar öffnen vom Backend aus, ala LA?.
SEO-technisch werden viele einzelne CSS-Dateien allerdings angemeckert.
-
Wie ich schon sagte, ich wollte mich mit meinem Ansatz vom Einfachen zum Komplexeren - oder von mir aus auch Komfortableren - bewegen. In Phase 1 geht es schon von Hand, in Phase 2 kommt dann das Klicki Klacki Backend dazu. Phase 1 ist dabei relativ wenig Aufwand und läßt sich problemlos auf Basis von 2.8.3 umsetzen. Phase 2 erfordert entweder ein Admin Tool, oder - besser, da passender - ein Aufbohren der Seitenadministratio n.
-
Erst am Ende wird dann per ::sendPage() o.ä. alles richtig zusammengesetzt und zum Client geschickt.
Das würde dann aber bedeuten, daß auch alle Templates umgeschrieben werden müssen. Richtig?
Das hätte mich jetzt echt gewundert, wenn dieser Einwurf nicht gekommen wäre. 8-)
Selbstverständlich sind da bis zum 'Endstadium' einige Anpassungen notwendig, die jedoch gleichzeitig wieder eine deutliche Vereinfachung bringen werden.
Eines der Ziele ist es auch möglichst viel, am besten allen PHP-Code aus den Templates auszulagern und dadurch eine wesentlich übersichtlichere HTML-Struktur der Templates zu erhalten. Die aktuellen Templates sind für Nichtprofis durch die teilweise extreme Vermengung von HTML-/PHP- und auch JS-Code inzwischen so unübersichtlich und teilweise auch 'unbegreifbar' geworden, dass hier dringend eine Vereinfachung notwendig wird.
Die Änderungen beginnen jedoch erst ab der 2.9.x und werden da schrittweise eingeführt, um die bisherigen Templates nicht schlagartig 'aussen vor' zu lassen und gleichzeitig genügend Zeit zur Umstellung zu geben.
Wie ich schon sagte, ich wollte mich mit meinem Ansatz vom Einfachen zum Komplexeren - oder von mir aus auch Komfortableren - bewegen.
Da die 2.8.4 inzwischen so gut wie fertig ist, ist es hier bereits zu spät. Jedoch könnte eine 'Einfachlösung' erst als Patch und dann als Teil eines eventuellen SP1 zur 2.8.4 veröffentlicht werden.
Die 'Komfort-Version' könnte dann bereits Teil der 2.9 werden.
Da die Sommerpause, sprich Ferienzeit langsam überall dem Ende entgegengeht, werden wir die nächsten Wochen sowieso wieder ein DEV-Meeting (Core und Module) anbieten, um die geplante Roadmap für die nächste Zeit vorzustellen und zu erklären.
Im Forenbereich des Addon-Dev-Teams (https://forum.WebsiteBaker.org/index.php/topic,24049.0.html) werden seit einiger Zeit bereits Änderungen veröffentlicht, die Einfluss auf die Modulentwicklung haben und haben können.
-
Das hätte mich jetzt echt gewundert, wenn dieser Einwurf nicht gekommen wäre. cool
Selbstverständlich sind da bis zum 'Endstadium' einige Anpassungen notwendig, die jedoch gleichzeitig wieder eine deutliche Vereinfachung bringen werden.
Dann hab ich noch einen: Es ist durchaus möglich, trotz eines komplett neuen Verfahrens die alten Templates - also das alte Verfahren - kompatibel zu halten. Es erfordert etwas Mehraufwand, aber es ist machbar. Ob es gewollt ist, steht natürlich auf einem anderen Blatt.
-
Das hätte mich jetzt echt gewundert, wenn dieser Einwurf nicht gekommen wäre. cool
Selbstverständlich sind da bis zum 'Endstadium' einige Anpassungen notwendig, die jedoch gleichzeitig wieder eine deutliche Vereinfachung bringen werden.
Dann hab ich noch einen: Es ist durchaus möglich, trotz eines komplett neuen Verfahrens die alten Templates - also das alte Verfahren - kompatibel zu halten. Es erfordert etwas Mehraufwand, aber es ist machbar. Ob es gewollt ist, steht natürlich auf einem anderen Blatt.
Genau,
-
Das 'alte' Verfahren wird sicherlich für einige Zeit (ein paar Releases) kompatibel bleiben, jedoch als deprecated gesetzt werden.
Es ist also sinnvoll, sich für neue Templates dann auch gleich an die dann geltenden neuen Regeln zu halten. Auch für Templates im alten Stil ist es angebracht, sie step by step umzustellen. Auf Dauer wird die vorläufige Kompatibilität nicht beibehalten werden können.
Aber das ist alles noch Zukunft und wird bei der Einführung dann auch entsprechend dokumentiert werden.
-
Und mit wievielen Leuten wolltest Du das System dann noch benutzen?
-
Heißt "kompatibel" dann, daß es unverändert bleibt? Also daß bei alten Templates keine dynamischen Header möglich sind? Oder heißt es, daß die Funktionsnamen gleich bleiben, aber auf das gestreamte Zeugs zugreifen? (So würde ich es machen.)