Каталог шаблонов веб-разработчиков

Ответ 1

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

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

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

Ответ 2

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

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

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

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

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

Ответ 3

Моя инфраструктура веб-разработки находится в репозитории 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 скриптs 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

Ответ 4

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

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

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

Ответ 5

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

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

Ответ 6

Очень сжатый вид 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 whatever)

          • кожа /
            • Значки /
            • фоны /

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

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

Ответ 7

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

Ответ 8

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

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

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

Ответ 9

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

Итак, я предлагаю вам взять все свое дерево и поместить его в:

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

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

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

и т.д..

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

Ответ 10

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

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

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

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

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

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

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

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

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

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

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

Ответ 11

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

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

/robots.txt