Проект веб-разработчика обрабатывает каталог по шаблону

Если у Вас есть много проектов с большим количеством статического содержания вместе (например, jQuery, платформа CSS, и т.д.) делают себя медиасервером для обслуживания всех они. Затем вместо того, чтобы создать набор структуры папок из "шаблона" все, что Вы делаете, включают правильные файлы в HTML Вашего проекта. Если Вы действительно хотите шаблон, Ваш шаблон становится одним файлом HTML вместо структуры каталогов.

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

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

можно, конечно, сделать это на маленьком VM (например, linode) за $20/мес или виртуальный веб-сервер на текущем веб-сервере. Вам действительно не нужен сервер, в этом отношении, Вам просто нужна папка. Однако я думаю, что у Вас может быть некоторое значительное увеличение производительности при наличии выделенные медиасерверы. Я рекомендовал бы использовать подстроенного апача или nginx с этой целью.

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

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

Моя платформа веб-разработки находится в репозитории мерзавца. Общий код, такой как классы 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

Я думаю, что структура хороша. Добавление нескольких других папок зависит от того, какую работу Вы завершаете.

Для фриланса и т.п., добавления папок PSD, клиентские комментарии были бы хорошим дополнением.

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

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

А пользовательский тег шаблона (я использовал это с 2 проектами Django, но Вы могли сделать это в PHP, и т.д.) генерирует URL, которые a) полуслучайным образом выбирают один из медиасерверов, b) добавляют основанный на времени псевдо каталог к пути и c) дают объект, Истекает время теперь + 10 лет.

Очень MS скошенное представление, но мой SOP прямо сейчас вроде:

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

• /

  • com.mycompany.projectname.solutionA/
  • com.mycompany.projectname.solutionB/
  • com.mycompany.projectnam e.solutionC/

  • com.mycompany.projectname.solutionX/ (проект в деловом чутье здесь)

    <ул.> <литий> businesslogic/<ул.> <литий> *.cs (или безотносительно) <литий> (дальнейшие проекты - в смысле Visual Studio) <литий>

    сайт /

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

  ресурсы /

  <ул.> <литий>

  img/ (pngs jpegs, gifs безотносительно)

  <ул.> <литий> кожа / <ул.> значки
  • /
  <литий> фоны / <литий>

  js/ (сжатый при публикации)

  <ул.> библиотека
  • / (стандартный код) <литий> общий / (приложение определенный код) <литий> *.js (приложение определенный код, надо надеяться, ноль) <литий> CSS / <ул.> <литий> skinX/ (даже если существует только "значение по умолчанию") <ул.> <литий> extension.css <литий> base.css <литий> преобразовывает / (всегда скрытый от общественности конфигурацией или процессом сборки) <ул.> <литий> *.xslt <литий> unittests/<ул.> <литий> насмешки /
  <литий> testmain.cs (или безотносительно)
• сторонний /
  • зависимости

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

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

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

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

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

и т.д.

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

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

основной девиз здесь: всегда легче удалить компоненты, чем добавить их. Поэтому заполните свой шаблон.

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

Я использовал следующую установку некоторое время теперь с большими результатами:

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

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

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

  • / поведение <ул.> <литий> global.js (сайт-специфичный код; может вспыхнуться в несколько файлов по мере необходимости)

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

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

    <ул.> <литий> behavior.css (любое моделирование, которое требует браузера JS-enabled) <литий> print.css (это в конечном счете смешивается, так используйте печать @media) <литий> reset.css ( Eric Meyer ) <литий> screen.css (для экрана @media, карманного компьютера)

  • / поставщик: весь сторонний код (jQuery, застекленная витрина, и т.д.)

  • Blendfile.yaml (для Блендера; посмотрите выше)

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

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

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

/robots.txt