2009-02-26 14 views
25

Ich mache viele benutzerdefinierte Anwendungen bei der Arbeit. Ich versuche einige Standards für neue Anwendungen zu definieren. Etwas wie Elemente.Was sind Ihre Tipps für Best Practices für die Webanwendungsstruktur?

CSS: Wie organisieren Sie die Stylesheets? Soll ich ein Basis-Stylesheet für die gesamte Site und eines für jede einzelne Seite für Anpassungen haben? Sollte ich einen anderen für Druckstile haben? Ich habe gehört, dass das Verknüpfen mehrerer Dateien mehr Zeit benötigt, damit der Browser sie abrufen kann. (Mehr Objekte pro Seite ... auch ein Problem mit vielen Javascript-Dateien oder Bildern) ... Wie viele sind zu viele? Haben Sie Ihr CSS stark kommentiert? Stellen Sie eine verschachtelte Struktur bereit? In Elementen alphabetisieren? Benötige ich einen Reset? Was ist mit Importen? Und Typografie?

Javascript: Grundsätzlich die gleiche Frage. Javascript-Dateien ... Soll ich ein oder zwei nette Bibliotheken (zB JQuery und Prototype) einbinden und dann für jede Seite ein anderes enthalten? Jetzt habe ich plötzlich 5 oder 6 CSS- und JS-Dateien ...

Verzeichnisstruktur: Wie organisieren Sie eine Website? Derzeit verwende ich etwas wie

/CSS   ... For CSS files 
/JS   ... For javascript files 
/INC   ... For private code includes 
/ASSETS/IMG ... For images 
/ASSETS/AU ... For audio 
/ASSETS/SWF ... For Flash 

Auch alle anderen Tipps wären willkommen. Vielen Dank!!

+0

interne Seiten? Oder extern? –

+0

Im Allgemeinen handelt es sich um interne Sites, die datengetrieben sind und größtenteils mit ASP.NET geschrieben wurden (aber oft mit Java, PHP oder anderen Technologien ...). Ich möchte eine "Routine" für alle etablieren meine Entwürfe werden auch extern sein. –

+0

Große Frage. Ich freue mich auch auf einige Antworten! – HardCode

Antwort

23

Sollte ich ein Basis-Stylesheet für die gesamte Site und eins für jede einzelne Seite für Anpassungen haben?

Seien Sie pragmatisch. Wenn Sie wenige Regeln haben, die Sie alle in einer Datei organisieren können und behalten Sie eine Übersicht darüber, was was macht, tun Sie das. Wenn Sie eine große Anzahl von Regeln haben, die nur für bestimmte Abschnitte oder einzelne Seiten Ihrer Site gelten, sollten Sie sie auf jeden Fall in ihre eigenen Sub-Stylesheets aufteilen, aber nicht das Bedürfnis haben, für jede einzelne Seite ein eigenes Stylesheet zu erstellen auch wenn es nur zwei Regeln enthält.Fügen Sie eine seitenspezifische Klasse oder ID zu < body> hinzu, damit Sie bei Bedarf aus einem freigegebenen Stylesheet einzelne Seiten auswählen können.

Die Trennung von Stilen in Stylesheets ist zu Ihrem Vorteil als Autor, also tun Sie das, was Sie am einfachsten zu verwalten finden. Für eine komplizierte Website wird es wahrscheinlich mehr als eine CSS-Datei geben, aber es werden nicht Dutzende sein.

Sollte ich ein anderes für Druckstile haben?

Allgemein ja. Während Sie Druckstile in ein anderes Stylesheet einbetten können, indem Sie eine @ media-Regel verwenden, war dies bisher oft fehlerhaft. Daher ist es am einfachsten, das Medium in das link> -Tag < zu setzen. In jedem Fall sind Druck-Stylesheets oft so verschieden von ihren Bildschirmgegenstücken, dass es einfach Sinn macht, ihre Regeln getrennt zu halten.

Ich habe gehört, dass das Verknüpfen von mehr Dateien dauert mehr Zeit für den Browser, um sie abzurufen.

Ja, aber dieser Effekt wird oft übertrieben. HTTP/1.1 reduziert die Latenz pro Anfrage, indem Verbindungen zwischen Client und Server aufrechterhalten werden, was eine starke Minderung darstellt.

Wie viele sind zu viele?

Genug, dass Sie extrem viele Stylesheets haben. Skripte können ein Problem darstellen, wenn Sie die Art von Framework verwenden, die eine Skriptdatei pro Klasse erfordert, ansonsten aber im Allgemeinen in Ordnung sind. Es ist häufiger problematisch mit vielen kleinen Bildern.

Haben Sie Ihr CSS stark kommentiert?

Lichtkommentar sollte normalerweise ausreichen. Der deklarative Regelstil von CSS wird normalerweise nicht kompliziert genug, um den detaillierten Erläuterungscode zu verlangen. Dokumentieren Sie insbesondere alles Intuitive wie browserspezifische Hacks.

Alphabetisch innerhalb von Elementen?

Nicht, es sei denn, es erleichtert Ihnen die Verwaltung. Normalerweise würden Sie nicht versuchen, ähnliche Regeln oder Regeln für ähnliche Elementgruppen zu gruppieren.

Benötige ich einen Reset?

Ein vollständiger Reset? Nicht, wenn Sie wissen, was Sie tun, und Sie können die speziellen problematischen Standardeinstellungen auswählen, die Sie zurücksetzen möchten.

Soll ich eine oder zwei nette Bibliotheken (JQuery und Prototype, zum Beispiel)

nicht mehr als einen Rahmen Sie sind, wenn Sie absolut zu haben.

und dann noch eine weitere für jede Seite enthalten?

Wenn jede Seite ein bestimmtes benutzerdefiniertes Verhalten hat, könnten Sie. Aber das passiert normalerweise nicht. Wenn Sie progressive-enhancement-Verhaltensskripts erstellen, die z. Klassennamen können Sie das Skript für jedes Verhalten auf jeder Seite einfügen, die es verwendet, und dann die Elemente finden, an die automatisch gebunden werden soll.

Verzeichnisstruktur: Wie organisieren Sie eine Website?

persönlich für meinen Python/WSGI Anwendungen:

appfolder 
    application.py  - main WSGI entry point and control/configuration script 
    data     - run-time writable application file store 
     private   - files not available through the web server 
     public   - mounted as a virtual directory on the web server 
    logs     - access, error, application log files 
    system    - all the static application code and data 
     htdocs   - web server root folder 
      file   - static servable files 
      img   - static images 
      script  - JavaScript 
      style  - CSS 
     lib    - Python modules used by site 
      appmodule - main application code package 
     templates  - HTML page templates 
      mail   - mail text templates 

Es ist wichtig für mich, in einem separaten Ort, um die ‚Daten‘ zu halten (mit separater Berechtigung) für die Anwendung in ‚System‘. Sie müssen in der Lage sein, den "System" -Ordner zu wechseln, um die Anwendung zu aktualisieren, ohne befürchten zu müssen, dass Bilder in htdocs/img hochgeladen werden, um die Sie sich kümmern müssen.

+0

Wenn Sie das über mod_wsgi hosten, würde ich sehr empfehlen, dass Sie "application.py" nicht in einem Verzeichnis haben, das etwas anderes enthält, insbesondere keine Unterverzeichnisse, die sensible Daten wie Konfigurationsdateien oder Code enthalten. Dies liegt daran, dass Sie Apache für das Verzeichnis 'application.py' in 'Allow from all' setzen müssen. Damit kann Apache Dateien aus dieser Verzeichnisstruktur bereitstellen. Wenn eine URL jetzt versehentlich diesem Verzeichnis zugeordnet wurde, können Clients das herunterladen, was sie wollen. Besser, es in einem Unterverzeichnis zu haben und nur auf dieses spezifische Unterverzeichnis zuzugreifen. –

+0

Persönlich benutze ich überhaupt nicht mod_access, es ist noch nicht einmal kompiliert; Ich denke nicht, dass es eine sehr effektive Maßnahme ist. – bobince

1

Tun Sie Ihr Bestes, um ein Stylesheet zu haben. Die Verknüpfung einzelner Stylesheets für einzelne Seiten vereitelt den Zweck.

Sie können andere Sheets in Ihrem CSS erben, indem Sie die folgenden Zeilen an der Spitze des Blattes einschließlich

@import url('blueprint/screen.css'); 
@import url('blueprint/styles.css'); 

in diesem Fall bin ich erben die CSS Plan Stile meine benutzerdefinierte Stile unter dem dann hinzufügen.

In Bezug auf JS-Bibliotheken bevorzuge ich 3 Dateien zu verknüpfen.

Die Bibliothek, eine Seite mit allen Plugins, und schließlich der Seitencode.

Für Verzeichnisstruktur I haben in der Regel die folgenden:

/_css /_images /_scripts Dateien

aber vor kurzem habe ich begann alles zu setzen verwendet, um die Website aussehen zu lassen/arbeiten, um die Art und Weise Ich will es in einem/_presentation Verzeichnis ... dann alles Weitere wie Bilder für Blog-Beiträge usw. gehen würde/Bilder

Hoffe, dass dies hilft.

3

Ich habe meine Verzeichnisstruktur und Kommentare in einem anderen Thread gepostet, aber es gilt auch hier!

Ich habe seit einiger Zeit mit sehr guten Ergebnissen der folgenden Einstellung mit:

  • /site: Dies ist, wo meine eigentliche Arbeits Website wird leben. Ich werde meinen CMS oder meine Plattform in diesem Verzeichnis installieren, nachdem die Vorlagen erstellt wurden.

    • .htaccess (Grund zwickt ich mich in der Regel finden ermöglichen sowieso)
    • robots.txt (so vergesse ich nicht später Gegenstände wie/admin nicht zulassen)
  • /source: Enthält alle Kompositionen, Notizen, Dokumente, Spezifikationen usw.

  • /vorlagen: Beginnen Sie hier! Erstellen Sie alle statischen Vorlagen, die eventuell in den CMS oder das Framework von/site portiert werden müssen.

    • /_behavior
      • global.js (ortsspezifischen Code, in mehrere Dateien aufgeteilt, wie erforderlich sein kann)
    • /_media: Bilder, Download-Dateien, etc. Nach Bedarf organisiert

    • /_style: Ich bevorzuge modulare CSS-Entwicklung, so dass ich normalerweise mit vielen Stylesheets für jeden einzelnen Abschnitt enden der Website. Dies ist sehr sauber mit Blender - ich empfehle dieses Tool!

      • print.css (dies wird schließlich vermischt, so verwenden @media print)
      • reset.css (Eric Meyer's)
      • Bildschirm.css (für @media Bildschirm, Handheld)
      • zusätzliche Module wie nötig
    • /_vendor: alle 3rd-Party-Code (jQuery, shadowbox etc.)

    • Blendfile.yaml (für Blender; siehe oben)

    • template.html (grundlegende Startvorlage; kann für jede eindeutige Vorlage kopiert und umbenannt werden)
  • /Tests: Selenium Unit-Tests

0

Ich versuche immer, um den Browser zu verhindern, mit CSS-Regeln und JS-Code zu laden und zu interpretieren, die nicht auf dem HTML-Code in Frage verwendet wird. Ich stimme @bobince zu, dass Sie die Styles und Scripts einer Seite nur dann in eine separate Datei aufteilen sollten, wenn dies für die Organisation erforderlich ist. Wenn Ihre Site jedoch sehr groß ist, werden Sie diesen Punkt erreichen.

Da ich jedoch nur Template-basierte Websites erstelle, frage ich mich, warum ich überhaupt auf externe Dateien verlinke. Wenn ich zum Beispiel eine Basisvorlage habe, werden die Dinge, die ich in den Kopf dieser Vorlage lege, auf alle Seiten meiner Website angewendet. Warum also nicht einfach meine Styles und Scripts dort hinstellen?

Zwei Gründe kommen in den Sinn. Zuerst kann der Browser die externe Datei zwischenspeichern und sie auf jeder Seite wiederverwenden, ohne sie erneut zu laden. Zweite Designer sind möglicherweise nicht so bequem in Ihren Vorlagen herumzustochern, wie sie mit einfachen CSS-Dateien herumspielen.

Das ist alles gut und gut für globale Stile, die für jede einzelne Seite in Ihrer Website gelten, aber was ist mit diesen einmaligen Seiten, die einen Stil haben, der nirgendwo anders geteilt wird? Wenn Sie diesen Stil zu einer global angewendeten externen Datei hinzugefügt haben, erhöhen Sie die anfängliche Ladezeit Ihrer Site, nur um einen Stil zu haben, der nur auf einer Seite verwendet wird. Wenn Sie Monate später zu dieser Datei zurückkehren, werden Sie wahrscheinlich vergessen haben, wofür diese Regeln überhaupt gelten.

Ich schlage vor, dass jede Stilregel, die nicht auf jede einzelne Seite ausgedrückt wird sollte in <style>-Tags innerhalb der Untervorlage platziert werden, die die HTML macht die Regel angewendet wird. Dadurch werden die Last und die Komplexität vom globalen Stylesheet auf die tatsächliche Seite verschoben, auf der die Styles benötigt werden, und der Regelkontext wird so definiert, dass er in Zukunft beibehalten werden kann. Wenn dies Ihren Designer erschreckt, müssen sie CSS sowieso nicht schreiben. Sag ihnen einfach, dass sie sich an Photoshop halten und die Big-Boy-Arbeit machen.

+0

Ich wusste, dass das keine sehr populäre Meinung sein würde :-) Aber ich freue mich sagen zu können, dass ich dies in die Praxis umgesetzt habe. Es ist besonders praktisch während der Entwicklung, wenn Sie nicht wollen, dass zwischengespeicherte Kopien von externen CSS-Dateien herumhängen, um Sie zu verwirren. – arkanciscan

3

Stellen Sie sicher, dass Sie keine Großbuchstaben für Ordner verwenden. Es kann Sie bei der Entwicklung auf Windows und bei der Bereitstellung auf einem Linux-Server beeinträchtigen.

8

CSS: Ich verwende nur ein Stylesheet. Ich bleibe einfach weiter unten, während ich weitergehe. Normalerweise gebe ich vor jedem seitenspezifischen Regelwerk einen Kommentar ab. Strg + F, wenn ich etwas bearbeiten muss.

Javascript: Normalerweise enthalten nur eine Bibliothek und vielleicht ein paar Plugins. Wird verwendet, um irgendwelche seitenspezifischen JS direkt in den Header dieser Seite zu werfen, aber ich finde es ein bisschen hässlich und mischt "Verhalten" mit Daten.So beginne ich ein neues Paradigma -

MVCB - Modell, Ansicht, Controller, Verhalten. MVC eignet sich hervorragend für Desktop-Anwendungen mit eher statischen Benutzeroberflächen. Wenn Sie jedoch viele JS hinzufügen, wird eine zusätzliche Abstraktionsebene benötigt.

So meine ursprüngliche Dateistruktur:

index.php 
app 
    config 
     bootstrap.php    -- code that needs to run before anything else, or functions that don't really fit elsewhere 
     core.php     -- timezone, database, and misc settings 
     routes.php     -- default routes 
    layouts       -- layout/template files 
     flash      -- layouts for one-time popup messages 
    objects       -- all files are stored in the same folder as the controller to keep directories 
              smaller and ease reusability 
     object 
      controller.php 
      model.php 
      routes.php    -- object-specific routes to override default routes 
      behaviours    -- page-specific javascript files 
       action.js   -- included automatically on that page if this file exists 
      views 
       action.php   -- the view for this action 
    public       -- static media files, sometimes called "assets" 
     favicon.ico 
     xrds.xml 
     css 
     img 
     js 
     uploads   
core 
    app.php       -- initializes stuff 
    controller.php     -- default controller 
    dispatcher.php     -- includes everything and calls all the appropriate functions 
    model.php      -- default model that all other models inherit from 
    components      -- helper functions to used in controllers 
    datasources      -- mysql, oracle, flat-file... 
    helpers       -- functions to be used in views and layouts 
    structures      -- model helpers such as tree or polymorphic behaviours 
    utils       -- functions that are useful everywhere 
libs        -- 3rd party libs 

.htaccess

Options -Indexes 

RewriteEngine On 

RewriteCond %{REQUEST_URI} !^/app/public/ 
RewriteCond %{DOCUMENT_ROOT}/app/public%{REQUEST_URI} -f 
RewriteRule .* /app/public/$0 [L] 

RewriteCond %{REQUEST_URI} !^/app/objects/ 
RewriteRule ^([^/]+)/(.+\.js)$ /app/objects/$1/behaviours/$2 [L] 

RewriteCond %{REQUEST_FILENAME} !-f 
RewriteRule .* /index.php?url=$0 [L,QSA] 
Verwandte Themen