Каковы ваши советы по наилучшей практике для структуры веб-приложений?

Я работаю над множеством пользовательских приложений. Я пытаюсь определить некоторые стандарты для новых приложений. Что-то вроде Элементов.

CSS. Как вы упорядочиваете таблицы стилей? Должен ли я иметь одну базовую таблицу стилей для всего сайта и по одной для каждой отдельной страницы для настроек? Должен ли я иметь другой для стилей печати? Я слышал, что для связывания большего количества файлов требуется больше времени, чтобы браузер их извлекал. (Больше объектов на странице... также проблема с большим количеством файлов или изображений javascript)... Сколько их слишком много? Вы сильно комментируете свой CSS? Предоставить любую вложенную структуру? Алфавит внутри элементов? Нужен ли мне reset? Как насчет импорта? И типография?

Javascript. В принципе, тот же вопрос. Файлы Javascript... Должен ли я включать одну или две красивые библиотеки (например, JQuery и Prototype), а затем добавить другую для каждой страницы? Теперь я внезапно включаю 5 или 6 файлов CSS и JS...

Структура каталогов. Как вы организовываете сайт? В настоящее время я использую что-то вроде

/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

Кроме того, любые другие советы будут приветствоваться. Спасибо!!

Ответы

Ответ 1

Должен ли я иметь одну базовую таблицу стилей для всего сайта и по одной для каждой отдельной страницы для настроек?

Будьте прагматичны. Если у вас мало правил, вы можете организовать их все в одном файле и сохранить контроль над тем, что что-то делает, сделайте это. Если у вас есть значительное количество правил, которые применяются только к определенным разделам или отдельным страницам вашего сайта, непременно их разломайте в свои собственные таблицы стилей, но не чувствуйте необходимости создавать отдельную таблицу стилей для каждой отдельной страницы даже если он содержит только два правила. Добавьте класс или идентификатор страницы в <body> , чтобы вы могли выделять отдельные страницы из общей таблицы стилей, если вам нужно.

Разделение стилей на таблицы стилей для вашей пользы как автора, поэтому сделайте то, что вам легче всего управлять. Для сложного сайта, который, вероятно, будет более одного файла CSS, но он не будет десятки.

Должен ли я иметь другой для стилей печати?

Вообще-то да. Хотя вы можете встроить стили печати в другую таблицу стилей с помощью правила @media, это традиционно было ошибкой, поэтому размещение медиа в теге <link> обычно проще всего. В любом случае таблицы стилей печати часто настолько отличаются от их сопоставлений с экраном, что имеет смысл сохранять свои правила отдельно.

Я слышал, что для связывания большего количества файлов требуется больше времени, чтобы браузер мог их восстановить.

Да, но этот эффект часто завышается. HTTP/1.1 уменьшает задержку для каждого запроса, поддерживая соединения между клиентом и сервером, что является сильным смягчением.

Сколько их слишком много?

Достаточно того, что у вас маловероятно, чтобы у вас было много таблиц стилей. Сценарии могут быть проблемой, если вы используете тип фреймворка, который требует один файл script для каждого класса, но в остальном, как правило, это нормально. Это чаще всего проблематично с большим количеством небольших изображений.

Вы сильно комментируете свой CSS?

Легкого комментирования обычно должно быть достаточно. Стиль декларативного правила CSS обычно не становится достаточно сложным, чтобы потребовать подробный код объяснения, который может потребоваться. В частности, однако, документируйте что-нибудь противоречивое, как взломы, специфичные для браузера.

Алфавит в элементах?

Нет, если это не облегчит вам управление. Обычно это не так, вы бы попытались сгруппировать аналогичные правила или правила, применяемые к подобным группам элементов.

Нужен ли мне reset?

Полный reset? Если вы не знаете, что делаете, и можете выбрать конкретные проблемы по умолчанию, которые вы хотите использовать reset.

Должен ли я включать одну или две красивые библиотеки (например, JQuery и Prototype)

Не включайте более одного фреймворка, если вам не нужно.

а затем включить другую для каждой страницы?

Если каждая страница имеет особое пользовательское поведение, вы можете. Но это обычно не происходит. Если вы создаете сценарии поведения с прогрессивным улучшением, которые привязаны, например. имена классов, вы можете включить script для каждого поведения на каждой странице, которая его использует, а затем позволить автоматически находить элементы для привязки.

Структура каталога: как вы организовываете сайт?

Лично для моих приложений Python/WSGI:

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

Мне важно сохранить "данные в отдельном месте (с отдельными разрешениями) для приложения в" системе ". Вы должны иметь возможность поменять" системную папку" для обновления приложения, не опасаясь, что есть загруженные изображения в htdocs/img, которые вам нужно беспокоиться о сохранении.

Ответ 2

CSS: Я использую только одну таблицу стилей. Я просто продолжаю прикладываться к дну, когда я иду. Обычно я помещаю комментарий перед каждым набором правил, специфичных для каждой страницы. Ctrl + F, если мне нужно что-то редактировать.

Javascript: Обычно включают только одну библиотеку и, возможно, несколько плагинов. Используется для того, чтобы бросить любую JS-страницу непосредственно в заголовок этой страницы, но я нахожу ее немного уродливой и смешивает "поведение" с данными. Поэтому я начинаю новую парадигму -

MVCB. Модель, представление, контроллер, поведение. MVC отлично подходит для настольных приложений с довольно статическими пользовательскими интерфейсами, но когда вы добавляете много JS, я думаю, что он требует дополнительного слоя абстракции.

Таким образом, моя исходная структура файла:

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]

Ответ 3

Я разместил свою структуру каталогов и комментарии в другом потоке, но это применимо и здесь!

Я использую следующую настройку в течение некоторого времени с отличными результатами:

  • /site: Здесь будет жить мой фактический рабочий сайт. Я установил свою CMS или платформу в этот каталог после создания шаблонов.

    • .htaccess(основные настройки, которые я обычно оказываю себе в любом случае)
    • robots.txt(поэтому я не забываю запрещать такие элементы, как /admin позже).

  • /source: содержит любые команды, заметки, документы, спецификации и т.д.

  • /шаблоны: Начните здесь! Создайте все статические шаблоны, которые в конечном итоге необходимо будет портировать в CMS или структуру/сайт.

    • /_ поведение
      • global.js(код сайта, может быть разбит на несколько файлов по мере необходимости)

    • /_ media: Изображения, загружаемые файлы и т.д. Организуется при необходимости

    • /_ style: Я предпочитаю модульную разработку CSS, поэтому я обычно получаю много таблиц стилей для каждого уникального раздела веб-сайта. Это сильно очищено Blender - Я настоятельно рекомендую этот инструмент!

      • print.css(это в конечном итоге смешивается, поэтому используйте печать @media)
      • reset.css(Эрик Мейер)
      • screen.css(для экрана @media, handheld)
      • дополнительные модули при необходимости

    • /_ vendor: весь сторонний код (jQuery, shadowbox и т.д.)

    • Blendfile.yaml(для Blender, см. выше)

    • template.html(базовый шаблон запуска, может быть скопирован и переименован для каждого уникального шаблона)

  • /tests: Selenium модульные тесты

Ответ 4

Просто убедитесь, что вы не используете заглавные буквы для папок. Это может укусить вас, когда вы разрабатываете окна и развертываете на сервере Linux.

Ответ 5

Сделайте все возможное, чтобы иметь одну таблицу стилей. Связывание отдельных таблиц стилей для отдельных страниц поражает цель.

Вы можете наследовать другие таблицы стилей в своем CSS, включая следующие строки в верхней части листа

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

В этом случае я наследую стили css проекта, добавляя ниже свои пользовательские стили.

В терминах JS-библиотек я предпочитаю связывать 3 файла.

Библиотека, одна страница со всеми плагинами, и, наконец, код страницы.

Для структуры каталогов я обычно имею следующее:

/_ CSS /_изображений /_scripts Файлы

но в последнее время я начал использовать все, чтобы сайт выглядел/работал так, как я хочу, чтобы он был в каталоге /_presentation... тогда что-нибудь дополнительное, как изображения для сообщений в блогах и т.д., включалось бы /images

Надеюсь, что это поможет.

Ответ 6

Я всегда стараюсь, чтобы браузер не загружал и не интерпретировал CSS-правила и JS-код, который не используется в рассматриваемом HTML. Я согласен с @bobince в том, что вам нужно только сломать стили и скрипты страниц в отдельный файл, если это необходимо для организации, но если ваш сайт очень большой, вы достигнете этой точки.

Однако, поскольку я только создаю сайты на основе шаблонов, я начинаю задаваться вопросом, почему я вообще привязываюсь к внешним файлам. Например, если у меня есть базовый шаблон, то вещи, которые я помещаю в голову этого шаблона, будут применяться ко всем страницам моего сайта. Так почему бы просто не поместить мои стили и скрипты?

Приходят на ум две причины. Сначала браузер может кэшировать внешний файл и повторно использовать его на каждой странице, которая включает его, не загружая его снова и снова. Во-вторых, дизайнеры могут быть не так удобны в ваших шаблонах, поскольку они возились с простыми файлами CSS.

Что хорошо и хорошо для глобальных стилей, которые применяются к каждой отдельной странице вашего сайта, но как насчет тех одноразовых страниц, которые имеют какой-то стиль, который не используется нигде? Если вы добавили этот стиль к глобально примененному внешнему файлу, вы увеличили начальное время загрузки вашего сайта, чтобы иметь стиль, который используется только на одной странице. Кроме того, когда вы вернетесь к этому файлу через несколько месяцев, вы, вероятно, забудете, для чего были эти правила.

Я предлагаю, чтобы любое правило стиля, которое не выражено на каждой отдельной странице, должно быть помещено в теги <style> в подшаблоне, которое отображает HTML, к которому применяется правило. Это переместит нагрузку и сложность с глобальной таблицы стилей на фактическую страницу, где нужны стили, и дайте контекст правил, чтобы они могли поддерживаться в будущем. Если это пугает вашего дизайнера, им не нужно писать CSS в любом случае. Просто скажите им, чтобы они придерживались Photoshop и позволяли вам выполнять работу большого мальчика.