Каталог шаблонов проектов веб-разработчика - PullRequest
16 голосов
/ 04 февраля 2009

ВАЖНО: Принятый ответ был принят за вознаграждение, не обязательно, потому что я чувствовал, что это был лучший ответ.


Я начинаю делать что-то снова и снова, когда начинаю новые проекты. Я создаю папку с подпапками, а затем копирую некоторые стандартные элементы, такие как файл сброса css, значки famfamfam, jquery и т. Д.

Это заставило меня задуматься о том, каким будет идеальный стартовый шаблон. Причина, по которой я спрашиваю, состоит в том, что я прохожу еще раз и задаюсь вопросом, что я должен включить в свой шаблон, чтобы мне не пришлось возвращаться в будущее и делать это снова и снова с каждым новым сайтом, который я запускаю .

Что у меня сейчас есть:

Папка шаблона проекта
  • index.html - XHTML 1.0 Strict Doctype. Мета-теги. Ссылки на CSS / js файлы.
  • CSS /
    • default.css - Пусто. Зарезервировано для пользовательских стилей.
    • 960 / - 960 Grid System для макетов CSS.
      • 960.css
      • reset.css
      • text.css
  • JS /
    • default.js - Пусто. Зарезервировано для пользовательских скриптов.
    • jQuery / - облегченный Javascript Framework
      • JQuery-1.3.1.min.js * * тысячу пятьдесят-одна
  • IMG /
    • famfamfam / - Отличная коллекция иконок png
      • Значки /
        • accept.png
        • add.png
        • ... и т.д.

Ответы [ 11 ]

8 голосов
/ 04 февраля 2009

У меня похожая структура и соглашение об именах, но для CSS я использую BluePrint , который, по моему мнению, является более расширяемым. Также предпочитаю, чтобы jQuery недавно переключился с прототипа. Кроме того, у меня есть файл common.js, который является расширением с пользовательскими функциями для jQuery.

A / db / папка с файлами .sql, содержащими определения схемы. A / lib / папка для общих библиотек среднего уровня.

У меня также будет папка / src /, в которой иногда будут находиться необработанные файлы, такие как шаблоны Photoshop, файлы readme, списки задач и т. Д.

3 голосов
/ 12 февраля 2009

Мой фреймворк для веб-разработки находится в git-репозитории. Общий код, такой как классы PHP общего назначения, разрабатывается в основной ветке. Вся работа для определенного веб-сайта выполняется на ветке, а затем изменения, которые помогут в дальнейшей работе, будут объединены с мастером.

Этот подход хорошо работает для меня, потому что у меня есть полный контроль над версиями всех веб-сайтов, и если мне удастся исправить ошибку или внедрить новую функцию во время работы над веткой, я могу выполнить слияние, и тогда все выиграет.

Вот как выглядит мой шаблон:

/
|-.htaccess            //mod_rewrite skeleton
|-admin/               //custom admin frontend to the CMS
|-classes/             //common PHP classes
|-dwoo/                //template system
|-config/              //configuration files (database, etc)
|-controllers/         //PHP scripts that handle particular URLs
|-javascript/
      |-tinyMCE/
      |-jquery/
|-modules              //these are modules for our custom CMS
      |-news/
      |-mailing_list/
      |-others
|-private/             //this contains files that won't be uploaded (.fla, .psd, etc)
      |-.htaccess      //just in case it gets uploaded, deny all
|-templates/           //template source files for dwoo
3 голосов
/ 11 февраля 2009

Если у вас много общих проектов со множеством статического контента (например, jquery, css framework и т. Д.), Сделайте себя медиасервером, который бы обслуживал все это. Затем вместо создания структуры папок из «шаблона» все, что вам нужно сделать, это включить нужные файлы в HTML вашего проекта. Если вам действительно нужен шаблон, ваш шаблон становится одним html-файлом вместо структуры каталогов.

Это также дает вам простой способ обновления статического носителя для ваших сайтов (например, переход на следующую версию 960). Вы должны сделать это только в одном месте. Конечно, вы все равно должны убедиться, что ваши обновления не нарушают существующие сайты! :)

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

Конечно, вы можете сделать это на небольшой виртуальной машине (например, linode ) за 20 долларов США в месяц или на виртуальном веб-сервере на вашем текущем веб-сервере. На самом деле вам не нужен сервер, просто вам нужна папка. Тем не менее, я думаю, что вы можете получить значительный прирост производительности, имея выделенные медиа-серверы. Я бы порекомендовал использовать для этой цели хорошо настроенный apache или nginx .

Что касается статических файлов, специфичных для сайта, также неплохо бы, чтобы они находились на медиасервере, и структура каталогов, вероятно, была бы именно такой, как у вас, но они будут / должны быть пустыми каталогами.

2 голосов
/ 13 февраля 2009

Я использую похожий макет, но с одним главным исключением: все эти каталоги находятся в директории media / верхнего уровня. Это по нескольким причинам:

  1. Этот каталог rsync'd для двух других серверов, которые обрабатывают все запросы статического носителя.
  2. Наличие нескольких хостов позволяет некоторым браузерам делать больше параллельных запросов для файлов поддержки.
  3. Каталог media / имеет свой собственный файл .htaccess, который удаляет каталог psuedo из пути, который является датой и временем последнего изменения образа (или чего-либо еще).

Пользовательский тег шаблона (я использовал это с 2 проектами Django, но вы могли бы сделать это в PHP и т. Д.) Генерирует URL, которые а) выбирают один из медиасерверов полуслучайно, б) добавляют основанный на времени псевдо-каталог к ​​пути, и c) дать объекту срок действия Expires + 10 лет.

1 голос
/ 13 февраля 2009

Мне нравятся OP в качестве начальной точки по умолчанию. Ваш стандартный шаблон должен ошибаться из-за простоты, с возможностью добавлять сложность, только если это необходимо.

одно дополнение:

/ robots.txt

1 голос
/ 12 февраля 2009

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

  • / site: Здесь будет жить мой действующий веб-сайт. Я установлю свою CMS или платформу в этом каталоге после создания шаблонов.
    • .htaccess (основные настройки, которые я в любом случае включаю)
    • robots.txt (поэтому я не забуду запретить такие элементы, как / admin позже)
  • / source: содержит все материалы, заметки, документы, спецификации и т. Д.

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

    .
    • / поведение
      • global.js (специфичный для сайта код; при необходимости может быть разбит на несколько файлов)
    • / media: изображения, загружаемые файлы и т. Д. Организованы по мере необходимости

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

      • поведение.css (любой стиль, для которого требуется браузер с поддержкой JS)
      • print.css (это в конечном итоге смешается, поэтому используйте @media print)
      • reset.css ( Эрик Мейер )
      • screen.css (для @media screen, handheld)
    • / vendor: весь сторонний код (jQuery, shadowbox и т. Д.)

    • Blendfile.yaml (для Blender; см. Выше)

    • template.html (базовый начальный шаблон; может быть скопирован и переименован для каждого уникального шаблона)
1 голос
/ 12 февраля 2009

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

Так что я бы посоветовал вам взять все дерево и вставить его в:

httpdocs/(all you had in your project template folder)

затем поместите весь свой код бэкэнда (например, библиотеки php, файлы sql и т. Д.) В соседние подкаталоги:

httpdocs/(all you had in your project template folder)
phplibs/
sql/

и т.д..

И, даже для вашего внешнего интерфейса, убедитесь, что вы не копируете файлы примеров, которые могут поставляться с вашими интерфейсными библиотеками, так как сами примеры могут иметь проблемы с безопасностью, которые позволят пользователям XSS или иным образом скомпрометируют ваш сайт.

1 голос
/ 12 февраля 2009

На работе мы используем Code Igniter в качестве PHP-фреймворка для наших веб-приложений и создали новый шаблон проекта, который делает именно это: Простая структура каталогов, Blueprint CSS, jQuery и папка приложения Code Igniter, заполненная парой общих используемые библиотеки (Аутентификация, некоторые специальные модели для часто используемых баз данных ...).

Основной девиз здесь: Всегда проще удалить компоненты, чем добавить их. Заполните ваш шаблон.

(А когда я в свободное время начинаю новый проект, я очень скучаю по этому шаблону ...)

1 голос
/ 12 февраля 2009

Мне определенно нравится идея иметь такую ​​папку с шаблонами скелетов, но если вы используете несколько разных технологий, обязательно обратите пристальное внимание на структуру. Моя структура папок VB.net имеет совершенно другую настройку по сравнению с PHP. Это звучит как здравый смысл, но я видел, как люди подходят к обоим одинаково.

1 голос
/ 11 февраля 2009

Очень искаженное представление MS, но мой SOP сейчас выглядит следующим образом:

  • Документация /
    • архитектура / (то, что вы можете назвать документацией кода)
    • связь / (важные документы клиента)
    • спецификация /
    • Официальные документы /
  • график /
    • *. СДП
  • источник /

    • com.mycompany.projectname.solutionA /
    • com.mycompany.projectname.solutionB /
    • com.mycompany.projectname.solutionC /
    • com.mycompany.projectname.solutionX / (проект в деловом смысле здесь)

      • BusinessLogic /
        • *. Cs (или что угодно)
      • (дальнейшие проекты - в визуальном студийном смысле)
      • сайт /

        • обработчики / (редко я использую фактический .html в наши дни)
        • модули /
        • ресурсы /

          • img / (pngs jpegs, gifs и т.д.)

            • кожа /
              • Значки /
              • фоны /
          • js / (сжато при публикации)

            • библиотека / (стандартный код)
            • common / (код приложения)
            • *. Js (код приложения, возможно, ноль)
          • CSS /
            • skinX / (даже если есть только «по умолчанию»)
              • extension.css
            • base.css
          • transforms / (всегда скрыты от общественности при настройке или процессе сборки)
            • *. * 1118 XSLT *
      • UnitTests /
        • издевается /
        • testmain.cs (или любой другой)
  • ThirdParty /
    • зависимости
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...