वेबसाइट के लिए निर्देशिका संरचना (js / css / img फ़ोल्डर्स)

Question

वर्षों से मैं अपनी वेबसाइटों के लिए निम्नलिखित निर्देशिका संरचना का उपयोग कर रहा हूं:

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

यह मेरे लिए बिल्कुल ठीक लग रहा था जब तक कि मैंने विभिन्न 3-पार्टी घटकों का उपयोग करना शुरू नहीं किया।
उदाहरण के लिए, आज मैंने एक डेटाइम पिकर जावास्क्रिप्ट घटक डाउनलोड किया है जो अपनी छवियों को उसी निर्देशिका में देखता है जहां इसकी सीएसएस फ़ाइल स्थित है (सीएसएस फ़ाइल में "url ('Calendar.png')" जैसे यूआरएल हैं।

तो अब मेरे पास 3 विकल्प हैं:

1) मेरे सीएसएस निर्देशिका में datepicker.css डालें और अपनी छवियों को साथ रखें। मुझे वास्तव में यह विकल्प पसंद नहीं है क्योंकि मेरे पास सीएसएस निर्देशिका के अंदर सीएसएस और छवि दोनों फाइलें होंगी और यह अजीब है। इसके अलावा, मैं एक ही नाम के साथ अलग-अलग घटकों की फ़ाइलों को पूरा कर सकता हूं, जैसे कि 2 अलग-अलग घटक, जो उनकी सीएसएस फ़ाइलों से पृष्ठभूमि.पिंग से लिंक करते हैं। मुझे उन नाम टकरावों को ठीक करना होगा (फाइलों में से किसी एक का नाम बदलकर और संबंधित फ़ाइल को संपादित करना जिसमें लिंक शामिल है)।

2) मेरे सीएसएस निर्देशिका में datepicker.css डालें, अपनी छवियों को छवि निर्देशिका में डालें और छवियों निर्देशिका में छवियों को देखने के लिए datepicker.css संपादित करें। यह विकल्प ठीक है, लेकिन मुझे अपनी साइट संरचना में फिट करने के लिए 3-पार्टी घटकों को संपादित करने के लिए कुछ समय बिताना होगा। फिर से, नाम टकराव यहां हो सकता है (जैसा कि पिछले विकल्प में वर्णित है) और मुझे उन्हें ठीक करना होगा।

3) datepicker.js, datepicker.css और उसकी छवियों को एक अलग निर्देशिका में डालें, मान लें कि / 3rdParty / datepicker / और फ़ाइलों को उस स्थान पर रखें जहाँ लेखक द्वारा इसका उद्देश्य रखा गया था (उदाहरण के लिए, 3rdParty / datepicker / css / datepicker .css, /3rdParty/datepicker/css/something.png, आदि)। अब मैं यह सोचना शुरू करता हूं कि यह विकल्प सबसे सही है।

अनुभवी वेब डेवलपर्स, आप क्या सलाह देते हैं?

Answer 1

मैं हमेशा तीसरे पक्ष के घटकों के लिए एक कार्यकारी निर्देशिका बनाता हूं, आप वास्तव में तीसरे पक्ष के पुस्तकालयों को बदलना नहीं चाहते हैं जब तक कि यह कड़ाई से आवश्यक न हो।

3 ऑप्शन के साथ जाएं।

Answer 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)

Answer 3

विकल्प # 2 व्यावहारिक और खतरनाक भी नहीं है क्योंकि जब आप अपने तृतीय पक्ष के पुस्तकालयों को अपग्रेड करते हैं, तो आपको अपने सभी परिवर्तनों को फिर से लागू करना होगा (और इसलिए कुछ भूल सकते हैं)। यह निश्चित रूप से एक बड़ा नहीं नहीं है! विकल्प # 1 और # 3 प्रत्येक के फायदे और नुकसान हैं। इसलिए मैं आमतौर पर दोनों के संयोजन के लिए जाता हूं।

मेरा समाधान मेरी फ़ाइलों के लिए विकल्प # 1 का उपयोग करना और 3 पार्टी पुस्तकालयों के लिए विकल्प # 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