CSS Klasse in Rendersetting eines Attributes definieren

[cogizz]

Wir haben relativ oft Attribute, wo zwar die HTML-Struktur gleich ist, wir aber eine eigene CSS-Class benötigen. Dafür wäre es super, wenn man an das Attribute-Template eine eigene Class übergeben könnte.

Das Template würde dann zum Beispiel wie folgt aussehen:

<span class="text<?php echo $this->customClass;?>"><?php echo $this->raw; ?></span>

Dadurch könnte man an vielen Stellen einfach das Standard-Attribut-Template nutzen.

[andreasisaak]

Theoretisch bin ich da voll bei dir. Aber das müssten wir nun in allen 30 Attributen machen :(

[cogizz]

Mit den Attributen hast du recht, das in der tat mühsam die alle zu aktualisieren. Ich habe dennoch mal einen Ansatz gebaut, der es ermöglicht eine CSS Klasse zu setzen.

cogizz/core@contao3...feature/css-class-attribute-rendersetting

Bei diesem Ansatz müssten nur die Templates der Attribute angepasst werden. Ich habe es bisher mit den Attributen Text, Tabletext, Longtext und File getestet. Dort hat eine kleine Anpassung des Attribut-Templates ausgereicht.

Attribut-Text: <span class="text<?php echo $this->additional_class; ?>"><?php echo $this->raw; ?></span>

Sollte euch der Ansatz gefallen, könnte ich kurzfristig für einige Attribute ( etwa 10 Stück ) entsprechende PR machen. Für die verbleibenden dann gerne später auch.

[discordier]

Klingt gut. bis das jedoch dann yberall drin ist, wird, wie @andreasisaak bereits sagte, ein wenig dauern.

[tim-bec]

Bei den PRs würde ich helfen.

[andreasisaak]

@discordier Wenn es für dich ok ist dass das Feld nicht von jedem Attribut kommt sondern vom Core selbst und man nur die Templates ändern muss, dann mache ich mir die Arbeit.

Aber wenn nun jedes Attribut dieses Feld braucht, dann warte ich noch auf V2

[discordier]

@andreasisaak Das kann man dann ohne Probleme von C3 nach tng mergen, zumindest in den Attributen, betrifft ja nur templates.
Allgemein sollten wir ja sowieso alles nach tng future-porten.

[andreasisaak]

@cogizz Wenn du mir da mit PR's helfen willst, gerne. Aber nur im C3 Branch

[cogizz]

Ich habe gerade mal einen PR für den Core erstellt, basierend auf den bereits bekannten änderungen.

@andreasisaak natürlich helfe ich dir, hab das ja so quasi angezettelt ;) ... ich könnte für die folgenden Attribute PR erstellen: alias, checkbox, file, longtext, select, tabletext, tags, text und timestamp. Damit würde ich morgen anfangen wollen ...

[andreasisaak]

Ich veröffentliche hier gleich eine Checkliste die wir dann abarbeiten können. Heute Abend fange ich schon mal an, vllt werde ich ja fertig.

Doof ist nur die Übernahme aller Änderungen von den contao3 in den tng Branch

[tim-bec]

Ist hier noch Unterstützung nötig? Dann würde ich mir das richtige forken und pull-requesten auch noch mal zu Gemüte führen...

[andreasisaak]

Jede Hilfe ist Herzlich Willkommen. Aber mach PR's nur für den Contao Branch. Gerne auch für Contao 3 und den TNG Branch (der ja der Branch für Contao 2.11 und Contao 3 ist)

[tim-bec]

@andreasisaak @cogizz gibt es eine Liste der schon erledigten Attribute?

[cogizz]

Ich bin bisher leider noch nicht dazu gekommen damit anzufangen. Habe auch noch auf die ToDo-Liste von @andreasisaak gewartet. Ich kann aber auch gerne morgen mal eine ToDo-Liste erstellen und anfangen mit den Attributen.
@andreasisaak wäre es nicht einfacher wir erstellen nur PR's für den Contao3 Branch und Ihr merged das dann in den TNG?

[tim-bec]

Wollen wir das bei Zeiten angehen @cogizz ?

[cogizz]

@tim-bec definitiv, ich habe auch schon ein paar templates hier liegen. ich trage das kommende woche mal zusammen.

[discordier]

Status?

[cyberlussi]

gut dass ich den Punkt hier gefunden habe, dann brauche ich kein neues Ticket aufzumachen 👍

[cogizz]

@tim-bec wollen wir das Thema am Sonntag mal angehen? Gerne vorher einmal Mumble am Sonntag?!

[tim-bec]

@cogizz ja! Sonntag klingt gut. Termin am besten per IRC ?

[cogizz]

@tim-bec und ich habe dazu morgen ein gespräch.
@discordier hast du eine idee, wie man die ganzen attribute möglichst einfach forken/clonen und in Contao holen kann? Meine Überlegung für den Teil mit Contao wäre den Autoloader der nightlies zu nehmen. Bessere Ideen?

[cogizz]

Ich mache gerade die folgenden Attribute ... liste wird später ergänzt.

• attribute_text
• attribute_longtext
• attribute_alias
• attribute_tags
• attribute_numeric
• attribute_rating
• attribute_country
• attribute_langcode
• attribute_tabletext
• attribute_checkbox
• attribute_file
• attribute_select
• attribute_decimal
• attribute_url
• attribute_timestamp
• attribute_combinedvalues
• attribute_color
• attribute_geoprotection

[tim-bec]

@cogizz so, nun dürften wir weitestgehend durch sein, bis auf die attribute die noch nicht TNG kompatibel sind (...) und die, die ich nicht verstehe ( z.b. https://github.com/MetaModels/attribute_select/blob/tng/src/system/modules/metamodelsattribute_select/templates/mm_attr_select.html5 )

[cyberlussi]

Ich habe noch eine Frage: Im Moment wird so bei jedem Attribut "innen" die additional_class hinzugefügt. Ich würde diese aber gerne "außen" (im Kontext metamodel_prerendered, leider sind die additonal_classes dort nicht im Template direkt verfügbar) plazieren.

Nur wie?

// aktuell
<div class="field detailed_text">
    <div class="value"> <span class="text  foobar">
        ...
    </span></div>
</div>

// Wunsch
<div class="field detailed_text foobar">
    <div class="value"> <span class="text">
        ...
    </span></div>
</div>

Warum? So könnte man super einfach Bootstrap oder andere CSS Frameworks mit Grids anflanschen. Wenn die additional_classes "innen" plaziert sind, kann man z.B. kein Grid anwenden, da die Klassen je nach Attribut immer auf unterschiedlichen Ebenen liegen.

Ergänzung: (Um es noch komplizierter zu machen :)
Am besten wäre es, wenn Attribute zwei additional_class Felder haben würden: additional_class_inner (wie jetzt) und additional_class_outer (am div.field) - damit wäre es echt perfekt und super flexibel!

[zonky2]

@cyberlussi: wäre es nicht "einfacher" und noch flexibler die Inner/Outer-Sache per Template-Variante zu erledigen?

• mm_attr_checkbox
• mm_attr_checkbox_bootstrap
• mm_attr_checkbox_foundation

[cyberlussi]

ja ... so halb. Wenn man auf der Ebene "field" die Klasse eines Attributes angezeit haben will, klappt das nicht direkt, da das nicht das mm_attr_* Template sondern metamodel_prerendered ist und dort die Klasse nicht einfach zugänglich ist. Aktuell habe ich auch einen Workaround verwendet, das metamodel_prerendered anzupassen und über die API auf die Klasse der Attribute zuzugreifen.

// aktuell
<div class="field detailed_text"> <!-- aus metamodel_prerendered -->
    <div class="value"> <span class="text  foobar"> <!-- aus mm_attr_* -->
        ...
    </span></div>
</div>

Meine Aufgabe, die ich hatte, war die Klasse in die Ebene "field" also metamodel_prerendered zu legen. Für zukünftige Projekte wäre es aber super, wenn man nicht stetig die Templates anpassen müsste, sondern die fertigen Templates nehmen kann.

[zonky2]

@cyberlussi: stimmt! bei mm_attr_* ist man schon "eine Etage zu tief"...

es wäre ggf. an der Stelle die "Grundsatzfrage" zu stellen, ob der "äußere Div-Container" aus metamodel_prerendered nicht eher in in das Template-Partial mm_attr_* gehört... - dazu müsste man alle mm_attr_* einmal anpassen und das Div aus prerendered raus nehemen...

...mit dem doppelten Eintrag der Klasse bzw. zwei Eintragsmöglichkeiten habe ich irgendwie ein "komisches Gefühl" - auch wenn technisch sicher machbar

siehe auch #660

[cyberlussi]

joa ... also technisch ist sicherlich vieles möglich :) So habe ich auch folgenden "Quickhack" im metamodel_prerendered machen können, um dort an die additional_class zu kommen.

echo $this->view->getSetting($strField)->get('additional_class');

[zonky2]

"von außen" siehts ja keiner... ;-))

[cboelter]

@tim-bec haben wir da mittlerweile alle Attribute erwischt?

[discordier]

Ich hoffe es.

[tim-bec]

@cboelter ich hoffe es auch, schließe das hier vorerst - wenn uns noch was begegnet, machen wir tickets auf, okay?