[tx_less] LESS CSS und konfigurierbare Themes

[soletan]

Hallo,

ich erlaube mir, an dieser Stelle meine gestern veröffentlichte Extension tx_less anzukündigen, natürlich in der Hoffnung, Erfahrungsberichte zu sammeln. Die Woche Arbeit soll sich wenigstens dadurch auszahlen, dass mancher auch einen Nutzen in der Extension sieht.

Mehr zu: LESS CSS

[MiTsch]

Hallo soletan,

sicherlich eine wertvolle Erweiterung und eine Menge Arbeit, ich hab mir natürlich auch deinen Link angesehen, aber leider hab ich noch nicht ganz verstanden was man damit anstellen kann.

Die Woche Arbeit soll sich wenigstens dadurch auszahlen, dass mancher auch einen Nutzen in der Extension sieht

Es wäre doch schade wenn Du da ne Menge Arbeit reingesteckt hast und die Erweiterung findet nicht die gebührende Beachtung!

Um mal Rocky III zu Zitieren "Was machtes ?" Blaues Licht?

Vielleicht könntest Du ja hier eine kurze Beschreibung posten.
Oder gibts dazu eine Beispielseite?


Viele Grüße
MiTsch

[soletan]

Hallo MiTsch,

da es sich um eine Backend-Erweiterung handelt, sind Demoseiten auf die schnelle schwer zu bieten. Es sind jedoch Handbuchseiten vorhanden, die zumindest umreißen, wie man die Extension nutzen kann.

Ein Kernziel ist die Unterstützung für LESS CSS ... was man damit anfangen kann, sollte bereits die von dir verlinkte Site erklären können: CSS-Code sparen, weil man Regeln verschachteln kann. Das ist aber nur der geringste Vorzug. Wesentlicher wichtiger ist der Vorzug, generell CSS-Regeln parametrisieren zu können. Dazu stehen Variablen, Farbberechnungsfunktionen und eine einfache Arithmetik zur Verfügung.

Der Gewinn: man legt statt CSS-Dateien eine LESS-Datei an. Diese definiert einen Parameter wie "Seitenbreite", den du mit der Erweiterung konfigurieren kannst. Wird dieser verringert, so könnten sich abhängig davon auch die Breiten der Seitenspalten, Höhenangaben aufgrund eines definierten Seitenverhältnisses, feste Breitenvorgaben für Formularelemente, oder Thumbnails, Galerien, verringern.

Die Wahl der Hintergrundfarbe könnte auch Einfluss auf die Vordergrundfarbe haben, weil diese als Komplementäre der Hintergrundfarbe definiert ist. Oder durch Nutzung eines "Mixins" für Inhaltsboxen mit abgerundeten Ecken würde ein Parameter genügen, um den Eckenradius aller Boxen auf der Seite zu vergrößern oder zu verkleinern.

Anstatt also für eine Anpassung eines Designs alle Regeln der CSS-Datei(en) abzuarbeiten, genügt es, bspw. 5 Farben und eine Schriftgröße zu definieren, die dann automatisch auf alle Elemente des Designs (Hintergründe, Schriften, Rahmen, Schatten) übertragen werden.

[MiTsch]

Hallo soletan,

Danke für die schnelle und informative Antwort. Jetzt hab ich auch das Aha-Erlebnis!
Und nun macht die Überschrift für mich auch Sinn: The dynamic stylesheet language.

Das heißt also, es sind salopp gesagt verschachtelte "CSS-Anweisungen in Abhängigkeit zueinander" die sich in etwa so verhalten wie z.B. eine komplex verknüpfte Kettenrechnung in einer Exceltabelle.
Ändere ich ein Ausgangswert so findet automatisch eine neue Berechnung statt und alle Ergebnisse werden entsprechend angepasst.

Tolle Sache! Wie kam es zur Entwicklung dieser Erweiterung?


Viele Grüße
MiTsch

[soletan]

Hallo MiTsch,

deine Ausführungen treff "salopp" zu. Zwar fehlen noch einzelne Features, um komplett die CSS-Möglichkeiten in Contao vollständig nachzuempfinden (Stichwort: bedingte Einbindung), doch auch darum würde ich mich in naher Zukunft noch kümmern. Die Motivation zur Erweiterung entstand u.a. aus der Tatsache, dass ich über LESS gestolpert bin und im Grunde etwas derartiges schon immer gesucht habe. Denn auch wenn man mit CSS das Design einer Site leichter adaptieren kann, wird man doch mitunter irre, wenn man bspw. bestimmte Signalfarben oder CD-Farben immer wieder auf neue Elemente anwenden muss.

[tril]

Hallo soletan,

zuerst eine kleine Fehlermeldung die Auftritt, wenn ich das erste mal auf den L-Button klicke bzw. eine Datei verändere:

Warning: array_combine(): Both parameters should have at least 1 element in ../system/modules/tx_less/TXLessRegistration.php on line 177

#0 [internal function]: __error(2, 'array_combine()...', '/home/tristan/p...', 177, Array)
#1 ../system/modules/tx_less/TXLessRegistration.php(177): array_combine(Array, Array)
#2 ../system/modules/tx_less/TXLessRegistration.php(155): TXLessRegistration->updateVariables(Object(TXLessScope), 1)
#3 ../system/modules/tx_less/TXLessRegistration.php(102): TXLessRegistration->addRegistrations(Array, 1)
#4 ../system/modules/tx_less/dca/tl_less.php(113): TXLessRegistration->updateFilesOfTheme(1)
#5 ../system/drivers/DC_Table.php(200): tl_less->updateFilesList(Object(DC_Table))
#6 ../system/modules/backend/Backend.php(173): DC_Table->__construct('tl_less')
#7 ../contao/main.php(101): Backend->getBackendModule('themes')
#8 ../contao/main.php(304): Main->run()
#9 {main}

Ich behaupte jetzt einfach mal, dieser Fehler ist auch dafür verantwortlich, dass ich die Parameter nicht über das BE verändern kann, egal was ich mache. Dein Handbuch konnte mir da leider auch nicht weiter helfen.

---

Nun zum eigentlichen, was ich mich in Bezug auf deinen Code Frage, ist die Frage was für eine Less Implementierung du genommen hast oder die gar selbst geschrieben hast? Ich habe für meine Erweiterung layout_additional_sources (kurz LAS, zukünftig trägt die den Nahmen Theme+) bereits einen Support für less.js eingebaut. Mit Hilfe von Node.js lässt sich das ganze sogar Serverseitig vorkompilieren. Details dazu stehen im Wiki.
Eine PHP Implementierung zu Integrieren ist bisher mangels Zeit auf der Strecke geblieben, wobei es dabei eigentlich nur Notwendig wäre, ein Compression API Minimizer zu bauen, der wiederum eine PHP Implementierung benutzt.

In der Richtung besteht also schon ein modulares System. Vielleicht können wir da zukünftig ein wenig zusammen Arbeiten. LAS besitzt jetzt schon ein paar mehr Features wie z.B. minimieren und vereinigen von CSS Dateien. Individuelle Auswahl der CSS Dateien pro Layout und pro Seite. Und noch ein bisschen mehr.

MfG Tristan

[soletan]

Hallo tril,

danke für die Fehlermeldung. Ich habe die korrekte Reaktion für den Fall mal ergänzt.

Deine Extension lesscss hatte ich durchaus vorab gesehen und kurz geprüft. Ehrlich gesagt hatte die mir in puncto Abhängigkeiten schon zuviel Ballast und die DomainLink-Extension verursachte sonderbare Extrawünsche in meinem Setup, so dass ich froh war, sie wieder los zu sein. Auch die Compression von CSS scheint mir nicht implizit teil der Idee zu sein, LESS einsetzen zu wollen. Natürlich birgt die Kompression von CSS weiteren Bandbreitengewinn, sollte aber IMHO optional bleiben.

Abgesehen davon basiert meine grundlegende Less-Unterstützung auf der less.js von lesscss.org. Dort habe ich natürlich auch die serverseitige Option zur Kenntnis genommen. Einer meiner nächsten Schritte wäre daher die optionale Paarung mit einer serverseitigen LESS-Verarbeitung, etwa um das Erfordernis von JavaScript zu umgehen. Ich stieß auch auf einen lessphp-Parser, der aber syntaktisch von der lesscss.org-Lösung abweicht und darum nicht zum Einsatz kam.

Weiterhin denke ich aber auch, dass die eigentliche Funktionalität, die ich mit meiner Extension angestrebt hatte, eine andere war. Ich nutze neben less.js noch einen eigenen Parser, der die LESS-Dateien analysiert und nur die für mich interessanten Stellen herausextrahiert, damit man sie bei Bedarf anpassen kann - konkret sind dies ///-Kommentare und Variablendefinitionen. Erst wenn du diese in vorhandenen LESS-Dateien, welche sich in den Ordnern eines Themes befinden, einsetzt, erst dann kannst du die Optionen sehen. Die Tatsache, dass du die Warnung erhalten hast, zeigt mir, dass in deinem Setup keine LESS-Dateien mit passenden Definitionen gefunden wurden.

Und auch eine Auswahl der "Stylesheet-Vorlagen" je Seitenlayout ist schon als Funktion enthalten. Ich habe das ganze erst einmal losgelöst von der gesamten CSS-Apparatur in Contao umgesetzt.

Gegen eine Zusammenarbeit habe ich natürlich auch nichts. BTW: Der Parser, den ich serverseitig einsetze, ist weitgehend unabhängig von meiner Extension nutzbar. Er dürfte sogar mit winzigen Handgriffen ohne Contao arbeiten.

[tril]

Deine Extension lesscss hatte ich durchaus vorab gesehen und kurz geprüft. Ehrlich gesagt hatte die mir in puncto Abhängigkeiten schon zuviel Ballast und die DomainLink-Extension verursachte sonderbare Extrawünsche in meinem Setup, so dass ich froh war, sie wieder los zu sein.

Wie muss ich denn verursachte sonderbare Extrawünsche verstehen? Durch den Einsatz von DomainLink sollte eine Installation auch ohne zusätzliche Konfiguration genau so funktionieren wie vor der Installation.

Auch die Compression von CSS scheint mir nicht implizit teil der Idee zu sein, LESS einsetzen zu wollen. Natürlich birgt die Kompression von CSS weiteren Bandbreitengewinn, sollte aber IMHO optional bleiben.

Teil der Idee von LESS meinst du? LESS selbst verfügt über einen Komprimierungsparameter. Das dann erzeugt CSS ist deutlich kleiner, als das reguläre CSS.

Abgesehen davon basiert meine grundlegende Less-Unterstützung auf der less.js von lesscss.org. Dort habe ich natürlich auch die serverseitige Option zur Kenntnis genommen. Einer meiner nächsten Schritte wäre daher die optionale Paarung mit einer serverseitigen LESS-Verarbeitung, etwa um das Erfordernis von JavaScript zu umgehen.

Ok ich muss gestehen, aufgrund des Fehlers hatte ich nicht genauer nachgeschaut, was denn letztlich in die Seite eingebunden wird. Benutzt du die ClientSide JavaScript Version?

Ich stieß auch auf einen lessphp-Parser, der aber syntaktisch von der lesscss.org-Lösung abweicht und darum nicht zum Einsatz kam.

Das war auch ein Grund, warum ich lessphp bisher nicht integriert hatte obwohl ich mal kurz davor stand...

Weiterhin denke ich aber auch, dass die eigentliche Funktionalität, die ich mit meiner Extension angestrebt hatte, eine andere war. Ich nutze neben less.js noch einen eigenen Parser, der die LESS-Dateien analysiert und nur die für mich interessanten Stellen herausextrahiert, damit man sie bei Bedarf anpassen kann - konkret sind dies ///-Kommentare und Variablendefinitionen. Erst wenn du diese in vorhandenen LESS-Dateien, welche sich in den Ordnern eines Themes befinden, einsetzt, erst dann kannst du die Optionen sehen. Die Tatsache, dass du die Warnung erhalten hast, zeigt mir, dass in deinem Setup keine LESS-Dateien mit passenden Definitionen gefunden wurden.

Ich hatte eine .less Datei mit eben solchen ///-Kommentaren gebaut und Variablen die ich nach deiner Beschreibung versucht habe zu dokumentieren. Ich habe das File jetzt leider nicht mehr, da ich die Installation schon "bereinig" habe :/

Und auch eine Auswahl der "Stylesheet-Vorlagen" je Seitenlayout ist schon als Funktion enthalten. Ich habe das ganze erst einmal losgelöst von der gesamten CSS-Apparatur in Contao umgesetzt.

Eingreifen ist auch nahezu unmöglich, wenn man nicht den Core überarbeiten will.

Gegen eine Zusammenarbeit habe ich natürlich auch nichts. BTW: Der Parser, den ich serverseitig einsetze, ist weitgehend unabhängig von meiner Extension nutzbar. Er dürfte sogar mit winzigen Handgriffen ohne Contao arbeiten.

Wenn ich dich richtig verstanden habe ist der Parser aber eigentlich kein LESS Parser sondern viel mehr ein Precompiler und geparsed wird mittels less.js auf Client Seite?

[soletan]

Wie muss ich denn verursachte sonderbare Extrawünsche verstehen? Durch den Einsatz von DomainLink sollte eine Installation auch ohne zusätzliche Konfiguration genau so funktionieren wie vor der Installation.

Das kann ich jetzt auch nicht mehr nachvollziehen. Ich hatte eine saubere Contao-Installation aufgesetzt und die lesscss installiert. Im Anschluss daran wurde ich beim Speichern einer Maske (würde meinen, es war tl_setting) angehalten, was auszufüllen, was ich vorher nicht ausfüllen musste. Das stieß mir nur negativ auf und ich hatte spontan die Verbindung zu DomainLink gebaut. Mag ungerechtfertigt gewesen sein, doch erschloss sich mir nicht diese Kette von Abhängigkeiten ... darfst du dennoch ignorieren

Ok ich muss gestehen, aufgrund des Fehlers hatte ich nicht genauer nachgeschaut, was denn letztlich in die Seite eingebunden wird. Benutzt du die ClientSide JavaScript Version?

Ja, aktuell existiert ein Hook, der in Seiten mit Layouts, für die mindestens eine LESS-Datei aktiviert wurde, automatisch die less.js und alle aktivierten, serverseitig aber potenziell überarbeiteten LESS-Dateien einbindet. Die Alternative wäre nun, dort auf Wunsch auch die LESS-Dateien auf dem Server in minimiertes CSS zu konvertieren.

Wenn ich dich richtig verstanden habe ist der Parser aber eigentlich kein LESS Parser sondern viel mehr ein Precompiler und geparsed wird mittels less.js auf Client Seite?

Die Auslieferung und Konvertierung in CSS erledigt less.js beim Client. Allerdings brauche ich serverseitig ja die Kommentare und die Variablen. Dafür habe ich einen serverseitigen Parser geschrieben, der LESS-Dateien parst, jedoch nur soweit wie es nötig ist, um die gewünschten Informationen zu finden, zu extrahieren und gegebenenfalls zu überschreiben. Insofern sind bei meiner Extension schon jetzt zwei Parser im Spiel.

[tril]

Das kann ich jetzt auch nicht mehr nachvollziehen. Ich hatte eine saubere Contao-Installation aufgesetzt und die lesscss installiert. Im Anschluss daran wurde ich beim Speichern einer Maske (würde meinen, es war tl_setting) angehalten, was auszufüllen, was ich vorher nicht ausfüllen musste. Das stieß mir nur negativ auf und ich hatte spontan die Verbindung zu DomainLink gebaut. Mag ungerechtfertigt gewesen sein, doch erschloss sich mir nicht diese Kette von Abhängigkeiten ... darfst du dennoch ignorieren

Ich tippe eher auf eine nicht gesetzte Administrator-E-Mail-Adresse, da falle ich jedes mal wieder drauf herein, wenn ich meine Entwicklungsinstanz bereinige.
Denn weder DomainLink noch die compression-api noch lesscss erzeugen Pflichtfelder in den Systemeinstellungen.

Ja, aktuell existiert ein Hook, der in Seiten mit Layouts, für die mindestens eine LESS-Datei aktiviert wurde, automatisch die less.js und alle aktivierten, serverseitig aber potenziell überarbeiteten LESS-Dateien einbindet. Die Alternative wäre nun, dort auf Wunsch auch die LESS-Dateien auf dem Server in minimiertes CSS zu konvertieren.

Prinzipiell gehe ich genau den gleichen weg. Nur sind bei mir halt schon ein paar mehr Funktionen integriert. Daraus resultiert auch der mitlerweile etwas größer gewordene Rattenschwanz an Abhängigkeiten. Weil meine Erweiterung immer größer und größer wurde, habe ich begonnen Komponenten daraus zu extrahieren. So entstand beispielsweise die compression-api. Diese API ist lediglich dazu da, dass eben der Administrator selbst entscheiden kann was er nutzen will. Will er CSS Dateien Minimieren, hat er aktuell z.B. die Möglichkeit zwischen dem cssMinimizer und YUI Compressor zu entscheiden. Für JavaScript gibt es gleich 3 Minimizer: jsMinimizer, DeanEdwardsPacker und wieder den YUI Compressor.

Im großen und ganzen habe ich mich einfach gegen eine große Extension und für viele kleine Extensions entschieden, die der Administrator nach belieben zusammen setzen kann.

Die Auslieferung und Konvertierung in CSS erledigt less.js beim Client. Allerdings brauche ich serverseitig ja die Kommentare und die Variablen. Dafür habe ich einen serverseitigen Parser geschrieben, der LESS-Dateien parst, jedoch nur soweit wie es nötig ist, um die gewünschten Informationen zu finden, zu extrahieren und gegebenenfalls zu überschreiben. Insofern sind bei meiner Extension schon jetzt zwei Parser im Spiel.

Ja da hab ich wohl nicht gründlich genug in den Code geschaut. Ich sage es mal so, in dem Punkt der Serverseitigen Verarbeitung bin ich ein paar Schritte weiter als du. Dafür hast du die über das BE Parametrierbaren LESS Dateien.

MfG Tristan

[soletan]

Denn weder DomainLink noch die compression-api noch lesscss erzeugen Pflichtfelder in den Systemeinstellungen.

Das hatte ich vorhin spontan auch entdeckt, daher mein Mangel an Nachvollziehbarkeit.

Im großen und ganzen habe ich mich einfach gegen eine große Extension und für viele kleine Extensions entschieden, die der Administrator nach belieben zusammen setzen kann.

Aber aus Sicht eines Administrators: wo ist der Unterschied zwischen einer monolithischen Extension und einer Kette von Abhängigkeiten, die bei Installieren der einen Extension dann doch mitgeladen wird. Ich bin ja durchaus auch gegen die Lösung einer Extension, doch stehe ich mehr auch auf optionale Abhängigkeiten. Etwa im Beispiel tx_search und tx_news habe ich diese abhängig vom Vorhandensein der Extension taxonomy_content gebaut, ohne diese zu verlangen. Wer die Taxonomie als Filter braucht, muss die taxonomy_content installieren ... wer nicht, lässt's ...

Ja da hab ich wohl nicht gründlich genug in den Code geschaut. Ich sage es mal so, in dem Punkt der Serverseitigen Verarbeitung bin ich ein paar Schritte weiter als du. Dafür hast du die über das BE Parametrierbaren LESS Dateien.

Daher auch meine Idee, ganz im Stile der taxonomy_content-Anbindung oben deine Extension für die serverseitige Aufbereitung der Daten zu wählen, wenn sich das damit irgendwie machen lässt.

[tril]

Aber aus Sicht eines Administrators: wo ist der Unterschied zwischen einer monolithischen Extension und einer Kette von Abhängigkeiten, die bei Installieren der einen Extension dann doch mitgeladen wird. Ich bin ja durchaus auch gegen die Lösung einer Extension, doch stehe ich mehr auch auf optionale Abhängigkeiten.

Hier muss ich grad Gegensteuern, denn die Abhängigkeiten sind alles andere als optional. DomainLink wird von layout_additional_sources für interne Operationen benötigt. Ich könnte daraus durchaus eine optionale Abhängigkeit machen oder aber das was ich benötige in layout_additional_sources nach implementieren. Aber das ist schließlich nicht Sinn und Zweck des ganzen. Die compression-api ist quasi als extrahierte Extension aus layout_additional_sources ein wichtiger Bestandteil, diese zu entfernen würde gleichbedeutend mit der Reduzierung der Funktionalität um 75% sein.

Das Minimieren, Zusammenführen und Komprimieren von einzelnen CSS oder JS Dateien ist immerhin gerade das, was Kern der Erweiterung layout_additional_sources ist. Ihr ursprünglicher Zweck zusätzliche CSS und JS Dateien bequem per BE in das Layout einzufügen ist längst nicht mehr ihr Kernfeature. Von dem ursprünglichen Kernfeature rührt aber auch der Name her "layout_additional_sources", frei übersetzt so viel bedeutend wie "Zusätzliche Layoutdateien (CSS/JS) für das Layout".
Da sich das Kernfeature mittlerweile drastisch verschoben hat, habe ich mich auch für eine Umbenennung in Theme+ entschieden.

Ich denke man muss aber einfach auch sehen, dass es wenig Sinn macht, gewisse Funktionen zu trennen, die eigentlich explizit zusammen gehören. Es macht in meinen Augen irgendwie keinen Sinn, eine Erweiterung zu entwickeln, die erst CSS Dateien zum Layout hinzufügt (z.B. aus LESS generiert) und dann eine zweite Erweiterung, die diese Minimiert, Zusammenführt und Komprimiert. Das gehört in meinen Augen irgendwie dann doch wieder zusammen. Aber darüber lässt sich auch wieder streiten
IMO ist das Minimieren, Zusammenführen und Komprimieren von CSS und JS Dateien ein Feature, dass jeden Administrator interessieren sollte, denn das ganze hat nicht nur auf die Ladezeit, sondern afaik auch in geringem Maße auf das Google Ranking Einfluss (Stichwort: page speed).

Aber ich glaube wir schweifen langsam ab vom Thema und beginnen hier eine Grundlagendiskussion die eigentlich nichts hier verloren hat. (Mal abgesehen davon, dass ich schon wieder viel zu viel geschrieben habe... *oops*). Ich fände es nur ziemlich Banane, wenn hier wieder 2 Erweiterungen für ein und dasselbe Feature entstehen würden.

MfG Tristan

[soletan]

Hier muss ich grad Gegensteuern, denn die Abhängigkeiten sind alles andere als optional.

Dagegen habe ich ja nichts. Mein Punkt ist ein anderer: hast du schon mal ein Visual Studio 2010 Professional auf deinem Rechner installiert? Dann noch ein oder zwei SDKs ergänzt und danach mal in die Systemsteuerung geschaut, um Programme zu deinstallieren? Da werden auch 20-30 separate Pakete benötigt, was sich aber nicht positiv auf dieses Werkzeug "Programme deinstallieren" auswirkt. Schlimmer ist dies oft bei Linux, wo bestimmte Apps schnell mal bis zu 100 andere Pakete mit an Bord holen. Hast du die eine App fertig getestet, für ungeeignet befunden und deinstalliert, bleibt der Rest mitunter dennoch im System ... aus Angst, man könnte Abhängigkeiten zerstören. So geht es mir bei der Erweiterungsverwaltung auch leicht, erst recht wenn die zugeladenen Extensions mitunter nur wenige Dateien mit je 1-2 KB umfassen.

Dass die Erweiterungsverwaltung in Contao sehr überholungsbedürftig ist und man aktuell teilweise nur so weiterkommt, mag sein. Doch eben aus Sicht eines Site-Nutzers ist oftmals wenig geholfen, wenn man ihm eine ganze Kladde an Extensions auflistet, die er nur zu einem Bruchteil auch selbst installiert hat.

Da sich das Kernfeature mittlerweile drastisch verschoben hat, habe ich mich auch für eine Umbenennung in Theme+ entschieden.

Dann hake ich hier nochmal ein, denn ich bin ja ehrlich gewillt, mich auf vorhandene Angebote zu stützen. Und so habe ich - nach Entdecken von lesscss.org - zuerst gefragt: "Gibt's da nicht auch was von ..." und habe auf contao.org eine Extension gesucht, per Volltextsuche, Suchterm "less" ... "Keine entsprechenden Erweiterungen gefunden." Danach in der Contao-Installation meines Vertrauens in den Erweiterungskatalog nach less gesucht bzw. als Stichwort genutzt: "keine Treffer". Selbst wenn ich die Erweiterungsliste auf Contao.org jetzt wissend auf deinen Namen filter, finde ich keine der beiden Extensions. Von las und Theme+ habe ich also in diesem Zusammenhang noch weniger erfahren als von lesscss ... letzteres habe ich nur entdeckt, weil ich beim Versuch, selbst eine Extension unter dem Namen anzulegen, per Fehler auf deren Existenz hingewiesen wurde.

Ich denke man muss aber einfach auch sehen, dass es wenig Sinn macht, gewisse Funktionen zu trennen, die eigentlich explizit zusammen gehören.

Klar, aber es ist aber auch nicht schlimm, manchmal eine per Design ausreichend kontext-unabhängige Funktion oder Klasse per Sourcecode zu übernehmen, als sie gleich in eine DLL auszulagern. Ich sehe da neben meiner Sicht des Software-Entwicklers, der klar modularisieren und damit effizienter produzieren möchte, eben auch die des Nutzers, der Abhängigkeiten oft nicht durchschauen kann. Und inwiefern "DomainLink" was mit "LESS CSS" zu tun hat, erschließt sich von außen gesehen eben nicht.

IMO ist das Minimieren, Zusammenführen und Komprimieren von CSS und JS Dateien ein Feature, dass jeden Administrator interessieren sollte, denn das ganze hat nicht nur auf die Ladezeit, sondern afaik auch in geringem Maße auf das Google Ranking Einfluss (Stichwort: page speed).

Ebenso kein Einwand. Es geht mir nicht darum, die Rechtfertigung dieser Funktionen anzugreifen ...

Ich fände es nur ziemlich Banane, wenn hier wieder 2 Erweiterungen für ein und dasselbe Feature entstehen würden.

Und auch hier sehe ich zumindest bezogen auf dein [lesscss] noch keine Überschneidung, eher nur eine Ergänzung. Zumal ich Bedenken hätte, auf ein Executable aufzubauen, dass ich dann für meine Funktionalität ausführen muss. Das dürfte bei den meisten Hostern doch eher Probleme machen. Abgesehen davon aber wäre ich durchaus interessiert, bei Vorhandensein der [lesscss] in einem Setup dann automatisch auch diese für die serverseitige Umwandlung einzusetzen. Dadurch hätte man Synergien geschaffen ...

Ob sich Theme+ und meine tx_less funktional eher überschneiden, kann auch aus Mangel an Wissen über Theme+ nicht beurteilen.

VG, soletan

[tril]

Dagegen habe ich ja nichts. Mein Punkt ist ein anderer: hast du schon mal ein Visual Studio 2010 Professional auf deinem Rechner installiert? Dann noch ein oder zwei SDKs ergänzt und danach mal in die Systemsteuerung geschaut, um Programme zu deinstallieren? Da werden auch 20-30 separate Pakete benötigt, was sich aber nicht positiv auf dieses Werkzeug "Programme deinstallieren" auswirkt. Schlimmer ist dies oft bei Linux, wo bestimmte Apps schnell mal bis zu 100 andere Pakete mit an Bord holen. Hast du die eine App fertig getestet, für ungeeignet befunden und deinstalliert, bleibt der Rest mitunter dennoch im System ... aus Angst, man könnte Abhängigkeiten zerstören.

Kann ich irgendwie nicht nachvollziehen, jedes Paketmanagementsystem das ich kenne, sei es APT, RPM, portage löschen automatisch nicht mehr benötigte Abhängigkeiten!

So geht es mir bei der Erweiterungsverwaltung auch leicht, erst recht wenn die zugeladenen Extensions mitunter nur wenige Dateien mit je 1-2 KB umfassen.

Mh ok, ich bin es mitlerweile gewöhnt das ich meine Contao Installation mit 20~30 Extensions voll gehauen habe. Kleinere Websites kommen natürlich auch mit teilweise deutlich weniger aus! Wenn ich eine Erweiterung teste, dann merke ich mir was installiert wurde und kann es dann nach dem testen auch wieder löschen. Man kann sich an alles gewöhnen, auch an eine schlechte Paketverwaltung

Dass die Erweiterungsverwaltung in Contao sehr überholungsbedürftig ist und man aktuell teilweise nur so weiterkommt, mag sein. Doch eben aus Sicht eines Site-Nutzers ist oftmals wenig geholfen, wenn man ihm eine ganze Kladde an Extensions auflistet, die er nur zu einem Bruchteil auch selbst installiert hat.

In beiden Punkten kann ich dir leider nur recht geben. Ersteres ist bereits in Überarbeitung. Und bei letzterem muss ich halt sagen, dass wir aktuell nur damit leben können...

Dann hake ich hier nochmal ein, denn ich bin ja ehrlich gewillt, mich auf vorhandene Angebote zu stützen. Und so habe ich - nach Entdecken von lesscss.org - zuerst gefragt: "Gibt's da nicht auch was von ..."

OK, das habe ich wohl übersehen, aber ich bin in letzter Zeit sowieso so ausgebucht, dass ich nur wenig im Forum lese...

...und habe auf contao.org eine Extension gesucht, per Volltextsuche, Suchterm "less" ... "Keine entsprechenden Erweiterungen gefunden." Danach in der Contao-Installation meines Vertrauens in den Erweiterungskatalog nach less gesucht bzw. als Stichwort genutzt: "keine Treffer".

Da das die gleiche (sch***) Suche ist, ist es klar das du weder auf contao.org noch im Erweiterungskatalog etwas findest.
Kleiner Tipp, versuchs mal mit CERIS vom Contao Pool

http://www.contao-pool.de/ceris.html

Selbst wenn ich die Erweiterungsliste auf Contao.org jetzt wissend auf deinen Namen filter, finde ich keine der beiden Extensions.

Also layout_additional_sources findet sich hier auf der ersten Seite: http://www.contao.org/erweiterungsli...ompat/2.9.html
und lesscss auf der dritten

Klar, aber es ist aber auch nicht schlimm, manchmal eine per Design ausreichend kontext-unabhängige Funktion oder Klasse per Sourcecode zu übernehmen, als sie gleich in eine DLL auszulagern.

Redundanz ahoi! *sry*

Ich sehe da neben meiner Sicht des Software-Entwicklers, der klar modularisieren und damit effizienter produzieren möchte, eben auch die des Nutzers, der Abhängigkeiten oft nicht durchschauen kann.

Das sollte ja auch eigentlich der Paketmanager für den Nutzer übernehmen, wenn er das denn im Fall des Extension Repositories könnte

Und inwiefern "DomainLink" was mit "LESS CSS" zu tun hat, erschließt sich von außen gesehen eben nicht.

Mit LESS selbst nicht, aber LAS benötigt es, weil es intern die CSS Dateien verändert. In älteren Versionen sogar noch deutlich stärker, als in der aktuellen Version. Mit ein paar wenigen Änderungen und dabei müsste ich noch nicht mal die Funktionalität von DomainLink kopieren, ließe sich diese Abhängigkeit auch gänzlich entfernen. Dann kommt aber wieder die compression-api ins Spiel, die schreib nämlich intern ebenfalls die CSS Dateien um und benötigt teilweise die Fähigkeiten von DomainLink.
Das ganze hängt in dem Fall mit dem Minimieren und Vereinheitlichen der CSS Dateien zusammen.

Ebenso kein Einwand. Es geht mir nicht darum, die Rechtfertigung dieser Funktionen anzugreifen ...

War auch mehr so ne Randbemerkung, wobei, was erzeugt denn LESS? Genau, CSS Code, also sind wir wieder beim Thema

Und auch hier sehe ich zumindest bezogen auf dein [lesscss] noch keine Überschneidung, eher nur eine Ergänzung. Zumal ich Bedenken hätte, auf ein Executable aufzubauen, dass ich dann für meine Funktionalität ausführen muss. Das dürfte bei den meisten Hostern doch eher Probleme machen. Abgesehen davon aber wäre ich durchaus interessiert, bei Vorhandensein der [lesscss] in einem Setup dann automatisch auch diese für die serverseitige Umwandlung einzusetzen. Dadurch hätte man Synergien geschaffen ...

Ob sich Theme+ und meine tx_less funktional eher überschneiden, kann auch aus Mangel an Wissen über Theme+ nicht beurteilen.

LAS/Theme+ benutzt die Serverseitige LESS Verarbeitung nur, wenn diese auch unterstützt wird oder mit anderen Worten: Wenn es möglich ist, "node.js" auf dem Server auszuführen. Ansonsten wird ebenso less.js genutzt so wie bei dir, d.h. die Überschneidung liegt allein in der less.js Unterstützung. Du bringst nur noch den Zusatz, die LESS Dateien per BE zu parametriesieren.

MfG Tristan

[soletan]

Kann ich irgendwie nicht nachvollziehen, jedes Paketmanagementsystem das ich kenne, sei es APT, RPM, portage löschen automatisch nicht mehr benötigte Abhängigkeiten!

Das stimmt bedingt. Ich habe auch so meine Erfahrungen mit yast, yum, apt und portage. Gerade die schlechten Erfahrungen mit yast und yum haben mich zuletzt auf gentoo gebracht. Oft musste ich aber auch da erst ein nicht gewolltes X dekonfigurieren, damit ich auch headless eine fontlib sonstwo einbinden konnte. Wenn du dort bspw. tomcat installierst, danach wieder entfernst und für den tomcat eine bis dato ungenutzte dev-chain für java eingefügt wurde, dann bleibt die erst einmal im System. Ähnliches gilt für obige fontlib und darüber eingebundene xviewer, treiber, xorg-server ... mitunter half mir nur eine manuelle Analyse der Abhängigkeiten.

War auch mehr so ne Randbemerkung, wobei, was erzeugt denn LESS? Genau, CSS Code, also sind wir wieder beim Thema

Die less.js arbeitet aber beim Client. Für den pageload ist daher die CSS-Größe hinterher belangloser. Da LESS-Dateien per se knapper sind als CSS, dürften Google & Co. sich auch weniger an der Größe stören, sofern sie die rel="stylesheet/less"-Verweise überhaupt in gleicher Weise auswerten und bewerten. Das weiß am Ende nur Google.

Gerade bei CSS spart man aber durch das Minifying in erster Linie doch auch nur Kommentare und Whitespace. Erstere nutze ich kaum/nicht, letztere fallen weniger ins Gewicht ... und oft haben CSS-Dateien mehr Sparpotenzial durch bessere Rules, die auch ein CSS-Minifier mangels Kenntnis der HTML-Struktur nicht intelligent bereinigen kann. Entsprechende Erfahrungen sammle ich gerade wieder bei Wordpress ... bspw. können Layouts mitunter auf das inzwischen recht populäre Reset aller Styles durchaus verzichten. Das spart weit mehr als alle Whitespaces, die ich so in meine CSS zimmere.

Überschneidung liegt allein in der less.js Unterstützung. Du bringst nur noch den Zusatz, die LESS Dateien per BE zu parametriesieren.

Aber das dafür per Intention ...

VG.