Klaus: Wie findet ihr meinen Umgang mit CSS & Views(MVC-Pattern) ?

Hallo.

Meine Views sind folgend aufgebaut:

class View{

public function __construct(){}

public function giveCSS(){
  $css="
 .box{color:#000000;border:1px solid #000000}
 ";
  return $css;
 }

public function giveView(){
  $html="<div class='box'>Text</div>";
  return $html;
 }

}

Der Controller gibt mir am Ende ein Array zurück:

return array($instanz->giveView(), $instanz->giveCSS());

Der FrontController nimmt sich dann das CSS und packt es in eine CSS Datei und das HTML gibt er aus.

Was ich da für einen Vorteil sehe?

In meiner CSS Datei steht immer nur das was auch benötigt wird und bei größeren Projekten, wird der CSS-Code nicht ellenlang und unnötig groß.
Sprich die Seite wird schneller geladen.

Also ich lasse mir von jedem View den ich brauche, HTML und CSS geben so das nur das was man braucht ankommt.

Was haltet ihr davon?

Lieben Gruß,

wie immer "Wink" an Dedlfix,

Klaus

  1. Du hast offenbar das Konzept von CSS nicht ganz verstanden. Diese Stilbeschreibungssprache dient dazu, dass man nicht für jedes Objekt jede einzelne Eigenschaft komplett definieren muss, sondern Stilvorgaben finden kann, die aufeinander aufbauen.

    Gruß, LX

    --
    RFC 1925, Satz 3: Mit ausreichendem Schub fliegen Schweine wunderbar. (...)
  2. Meine Views sind folgend aufgebaut:

    class View{ ...

    Soweit ich Views aus MVC-Frameworks kenne, handelt es sich um Template-Dateien, die hauptsächlich aus HTML bestehen (oder XML oder was auch immer gewünscht ist). Klar, wenn du HTML *und* CSS an einer Stelle unterbringen willst, dann brauchst du eine Metasprache (hier PHP), die beides trennt.

    Was haltet ihr davon?

    Ehrlich gesagt gar nichts. Stylesheets sollte man abstrahieren und auslagern. Für die einzelne View sollte dann, wenn einem das gelungen ist, nur wenig individuelles Styling nötig sein. So wenig, dass du (letztlich) alles in einer Datei zusammenfassen kannst. Die kannst du vorkomprimieren, indem du überflüssige Kommentare und Whitespace entfernst (YUI Compressor), sie GZip-komprimiert ausliefern lässt und Expires-Header senden, sodass der Browser beim Laden einer weiteren Seite nicht erneut das Stylesheet abfragt (nicht einmal mit einem Conditional-GET). Damit hat der Browser mit einem Stylesheet fast alle Styles für deine Site - bei sehr kleiner Übertragungsmenge.

    Wenn du allerdings View für View eine eigene CSS-Datei laden lässt (oder ein style-Element im head einbindest), so geht das weder schneller noch sparst du unter dem Strich Ladezeit, übertragene Datenmenge und Serverlast ein. Es sei denn, dein Projekt ist soooo riesig, dass sich modulare Stylesheets anbieten. Aber dann wäre »View für View« kein passendes Konzept, um zusammengehörige Stylesheets zu gruppieren. Die Styles für die Controller/Actions, die nur selten genutzt werden, kannst du hinzu laden, aber unter dem Strich macht es mehr Sinn, die zusammengehörigen Styles in einer ausgelagerten Datei zusammenzufassen.

    Ich kann verstehen, dass du die Styles möglichst nah am zugehörigen HTML-Code haben willst. Das ist sicher zu einem gewissen Teil Geschmackssache, allerdings sehe ich auch kein Problem darin, verschiedene Stylesheet-Dateien nach Controllern anzulegen und sie mit CSSDOC nach Actions aufzuteilen. So weiß man immer, wo die zugehörigen Styles liegen, und das Zusammenfassen dieser Stylesheets ist beim Deployment einfach automatisierbar.

    Mathias

  3. Hallo

    damit vermischst du View und Controller und zerstörst eigentlich das MVC Pattern.

    Warum sollte es den Controller interessieren, was für Ressourcen ein View benötigt? Wenn ja, warum dann bei CSS aufhören, und nicht gleich Javascript, Bilder, Favicon, Flash dazu?

    Du kannst ausserdem deinen Viewtreiber nicht auswechseln, ein Consolenview wird vermutlich kein CSS verwenden, ein wxWidgets View noch weniger, soll heissen, deine Controller sind abhängig vom View und nicht auswechselbar.

    Lieben Gruß zurück

  4. Hallo,

    In meiner CSS Datei steht immer nur das was auch benötigt wird und bei größeren Projekten, wird der CSS-Code nicht ellenlang und unnötig groß.
    Sprich die Seite wird schneller geladen.

    Wie schon einige hier gepostet haben: CSS dynamisch zusammenzubauen ist vielleicht nicht ideal, auch Deine Einschätzung bezgl. Ladezeit würde ich nicht 100%tig teilen:
    Eine CSS-Datei(!) mag zwar zeimlich lang sein, sie ist aber dafür cachebar im Browser. Der User läd sie also nur einmal und dann nicht mehr (sofern er seinen Browser entsprechend konfiguriert hat).
    Wenn Dein CSS hingegen dynamisch zusammengebaut wird, besteht die Gefahr, dass der User das jedesmal von neuem läd.
    Generell fallen ASCII-Datein größentechnisch ohnehin nicht mehr so ins Gewicht, weil die meisten Webserver mit mod_gzip/mod_deflate ausliefern.

    Ein weiterer Punkt: Gerade bei größeren Systemen (und wenn Du Dir über die Ladezeiten von CSS-Dateien Gedanken machst, gehe ich davon aus, dass Du das zumindest in Erwägung ziehst) wird strikt getrennt zwischen Applikation/Business-Logik und (statischem) Content (gewissermaßen wird also der MVC-Ansatz dann auch ein Stück weit in Hardware vollzogen).
    Man stelle sich z.b. eine Webanwendung vor, bei denen die ganze Logik auf einem Application-Server läuft, während statischer Content (css, Bilder, statische HTML-Seiten wie z.b. für Hilfe o.ä.,...) über einen (oder mehrere) schnelle Webserver oder sogar ein Media-Distributio-Network passiert.
    Auch dafür ist es praktisch, CSS und PHP zu trennen.

    => Ich würde Deinen Ansatz vielleicht so ändern/erweitern, dass
    Du ein paar wenige CSS-Files hast, und ein View immer "weiß", welche CSS-Datei er einbinden muss, damit alles korrekt geladen wird - z.b. eine "general.css" die Styles beschreibt, die IMMER benötigt werden (menu, Header, Footer,...) und weitere Dateien, die dann auf die jeweiligen Views zugeschnitten sind.

    Jedenfalls spannendes thema, dass Du da aufgemacht hast.

    Hope that helps,

    Jörg

  5. echo $begrüßung;

    Zwei Punkte fallen mir auch noch ein.

    Der FrontController nimmt sich dann das CSS und packt es in eine CSS Datei und das HTML gibt er aus.

    Der Request nach der HTML-Ressource und der nach der CSS-Ressource sind zwei verschiedene. Angenommen, der CSS-Request wird vom Browser nicht gecachet, dann muss deine MVC-Maschine zweimal laufen. Du könntest denn CSS-Ablauf vielleicht abkürzen, wenn du nur Dummy-Daten zur View schickst, dann hast du aber immer noch umsonst die - ich nenn sie mal HTML-View - erstellt (respektive beim HTML-Request die CSS-View).

    Wenn ich mit deinen Satz aber nochmal genau ansehe, schwant mir, dass du wirklich beim HTML-Request eine Datei erstellst, die sich der CSS-Request dann quasi als statisches Element abholt. Und dieses Erstellen findet auch jedes Mal statt (was dann noch File-Locking erfordert) oder wird zumindest jedes Mal vorbereitet. Das bekommt man mit den bereits geposteten Vorschlägen ressourcenschonender hin.

    In meiner CSS Datei steht immer nur das was auch benötigt wird und bei größeren Projekten, wird der CSS-Code nicht ellenlang und unnötig groß. Sprich die Seite wird schneller geladen.

    Wenn du solch eine Vermutung anstellst, solltest du das auch praktisch messen. Und zwar am besten nicht nur mit einzelnen Requests im Labor sondern mit Tools wie dem ab2 (mit dem Apachen mitgeleifert), das den Server mit mehreren Requests "gleichzeitig" stressen kann. Vergleichsmessungen mit echtem statischen Content sollten dabei auch nicht fehlen.

    echo "$verabschiedung $name";