#3 Benutzerdefinierte Veraenderungen

[Alexander Fischer]

Bis wir ein eigenes Layout haben (bzw, das devel bleibt ja erhalten -> sollte
evtl. mal umbenannt werden.. "quick_and_fast" oder so ^^)...

Auf jedenfall, erm, hatten wir ja gesagt, dass wir dem Benutzer eine
Moeglichkeit anbieten wollen, das Layout seinen Beduerfnissen anzupassen.
Farben / Schriftgroessen.

Es gibt mehrere praktische Ansaetze wie wir das Loesen koennten.

a) wir definieren hardcodet eine handvoll Layouts und bieten dem User die
Auswahl an Vorteil: keine DB-Belastung, wenig Wartungsaufwand Nachteil: Dem
Benutzer wird wieder etwas "aufgedraengt"

b) wir nehmen uns Systeme wie z.B. Drupal als Beispiel: Bei dem Standard-Layout
hat der Benutzer eine Moeglichkeit, mittels eines "Farbrades" aus dem gesamten
Farbspektrum seine gewuenschten Farben festzulegen, dessen Hex-Werte wir in der
Datenbank beim user speichern (werden wohl 2-3 spalten belegen: background,
schriftfarbe, menu, what ever) - zudem eben noch eine spalte mit
schriftgroesse.
Vorteil: Der Benutzer hat vollste Freiheit ueber seine Vorlieben
Nachteil: 4-5 Spalten in der Tabelle werden mehr benutzt werden.

Weite Vorschlaege, Meinungen?

------- Kommentar Nr. 1 von Johannes 2008-11-05 20:22:45 (−) [antworten] -------

Quick and fast? Soll das eine Beleidigung sein? xD

Wie stellst du dir das mit den Änderungen über die DB vor? Du kannst ja die
CSS-Dateien nicht wirklich 'bearbeiten', von Smarty werden die auch nicht
geparst...

Ich finde, es reicht, wenn es ein paar Designs zur Auswahl gibt. Klar, die
totale Konfigurierbarkeit ist natürlich super, müsste man nur irgendwie
realisierbar machen.

------- Kommentar Nr. 2 von Alexander Fischer 2008-11-06 08:05:04 (−) [antworten] -------

Nein Quick & Fast ist keine Beleidigung, im gegenteil.
Es ist ein schnelles layout und (eigentlich ^^) fast w3c konform und
barrierefrei (daran muessen wir noch arbeiten, bzw. tu ich jetzt gleich)
Zeitvergleich: das stable-release mit dem YAML layout benoetigt im Schnitt
0,729 Sekunden .. das "quick and fast" 0,446 Sekunden .. das sind um ein
gewaltiges stueck weniger - wenn man bedenkt, dass der seiteninhalt der selbe
ist und die zeit nur am "layout" liegt.

Mit der Integration in die Datenbank und das uebernehmen (parsen) durch smarty,
mache ich mir gedanken und meld mich dazu nochmal mit Loesungen fuer die
Realisierung (sofern moeglich). Ist aber schonmal ein Vorteil, dass du
prinzipiell von der Idee nicht abgeneigt bist ;)

------- Kommentar Nr. 3 von Alexander Fischer 2008-11-06 08:59:59 (−) [antworten] -------

Yes, sure.. css-files werden nicht von smarty geparsed (grad nen praxis-test
unterzogen)

da faellt mir spontan eine loesung ein. Wir definieren in der config.ini
standard-farben:

ich nehm jetzt einfach nur ein Beispiel her. Ein Auszug aus der jetzigen
site.css:

body
{
background-color:#CCCCCC;
font-family: verdana, sansans-serif;
font-size: 18px;
}

dieses background-color werfen wir aus der css raus (kurzer kommentar da hin,
dass der default-background-color ueber die config.ini gesetzt wird)

in der config.ini machen wir ein:

;
; Stylesheet Defaultwerte
;
body.background.color = #CCCCCC

in der user-tabelle gibt es ebenfalls eine spalte, die default NULL ist.
in PHP wird nach dieser spalte gefragt, wenn gesetzt -> nutzen, wenn nicht
defaultwert aus config nehmen. das assignen wir zu smarty rueber und binden es
in den haeder ein:

<STYLE type="text/css">
body {ldelim}background-color: {$backgroundColor}{rdelim}
</STYLE>

So mal mein erster theoretischer Loesungsweg, hex-codes nachtraeglich
einzuspeisen, sodass sie von smarty geparsed werden