Структура каталогу веб-сайту (папки 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, і це дивно. Також я можу зустріти файли з різних компонентів з тим самим іменем, як, наприклад, два різні компоненти, які посилаються на background.png зі своїх файлів css. Мені доведеться виправити ці зіткнення імен (перейменувавши один із файлів та відредагувавши відповідний файл, що містить посилання).

2) помістіть datepicker.css у свій каталог css, покладіть його зображення в каталог зображень та відредагуйте datepicker.css для пошуку зображень у каталозі зображень. Цей параметр нормальний, але мені доведеться витратити деякий час на редагування сторонніх компонентів, щоб вони підходили до моєї структури сайту. Знову тут можуть виникати зіткнення імен (як описано в попередньому варіанті), і мені доведеться їх виправити.

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.