Структура каталогов для веб-сайта (папки js / css / img)


9

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

<root>
  ->js
    ->jquery.js
    ->tooltip.js
    ->someplugin.js
  ->css
    ->styles.css
    ->someplugin.css
  ->images
    -> all website images...

мне казалось, что это прекрасно, пока я не начал использовать разные сторонние компоненты.
Например, сегодня я скачал компонент javascript средства выбора даты и времени, который ищет свои изображения в том же каталоге, где находится его css-файл (css-файл содержит URL-адреса, такие как "url ('calendar.png')").

Так что теперь у меня есть 3 варианта:

1) Поместите datepicker.css в мой каталог css и поместите его изображения. Мне не очень нравится эта опция, потому что у меня будут файлы css и изображения внутри каталога css, и это странно. Также я могу встретить файлы из разных компонентов с одинаковыми именами, например 2 разных компонента, которые ссылаются на background.png из своих css файлов. Мне придется исправить эти конфликты имен (переименовав один из файлов и отредактировав соответствующий файл, содержащий ссылку).

2) поместите datepicker.css в мой каталог css, поместите его изображения в каталог images и отредактируйте datepicker.css, чтобы найти изображения в каталоге images. Этот вариант подходит, но мне нужно потратить некоторое время на редактирование сторонних компонентов, чтобы они соответствовали структуре моего сайта. Опять же, здесь могут возникнуть конфликты имен (как описано в предыдущем варианте), и мне придется их исправить.

3) поместите datepicker.js, datepicker.css и его изображения в отдельный каталог, скажем, / 3rdParty / datepicker / и поместите файлы так, как это было задумано автором (например, / 3rdParty / datepicker / css / datepicker) .css, /3rdParty/datepicker/css/something.png и т. д.). Теперь я начинаю думать, что этот вариант самый правильный.

Опытные веб-разработчики, что вы рекомендуете?

Ответы:


9

Я всегда создаю каталог lib для сторонних компонентов, вы действительно не хотите менять сторонние библиотеки, если это не является строго необходимым.

Перейти с 3-го варианта.


2

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

myapp/
  ui/ # or "www"
    lib/ # third-party
      jquery/
      sugarjs/
      backbone/
      underscore/
    app/ # application logic
      main.js
      router.js
      views.js
      models.js
    style/ # all presentation
      main.css
      buttons.css
      icons/
        add.svg
        log.png
      img/
        logo.png
        signup.png
    components/ # standalone bundles of html/css/js, if necessary
  server/ # or "api" (all server-side logic)

0

Вариант № 2 также не практичен и опасен, поскольку вам придется повторно применять все ваши изменения (и, следовательно, некоторые из них могут забыть) при обновлении сторонних библиотек. Это, безусловно, большой нет, нет! Варианты № 1 и № 3 имеют свои преимущества и недостатки. Так что я обычно иду на комбинацию обоих.

Мое решение состоит в том, чтобы использовать Вариант № 1 для моих файлов и использовать Вариант № 3 для сторонних библиотек.

Пример:

<root>
  -> js
    -> jquery.js
    -> main.js
  -> css
    -> reset.css
    -> style.css
  -> img
    -> img1.jpg
    -> img2.jpg
  -> lib
    -> someplugin1
      -> original folder/file structure of this plugin
    -> someplugin2
      -> original folder/file structure of this plugin
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.