Theme vs. Mod TPLs

[xsign.dll]

So...
Wir müssen jetzt mal auf nen grünen Zweig mit der Scheiß Theme Kacke dort kommen. Ich hab absolut keine Lust, die TPLs doppelt zu schreiben. Einmal für Standard UND einmal fürs Modul. Was fürn Schwachsinn - ganz ehrlich.

Sowas geht nicht, vorallem wenn wir die Module später zum Einsatz bringen wollen und als standalone präsentieren müssen.

Daher folgendes Fazit:

Wir bleiben auf "Standard Theme", aber dort gibt es nur 3 Files:

Code:

index.tpl
standard.css
theme.xml

Der Rest fliegt umgehend raus bzw. wird in die Module verschoben.
Die Mod Templates werden die CSS Sachen von standard.css verwenden UND BITTE KEIN style="" ...

[thunderm00n]

Die verwendung von "eigenen" Modul-TPLs bleibt jedoch erhalten (wenn diese vorhanden sind) oder?
Hatten darüber ja im TS schon gesprochen...

[xsign.dll]

Na ich beschränke die ganze Sache jetzt NUR auf die Modul Templates!
Also alle Templates werden NUR noch im Modul Ordner verändert.

Alles was Look & Feel betrifft, wird ja über die standard.css und index.tpl gesteuert. Und das ist auch richtig so.
Hatten diese Verfahren, wie schon gesagt, im TS abgesprochen.

Jetzt gehts nur noch dran, gewisse Richtlinien einzuführen.
Also was wir rudimentär mit "cell1" "cell2" etc. versucht haben, muss nun ausgebaut werden. Das wäre dann dein Part eigentlich

/edit: Ja - man kann die TPLs immer wieder im jeweiligen Themes Ordner überschreiben. Das ist jetzt nur für uns gedacht, damit wir nicht alles zweimal schreiben müssen und damit die Module ihre eigenen Templates mitliefern.

[thunderm00n]

Also können wir festhalten:

1.) Durchweg vereinheitlichte css klassen in den clansuite_templates (die in den modulordnern liegen)
2.) Alle css Klassen werden über die standard.css zentral gesteuert.  incl. Kommentare

Wobei die Verwenung von "Custom-Templates" im Theme Ordner weiterhin möglich bleibt. (Für uns aber erstmal unrelevant ist)

[xsign.dll]

Ganz genau.

[thunderm00n]

Dann sollte im Auslieferungstemplate jedoch später quasi ein "Custom-Template" genutzt werden um daran auch direkt den Usern eine Anpassung zu erklären (vereinfachen). Das können wir ja dann quasi zum Schluss hinzufügen. Find ich gut.

Das zieht aber eine Komplett Überarbeitung bzw Sichtung alles bisherigen Templates nach sich na da hab ich ja dann gut zu tun.

[xsign.dll]

also die tpls hab ich schon geändert. liegen alle im mod ordner und sind auch schon angepasst.
wenn wir beim release angekommen sind, kann man die tpls recursiv locker in den standard ordner packen, das stellt kein problem dar.

[thunderm00n]

supi, so muss jetzt zum kunden^^ bis später

[Jens-A. Koch]

Also wir arbeiten bislang nach diesem Muster:
Das Theme "Drahtgitter" ist der eigentliche Ausgangspunkt! Es zeigt die Templates des Modul-Folders an.
Das Theme "Standard" ist (war), genau wie das "Accessible" bereits ein vollständiges Theming aller Modul-Templates. Die Arbeit ist doch aus gutem Grund doppelt.

Im Prinzip gehts um Vereinheitlichung des CSS-Krams: ich schlage die Verwendugn eines CSS-Frameworks (feste Standards) für die Modul-Folder-Templates vor.

[xsign.dll]

Und warum fehlen dann Templates bei den Modulen und ich such mir nen Wolf ? Das muss aufhören...
Wir sollten uns nicht um die themes kümmern, sondern dass die module standalone funktionieren.
Und warum sollen wir uns die arbeit doppelt machen? Das musste mir echt mal erklären...

[Jens-A. Koch]

Wenn wir uns doppelte Arbeit ersparen wollen, müssen wir uns auf nen CSS Style einigen bzw. nen FW nehmen und den gleichmäßig verwenden. "Standard" war ohne ein CSS Standard und komplett eigenständig vom Style - insoweit war es doppelte Arbeit. Ich hab meistens die Styleangaben einfach entfernt, wenn ich aus Standard in den Modul-Folder kopiert habe. Im Modul-Folder später einfach CSS-FW hinzuzufügen, is kein Thema: aber je früher wir auf nen CSS-FW kommen, desto besser.

D.h. Standard-Template -> sauberes TPL im Modul-Folder (testen mit Drahtgitter) -> CSS-Frameworks Styles hinzufügen

[xsign.dll]

kay - vorschläge?

[Jens-A. Koch]

Ich stell mal ne kleine Liste von CSS-Frameworks zusammen und setz ne Abstimmung dafür an.

1.YAML
Website & Demo:  http://www.yaml.de/
Builder verfügbar.
Lizenz: Creative Commons 2

2. BluePrintCSS
Website: http://www.blueprintcss.org/
Demo: http://www.blueprintcss.org/sample.html
Lizenz: MIT

3. Yahoo Grids
http://developer.yahoo.com/yui/grids/
Lizenz: BSD

4. Grideasy
Website: http://grideasy.blogpimp.de/
Lizenz: GNU

5. Elements
Website: http://elements.projectdesigns.org/

6. Tripoli
http://devkick.com/lab/tripoli/
Lizenz: GPL

7. 960 Grid System
Website: http://960.gs/
Demo: http://avalonstar.com/
Lizenz: GNU GPL & MIT

8. WMStyle
Website: http://www.wymstyle.org/en/
Lizenz: LGPL

[xsign.dll]

Hier noch kurz was zum lesen, während ich aufs game warte:
http://warpspire.com/features/css-frameworks/

[Jens-A. Koch]

kurzgefasst:
Pro
Speed up your develoment (don’t have to write all that HTML/CSS)
Don’t worry about those nasty IE bugs!
Normalize your code/class base

Contra
Familiarity with your code’s architecture
Inheriting someone else’s bugs
Not learning

[xsign.dll]

Kurzgefasst auf deutsch:

Danach gelten als Vorteile ...

    * Steigerung der Produktivität
    * Vermeiden von alltäglichen Fehlern
    * Einheitliche Code-Basis
    * Verbesserter Workflow bei Team-Arbeit

Dem gegenüber stehen einige Nachteile ...

    * Erlernen der Arbeitsweise des Frameworks kostet Zeit
    * Verstehen der Code-Architektur kostet Zeit
    * Fehler in der Codebasis werden unerkannt mitgeschleift
    * Man vertaut dem Framework, nicht seinen eigenen CSS-Kenntnissen
    * Frameworks erzeugen Overhead im Code
    * CSS Frameworks und semantische Codeauszeichnung stehen im Gegensatz zueinander
    * Man ignoriert die Einzigartigkeit eines Webprojekts

[xsign.dll]

Btw:

YAML bedeutet "Yet Another Multicolumn Layout" und ist ein (X)HTML/CSS Framework von Dirk Jesse zu Erstellung moderner und flexibler Layouts basierend auf float-Umgebungen.

Haben wir das bzw. wollen wir auf Float Umgebungen setzen? NEIN! Und zwar ganz klares Nein!
Und noch als Anmerkung, weil wir das Thema im IRC hatten:
Joomla bietet keine native YAML Unterstützung an. Dafür gibt es extra Designer, die YAML Templates erstellen. Das ist bei uns ebenfalls möglich.

Ich bin gegen YAML, da ich:
1. nicht ohne tables arbeiten will
2. einfache class="" Strukturen auch so mit Konventionen gut beschreiben kann, sodass es modular ist
3. müsste man YAML ebenfalls mit diesen style classes ausstatten, um zu stylen - also vollkommen sinnlos auf YAML zu setzen imho

Vorallem aber müssten wir ALLE templates umbauen, und dazu bin ich in der 0.2alpha weder bereit, noch werde ich es sppäter bereit sein, mir YAML als "neue" Sprache anzueignen.

[xsign.dll]

Nach Monaten der Überlegung, habe ich mich dazu entschlossen, die Kippe in das Bier fallen zu lassen. Ich bin gegen CSS Frameworks.

(c) This post is licensed under Artificial Artist License

powered by Rucksack-in-die-Menge-Werfern!