General Community > Development 2.10.x
<body id="var">
evaki:
Für's neue Jahr... :-D
Im Zusammenhang mit SASS, das ich bisher selbst noch nie genutzt habe, worum ich mich aber nun wg. eines Anwenders kümmern soll, tauchten nicht nur dynamisches CSS auf, sondern nun auch entsprechende Elemente, hier nun body.
Die Möglichkeit "body id" vielfältig nutzen zu können, hängt auch vom jeweils verwendeten CMS ab.
Dynamische body ID's lassen sich auch in WB nutzen, m.W. aber nicht ganz so dynamisch wie es möglich wäre -wenn ich nichts übersehen habe.
Im vorliegenden Falle gehts darum ausgewählte Seiten gestalterisch (per CSS) einer bestimmten Gruppe zuzuordnen. Das kann also ab (von, bis) einer bestimmten Unterebene (SM2), in Abhängigkeit von Seiten (pageID), oder z.B. von Verzeichnissen (z.B. /media/xy...) geschehen. Sogar globalBlocks sind inbegriffen. Sowas ist dann mehr oder minder im Template fest verdrahtet, evtl. dann auch in wechselnden sekundären Templates. (Ausgenommen sind hierbei die Anteile aus Modulen oder aus WYSIWYG)
Per bodyID's ließe sich derartiges dynamisch gestalten.
Will man html nicht anrühren, können es auch entsprechende Platzhalter im Template sein, die genauso für andere andere Funktionen herhalten können. Gut, somit ist man beim Thema CMS-Scriptsprachen.
Gibts für sowas ne OpenSource Schriptsprache (muß ja nicht t_y_p_o3script "ausarten), die sich in WB implementieren ließe?
MfG. Evaki
Gast:
Möglichkeiten gäbe es schon genug, allerdings fliegen die nicht automatisch in das jeweils aktive Frontend-Template und selbst, wenn das so wäre, findet sich ganz schnell jemand, dem diese Lösung nicht gefällt, weil er dafür bereits eigene Sachen integriert hat.
Einfachste und zugleich sicherste Möglichkeit für ein <body id="page"> wäre die Nutzung der Page-ID mit einem Bezeichner XY, z.B.
--- Code: ---<body id="page<?php echo PAGE_ID; ?>">
--- End code ---
Analog gilt das dann auch für einzelne Blöcke, z.b,
--- Code: ---<div id="main<?php echo PAGE_ID; ?>" class="main-content">
--- End code ---
oder über die Section-ID
--- Code: ---<div id="main<?php echo SECTION_ID; ?>" class="main-content">
--- End code ---
all das setzt aber voraus, das der Benutzer die Werkzeuge zum Erstellen von LESS und SASS bedienen kann und über das benötigte Wissen verfügt. Am Ende habe ich auch nur eine komplierte CSS-Datei, die es einzubinden gilt
evaki:
Jo, so is dat.
Wobei ich dummerweise versäumt habe, ausdrücklich auf eine frei konfigurierbare Gruppenzuordnung als Wunsch zu verweisen, also die schon jetzt genannten Möglichkeiten bzw. Zuweisungen wahrzunehmen, aber diese dann auch einer wählbaren Gruppe zuordnen zu können, resp. in einer Gruppe die Möglichkeiten zusammenzufassen, und damit den Interpreter seine Arbeit machen zu lassen. Natürlich entsteht hierdurch nur eine entsprechende CSS bzw. mehrere. Wer sich für sowas entscheidet, stößt halt bei der Gestaltung und Bedienung an Grenzen, die er überwinden möchte.
Wer sich anno-dazumal mit ZEN-Garden beschäftigt hat, kennt halt die strikte Trennung von CSS und HTML-Struktur.
Apropos SASS. In der letzten Woche stieß ich bei einem Anwender auf einen Stolperstein:
--- Code: ---imgresponsive.css
.responsive100 {
width: 100%;
height: auto;
}
.responsive90 {
width: 90%;
height: auto;
}
.responsive75 {
width: 75%;
height: auto;
}
usw.
--- End code ---
Das läßt sich eleganter lösen, als den zigsten Zettel mit Optionen dazuzubacken :-D
Da die meisten meiner Anwender beim selben Hoster sind, sind Python und Ruby schon im "zweitkleinsten" Paket drin. Schön, wenn man auch mal mit Erfahrungen der eigenen Anwendern bereichert wird.
Die Benutzer selbst kommen mit SASS bei sowas übrigens nicht in Berührung. Das ist die Sache des Templateerstellers, in Absprache mit dem Admin, so daß die Schreiber nur die Möglichkeiten offeriert bekommen (Optionen bei den einzubindenden Objekten).
MfG. Evaki
Gast:
warum sagst du nicht in einfachen, klaren Worten, was du möchtest? :-o
Und wenn du noch ein praktisches Beispiel dazu packst, versteht es der Rest auch
Es ist wohl so, das LESS/SASS nur von einer ganz, ganz kleinen Gruppe von WB-Nutzern eingesetzt wird, i.d.R. von Leute, die damit auch berufsmäßig arbeiten. Wenn nicht gerade über ein Freies Template kopiert, dann kaum vom allgemeinen User.
Für mich gesprochen, sehe ich da kein Problem, beide Methoden mit dem aktuellen WB zu verwenden. Was mir der Core nicht liefert, z.b. die angesprochene Gruppenzuordnung (sofern ich dich da richtig verstehe), kann ich mir auch selbst bauen, in dem ich z.b. diverse Page-ID's in einem Array zusammenfasse und darüber eine Klasse oder ID setze.
Ich könnte auch den Parent abfragen und so alle Childs gruppieren oder, oder, oder.....
Und ob ich nachher eine eher private Klasse für mich und mein SASS draus mache oder eine, die ich in z.b. Bootstrap oder W3CSS etc verwenden kann, bleibt meiner Fantasie überlassen.
Sicherlich wäre es einfacher, wenn ich eine Gruppe XY per Seiteneinstellung wählen könnte, allerdings kenn ich auf Anhieb auch kein CMS, das solch Gruppierung ermöglicht. WB hat seit einigen Jahren die bislang unbedienten Datenbank-Felder custom1 und custom2 in der pages-Tabelle, die man über ein kleines AdminTool bedienen könnte. AdminTool hieße aber: Seiteneinstellungen verlassen und in eine Übersicht wechseln. Dank der neuen helpers-Funktionen ist solch Übersicht mit Einstellmöglichkeit en schnell gemacht. Das Auslesen geht dann aber wieder nur individuell.
Wie gesagt, ich persönlich gehe von einem sehr kleinen Anwenderkreis aus, ein, zwei Prozent vielleicht und da stellt sich die Frage, ob ich das CMS für die Allgemeinheit aufblähen muß?
Interessanter wäre für mich da eher die Frage, ob es nicht grundsätzlich möglich sein könnte, mich mittels Addon z.b. in die Page-Settings einzuklinken. Da sehe ich z.b. in Wordpress teils recht gute Lösungen. Ein Plugin wie solch Gruppierungsmöglich keit hat ein Basis-Settings (z.b. das Anlegen von Gruppen unter AdminTools) und würde sich dann an die vorhandenen Pagesettings anhängen, ein nächstes Addon dann wieder darunter. Solch Vorgehen wäre technisch kein Problem und mit der anstehenden Umstellung auf Twig muß eh alles einmal durch gearbeitet werden, aber es bedarf eben eines grundlegenden Konzepts und einiger Regeln.
Aber auch dann, wenn all die Fantasie-Möglichkeiten vorhanden sind, braucht es am Ende jemanden, der das vernünftig nutzt. Wenn ich z.b. in WP sehe, das ich für manche CSS-Klassen 50 Einträge habe, weil jedes Addon da ein paar Klassen hinzufügt, bin ich eher dagegen und ziehe die Einzelprogrammierun g vor, bei der ich auslese, was ich brauche.
evaki:
Ja, manchmal mache ich es "Euch" nicht einfach.
Ist aber auch schwierig, wenn man etwas aus dem Anwenderkreis mitgeteilt bekommt, mit dem man ja bisher keinen Kontakt, und auch keine Praxis hatte, also selbst (doof wie Schwarzbrot) mit was Neuem bzw Unbekanntem konfrontiert wird.
>>"Sicherlich wäre es einfacher, wenn ich eine Gruppe XY per Seiteneinstellung wählen könnte"
>>"mich mittels Addon z.b. in die Page-Settings einzuklinken."
Gut zu wissen, daß ich mich nicht komplett auf Abwegen befand.
Schauen wir mal, was sich im neuen Jahr noch so an Ideen aus dem Sandkasten schaufeln läßt.
MfG. Evaki
p.s. Einen schönen Restfeiertag wünsch ich noch (Y)
Navigation
[0] Message Index
[#] Next page
Go to full version