Quels sont vos conseils pour de meilleures pratiques pour l'application de web structure?

Je fais beaucoup d'applications personnalisées au travail. Je suis en train de définir des normes pour les nouvelles applications. Quelque chose un peu comme Éléments.

CSS: Comment vous organisez-vous les feuilles de style? Dois-je avoir une base de feuille de style pour l'ensemble du site et un pour chaque page individuelle pour les personnalisations? Devrais-je en avoir une autre pour les styles d'impression? J'ai entendu dire que le fait de lier plusieurs fichiers prend plus de temps pour le navigateur afin de les récupérer. (Plus d'objets par page...également un problème avec beaucoup de fichiers javascript ou des images) ... Combien est trop? Avez-vous fortement à commenter votre CSS? Fournir toute la structure imbriquée? Classer par ordre alphabétique à l'intérieur des éléments? Ai-je besoin d'une remise à zéro? Ce sur les importations? Et de la typographie?

Javascript: Fondamentalement la même question. Les fichiers Javascript...dois-je inclure une ou deux belles librairies (JQuery et Prototype, par exemple) et puis une autre pour chaque page? Maintenant, je suis tout d'un coup, y compris 5 ou 6 les fichiers CSS et JS...

Structure de répertoire: Comment vous organisez-vous un site? Actuellement, je utiliser quelque chose comme

/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

Aussi, tous les autres conseils seraient les bienvenus. Merci!!

  • Site interne? Ou de l'extérieur?
  • Généralement parlant, ces sites internes qui sont pilotés par les données, et surtout écrit avec ASP.NET (mais souvent avec Java, PHP ou d'autres technologies...) cela étant dit, je voudrais mettre en place une "routine" pour tous mes dessins qui seront externes, trop.
  • Grande question. Je vais être à la recherche de réponses à certaines questions, trop!
InformationsquelleAutor | 2009-02-26
  1. 23

    Devrais-je avoir une base de feuille de style pour l'ensemble du site et un pour chaque page individuelle pour les personnalisations?

    Être pragmatique. Si vous avez assez peu de règles que vous pouvez organiser tous dans un seul fichier et de maintenir une surveillance de qu'est-ce que, le faire. Si vous avez un nombre important de règles qui ne s'appliquent qu'à certaines sections ou des pages de votre site, par tous les moyens de les sortir de leur propre sous-les feuilles de style, mais ne se sentent pas la nécessité de créer une feuille de style pour chaque page, même lorsqu'il ne contient que deux règles. Ajouter une page spécifique à la classe ou l'id <body>, de sorte que vous pouvez choisir de simples pages d'une feuille de style si vous avez besoin.

    La séparation des styles dans des feuilles de style est à votre avantage en tant qu'auteur, donc faire ce que vous trouver les plus faciles à gérer. Pour un complexe de site qui va probablement être plus d'un fichier CSS, mais ça ne va pas être des dizaines.

    Devrais-je en avoir une autre pour les styles d'impression?

    En général, oui. Alors que vous pouvez l'incorporer les styles d'impression à l'intérieur d'une autre feuille de style à l'aide d'une règle @media, ce qui a traditionnellement été buggy, afin de mettre les médias dans le <lien> tag est généralement plus facile. Dans tous les cas d'imprimer les feuilles de style sont souvent si différentes de leurs homologues écran qu'il est tout à fait logique pour garder leurs règles distinctes.

    J'ai entendu dire que le fait de lier plusieurs fichiers prend plus de temps pour le navigateur afin de les récupérer.

    Oui, mais cet effet est souvent surestimée. HTTP/1.1 réduit la demande de latence en gardant les connexions entre le client et le serveur en vie, ce qui est une forte atténuation.

    Combien est trop?

    Assez que vous êtes extrêmement rare d'avoir autant de feuilles de style. Les Scripts peuvent être un problème si vous utilisez le type de cadre qui exige un fichier de script par classe, mais sinon ils sont généralement OK. C'est plus souvent problématique avec beaucoup de petites images.

    Avez-vous fortement à commenter votre CSS?

    Lumière de commentaire devrait normalement suffire. CSS déclaratif de la règle de style n'a pas l'habitude de faire assez compliqué de besoin d'explications détaillées code peut exiger. En particulier si, document de quelque chose de contre-intuitif comme spécifiques à un navigateur hacks.

    Classer par ordre alphabétique à l'intérieur des éléments?

    Pas moins qui le rend plus facile pour vous de gérer. Habituellement, il ne serait pas, vous essayez de groupe, des règles ou des règles portant sur des groupes d'éléments.

    Ai-je besoin d'une remise à zéro?

    Une réinitialisation complète? Pas si vous savez ce que vous faites et peut sélectionner les problématiques les valeurs par défaut que vous souhaitez réinitialiser.

    Dois-je inclure une ou deux belles librairies (JQuery et Prototype, par exemple)

    Ne pas inclure plus d'un cadre sauf si vous devez absolument.

    et puis une autre pour chaque page?

    Si chaque page a coutume particulière de comportement que vous pourriez. Mais qui n'a généralement pas se produire. Si vous faites progressive d'amélioration des comportements des scripts qui se lient à des par exemple. les noms de classe, vous pouvez inclure le script pour chaque comportement sur chaque page qui l'utilise, puis de le laisser trouver les éléments de lier automatiquement.

    Structure de répertoire: Comment vous organisez-vous un site?

    Personnellement, pour mon Python/WSGI applications:

    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

    Il est important pour moi de conserver les "données" dans un endroit séparé (avec des autorisations distinctes) pour l'application du "système". Vous devez être en mesure de remplacer le "système" dossier pour la mise à niveau de l'application, sans avoir à se soucier qu'il y a des images téléchargées dans htdocs/img que vous avez à vous soucier de garder.

    • Si vous êtes d'hébergement que par le biais de mod_wsgi, j'aimerais beaucoup être recommander que vous n'avez pas 'application.py" dans un répertoire contenant rien d'autre, surtout pas les sous-répertoires contenant des trucs comme des fichiers de configuration ou de code. C'est parce que vous devez avoir mis "Allow from all" pour Apache sur le répertoire 'application.py' est dans. Qui dit Apache est autorisé à servir des fichiers à partir de l'arborescence de répertoire. Si une URL est maintenant connecté à ce répertoire, par inadvertance, les clients peuvent télécharger ce qu'ils veulent. Il vaut mieux l'avoir dans un sous-répertoire et seulement l'accès à ce sous-répertoire.
    • Personnellement je n'utilise pas mod_access à tous, il n'est même pas compilé, je ne pense pas que c'est une mesure très efficace.
    InformationsquelleAutor bobince
  2. 8

    CSS: je ne l'utilise une feuille de style. Je viens de continuer à ajouter du texte à la bas que je vais le long. J'ai l'habitude de placer un commentaire avant de chaque page-ensemble spécifique de règles. Ctrl+F si je dois modifier quelque chose.

    Javascript: comprennent Généralement une seule bibliothèque, et peut-être quelques plugins. Utilisé pour lancer une page spécifique à la JS directement dans l'en-tête de la page, mais je trouve ça un peu moche et mélanges "comportement" avec des données. Donc je commence un nouveau paradigme --

    MVCB -- Modèle, Vue, Contrôleur, le Comportement. MVC est idéal pour les applications de bureau avec plutôt statique de l'Isu, mais lorsque vous ajoutez beaucoup de JS je pense que cela appelle une couche d'abstraction supplémentaire.

    Ainsi, ma structure de fichier d'origine:

    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]
    InformationsquelleAutor mpen
  3. 3

    J'ai posté ma structure de répertoire et de commentaires dans un autre thread, mais il est applicable ici aussi!

    J'ai été en utilisant la configuration suivante pour un certain temps maintenant avec d'excellents résultats:

    • /site: C'est là que mon travail réel site de volonté de vivre. Je vais installer mon CMS ou de plate-forme dans ce répertoire après les modèles sont créés.

      • .htaccess (réglages de base j'ai l'habitude de me trouver à l'activation de toute façon)
      • robots.txt (je n'oublie pas de refuser des articles comme /admin plus tard)

    • /source: Contient des compositions, des notes, des documents, spécifications, etc.

    • /modèles: Commencez ici! Créer tous les modèles statiques qui auront éventuellement besoin d'être porté dans le CMS ou framework de /du site.

      • /_behavior
        • global.js (code spécifiques au site; peut être décomposée en plusieurs fichiers selon les besoins)

      • /_media: Images, fichiers à télécharger, etc. Organisé si nécessaire

      • /_style: je préfère modulaire CSS donc j'ai l'habitude jusqu'à la fin avec beaucoup de feuille de style pour chaque section unique du site. C'est nettoyé grandement avec Blender - je recommande fortement cet outil!

        • d'impression.css (ce qui finit par être mélangés, de sorte que l'utilisation de @media print)
        • de réinitialisation.css (Eric Meyer)
        • écran.css (pour les @media écran, de l'ordinateur de poche)
        • modules supplémentaires que nécessaire

      • /_vendor: tous les 3ème partie du code (jQuery, shadowbox, etc.)

      • Blendfile.yaml (pour Blender; voir ci-dessus)

      • template.html (basic template de départ; peut être copié et renommé pour chaque modèle unique)

    • /tests: Le sélénium tests unitaires

    InformationsquelleAutor Mark Hurd
  4. 3

    Assurez-vous de ne pas utiliser les majuscules pour les dossiers. Il peut vous mordre quand vous développer sur windows et les déployer sur un serveur linux.

    InformationsquelleAutor cherouvim
  5. 1

    Faire de votre mieux pour avoir une feuille de style. La liaison de plusieurs feuilles de style pour les pages individuelles de défaites le but.

    Vous pouvez hériter d'autres feuilles de style dans votre css en incluant les lignes suivantes en haut de la feuille

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

    dans ce cas, je suis d'hériter le plan des styles css puis ajouter mes styles personnalisés en dessous.

    En termes de bibliothèques JS je préfère lien 3 fichiers.

    La Bibliothèque,
    une page avec tous les plugins,
    et enfin le code de la page.

    Pour la structure de répertoire j'ai généralement la suivante:

    /_css
    /_images
    /_scripts
    fichiers

    mais récemment, j'ai commencé à mettre tout ce qui sert à rendre le site de look/travail de la façon dont je veux qu'elle en a /_presentation répertoire... puis rien supplémentaires comme des images de billets de blog, etc, irait dans le /images

    Espère que cette aide.

    InformationsquelleAutor Birk
  6. 0

    J'essaie toujours de garder le navigateur de charger et d'interpréter les règles CSS et JS code qui n'est pas utilisé sur la HTML en question. Je suis d'accord avec @bobince que vous ne devez casser une page styles et des scripts dans un fichier distinct, si elle est nécessaire pour l'organisation, mais si votre site est très grande, vous atteignez ce point.

    Cependant depuis que j'ai seulement construire à partir de modèles de sites, je commence à me demander pourquoi je lien vers des fichiers externes à tous. Par exemple, si j'ai un modèle de base les choses que j'ai mis dans la tête de ce modèle sera appliqué à toutes les pages de mon site. Alors, pourquoi ne pas simplement mettre mes styles et scripts?

    Deux raisons viennent à l'esprit. D'abord le navigateur met en cache le fichier externe et de le réutiliser sur chaque page qui inclut, sans avoir à le charger une fois de plus. Deuxième concepteurs pourraient ne pas être aussi à l'aise de fouiller dans vos modèles qu'elles sont gâcher avec de la plaine des fichiers CSS.

    C'est tout bon pour les styles globaux qui s'appliquent à chaque page de votre site, mais que dire de ces one-off des pages qui ont un style qui n'est pas partagée partout ailleurs? Si vous avez ajouté ce style à l'échelle mondiale appliquée fichier externe vous avais augmentation initiale de temps de chargement de votre site juste pour avoir un style qui n'est utilisé que sur une seule page. De plus, lorsque vous revenez à ce fichier mois plus tard, vous aurez probablement oublié ce que ces règles n'étaient même pour.

    Je suggère que toute règle de style qui n'est pas exprimé sur chaque page doit être placé dans <style> tags à l'intérieur du sous-modèle qui rend la HTML la règle s'applique. Cela vous permettra de déplacer la charge et de la complexité de la mondial de la feuille de style de la page en question, où les styles sont nécessaires, et de donner les règles de contexte, de sorte qu'ils peuvent être maintenus à l'avenir. Si cela fait peur à votre concepteur ils n'ont pas besoin d'être écrit CSS de toute façon. Dites-leur de coller à Photoshop et vous permettre de faire le grand garçon de travail.

    • Je savais que ce ne serait pas très populaire avis 🙂 Mais je suis heureux de dire que j'ai été la mise en pratique d'un bel effet. C'est particulièrement utile lors du développement quand vous ne voulez pas les copies mises en cache des fichiers CSS externes traîner pour vous confondre.
    InformationsquelleAutor Jesse Hattabaugh