वेब अनुप्रयोग संरचना के लिए सर्वोत्तम अभ्यास के लिए आपकी युक्तियां क्या हैं?

Question

मैं काम पर बहुत सारे कस्टम एप्लिकेशन करता हूं। मैं नए अनुप्रयोगों के लिए कुछ मानकों को परिभाषित करने की कोशिश कर रहा हूं। कुछ तत्वों की तरह कुछ।

सीएसएस: आप स्टाइल शीट कैसे व्यवस्थित करते हैं? क्या मेरे पास पूरी साइट के लिए एक बेस स्टाइल शीट होनी चाहिए और प्रत्येक व्यक्तिगत पृष्ठ के लिए अनुकूलन के लिए एक होना चाहिए? क्या मेरे पास प्रिंट शैलियों के लिए दूसरा होना चाहिए? मैंने सुना है कि अधिक फ़ाइलों को जोड़ने से ब्राउज़र को पुनर्प्राप्त करने में अधिक समय लगता है। (प्रति पृष्ठ अधिक वस्तुएं ... जावास्क्रिप्ट फ़ाइलों या छवियों के साथ भी एक समस्या) ... कितने लोग हैं? क्या आप अपने सीएसएस पर भारी टिप्पणी करते हैं? किसी नेस्टेड संरचना प्रदान करें? तत्वों के भीतर वर्णमाला? क्या मुझे रीसेट की ज़रूरत है? आयात के बारे में क्या? और टाइपोग्राफी?

जावास्क्रिप्ट: मूल रूप से वही प्रश्न। जावास्क्रिप्ट फाइलें ... क्या मुझे एक या दो अच्छी पुस्तकालयों (उदाहरण के लिए JQuery और प्रोटोटाइप) शामिल करना चाहिए और फिर प्रत्येक पृष्ठ के लिए एक और शामिल होना चाहिए? अब मैं अचानक 5 या 6 सीएसएस और जेएस फाइलों सहित हूं ...

निर्देशिका संरचना: आप साइट को कैसे व्यवस्थित करते हैं? वर्तमान में, मैं

/CSS   ... For CSS files 
/JS   ... For javascript files 
/INC   ... For private code includes 
/ASSETS/IMG ... For images 
/ASSETS/AU ... For audio 
/ASSETS/SWF ... For Flash 

जैसे कुछ भी उपयोग करता है, इसके अलावा, किसी अन्य सुझाव का स्वागत किया जाएगा। धन्यवाद!!

Answer 1

क्या मुझे पूरी साइट के लिए एक बेस स्टाइल शीट और प्रत्येक व्यक्तिगत पृष्ठ के लिए अनुकूलन के लिए एक होना चाहिए?

व्यावहारिक बनें। यदि आपके पास कुछ पर्याप्त नियम हैं जो आप उन्हें एक फ़ाइल में व्यवस्थित कर सकते हैं और क्या कर सकते हैं, इसकी निगरानी बनाए रखें। यदि आपके पास पर्याप्त संख्या में नियम हैं जो केवल आपकी साइट के कुछ अनुभागों या व्यक्तिगत पृष्ठों पर लागू होते हैं, तो हर तरह से उन्हें अपने स्वयं के स्टाइलशीट में विभाजित करें, लेकिन प्रत्येक पृष्ठ के लिए अलग स्टाइलशीट बनाने की आवश्यकता महसूस न करें यहां तक ​​कि जब इसमें केवल दो नियम होते हैं।पेज-विशिष्ट क्लास या आईडी को < बॉडी में जोड़ें> ताकि आप साझा स्टाइलशीट से एकल पृष्ठ चुन सकें, आपको इसकी आवश्यकता होनी चाहिए।

स्टाइलशीट में शैलियों को अलग करना लेखक के रूप में आपके लाभ के लिए है, इसलिए जो भी आपको प्रबंधित करने के लिए सबसे आसान लगता है। एक जटिल साइट के लिए जो शायद एक से अधिक सीएसएस फ़ाइल होगी, लेकिन यह दर्जनों होने वाला नहीं है।

क्या मेरे पास प्रिंट शैलियों के लिए कोई और होना चाहिए?

आम तौर पर हां। जब आप @media नियम का उपयोग करके किसी अन्य स्टाइलशीट के अंदर प्रिंट शैलियों को एम्बेड कर सकते हैं, तो यह परंपरागत रूप से खराब हो गया है, इसलिए < लिंक में मीडिया डालना> टैग आमतौर पर सबसे आसान होता है। किसी भी मामले में प्रिंट स्टाइलशीट अक्सर अपने स्क्रीन समकक्षों से बहुत अलग होते हैं कि यह उनके नियमों को अलग रखने के लिए समझ में आता है।

मैंने सुना है कि अधिक फ़ाइलों को जोड़ने से ब्राउज़र को पुनर्प्राप्त करने में अधिक समय लगता है।

हां, लेकिन यह प्रभाव अक्सर अतिरंजित होता है। HTTP/1.1 क्लाइंट और सर्वर के बीच कनेक्शन को रखकर प्रति-अनुरोध विलंबता को कम करता है, जो एक मजबूत शमन है।

कितने लोग हैं?

पर्याप्त है कि आप कई स्टाइलशीट होने की संभावना नहीं है। स्क्रिप्ट एक समस्या हो सकती है यदि आप उस प्रकार के ढांचे का उपयोग कर रहे हैं जो प्रति वर्ग एक स्क्रिप्ट फ़ाइल की मांग करता है, लेकिन अन्यथा आमतौर पर ठीक है। यह बहुत छोटी छवियों के साथ अधिक सामान्य रूप से समस्याग्रस्त है।

क्या आप अपने सीएसएस पर भारी टिप्पणी करते हैं?

लाइट कमेंटिंग आमतौर पर पर्याप्त होना चाहिए। सीएसएस की घोषणात्मक नियम शैली आमतौर पर गहन स्पष्टीकरण कोड की मांग करने के लिए पर्याप्त जटिल नहीं होती है। विशेष रूप से, ब्राउज़र-विशिष्ट हैक्स की तरह कुछ भी counterintuitive दस्तावेज।

तत्वों के भीतर वर्णमाला?

जब तक कि आपके प्रबंधन के लिए यह आसान नहीं हो जाता है। आमतौर पर ऐसा नहीं होता है, आप समान नियमों, या तत्वों के समान समूहों के लिए आवेदन करने वाले नियमों को समूहित करने का प्रयास करेंगे।

क्या मुझे रीसेट की आवश्यकता है?

एक पूर्ण रीसेट? यदि आप जानते हैं कि आप क्या कर रहे हैं और आप जिस विशेष समस्याग्रस्त डिफ़ॉल्ट को रीसेट करना चाहते हैं उसका चयन कर सकते हैं।

मैं

एक से अधिक ढांचा शामिल न करें जब तक आप पूरी तरह से करने के लिए है एक या दो अच्छा पुस्तकालयों (JQuery और प्रोटोटाइप, उदाहरण के लिए) शामिल करना चाहिए।

और फिर प्रत्येक पृष्ठ के लिए एक और शामिल है?

यदि प्रत्येक पृष्ठ में विशेष कस्टम व्यवहार है तो आप कर सकते हैं। लेकिन यह आमतौर पर नहीं होता है। यदि आप प्रगतिशील-वृद्धि व्यवहार स्क्रिप्ट करते हैं जो उदाहरण के लिए बाध्य करते हैं। कक्षा के नाम, आप प्रत्येक पृष्ठ पर प्रत्येक व्यवहार के लिए स्क्रिप्ट शामिल कर सकते हैं जो इसका उपयोग करता है, फिर इसे तत्वों को स्वचालित रूप से बाध्य करने दें।

निर्देशिका संरचना: आप साइट को कैसे व्यवस्थित करते हैं?

व्यक्तिगत रूप से, मेरे अजगर/WSGI अनुप्रयोगों के लिए:

appfolder 
    application.py  - main WSGI entry point and control/configuration script 
    data     - run-time writable application file store 
     private   - files not available through the web server 
     public   - mounted as a virtual directory on the web server 
    logs     - access, error, application log files 
    system    - all the static application code and data 
     htdocs   - web server root folder 
      file   - static servable files 
      img   - static images 
      script  - JavaScript 
      style  - CSS 
     lib    - Python modules used by site 
      appmodule - main application code package 
     templates  - HTML page templates 
      mail   - mail text templates 

यह मेरे लिए एक अलग जगह में 'डेटा' (अलग अनुमति के साथ) 'सिस्टम' में आवेदन करने के लिए रखने के लिए के लिए महत्वपूर्ण है। एप्लिकेशन को अपग्रेड करने के लिए आपको 'सिस्टम' फ़ोल्डर को स्वैप करने में सक्षम होना चाहिए, बिना चिंता किए कि htdocs/img में अपलोड की गई छवियां हैं, आपको रखने के बारे में चिंता करने की ज़रूरत है।

Answer 2

एक स्टाइल शीट रखने के लिए अपनी पूरी कोशिश करें। व्यक्तिगत पृष्ठों के लिए अलग-अलग स्टाइल शीट को जोड़ने से उद्देश्य को हराया जाता है।

आप पत्रक

@import url('blueprint/screen.css'); 
@import url('blueprint/styles.css'); 

इस मामले मैं तो है कि नीचे अपने कस्टम शैलियों जोड़ने खाका सीएसएस शैलियों इनहेरिट कर रहा हूँ में के शीर्ष पर निम्नलिखित लाइनों को शामिल करके अपने सीएसएस में अन्य स्टाइलशीट वारिस कर सकते हैं।

जेएस पुस्तकालयों के संदर्भ में मैं 3 फाइलों को लिंक करना पसंद करता हूं।

लाइब्रेरी, सभी प्लगइन, और अंत में पृष्ठ कोड के साथ एक पृष्ठ।

/_css /_images /_scripts फ़ाइलों

लेकिन हाल ही में मैं इस साइट देखो बनाने के लिए इस्तेमाल सब कुछ/डाल करने के लिए तरीके से काम शुरू कर दिया गया है:

निर्देशिका संरचना के लिए मैं आम तौर पर निम्नलिखित है मैं इसे एक/_ प्रस्तुति निर्देशिका में चाहता हूं ... तो ब्लॉग पोस्ट आदि के लिए छवियों जैसी अतिरिक्त कुछ भी/छवियों में

उम्मीद है कि इससे मदद मिलती है।

Answer 3

मैंने अपनी निर्देशिका संरचना और टिप्पणियां किसी अन्य धागे में पोस्ट की हैं, लेकिन यह यहां भी लागू है!

मैं अब थोड़ी देर के लिए निम्नलिखित सेटअप का उपयोग किया गया है महान परिणामों के साथ:

• /साइट: यह वह जगह है जहाँ अपने वास्तविक चालू वेबसाइट रहना होगा। टेम्पलेट बनने के बाद मैं इस निर्देशिका में अपना सीएमएस या मंच स्थापित करूंगा।

  • .htaccess (मूल तोड़ मरोड़ मैं आमतौर पर अपने आप को वैसे भी सक्षम करने लगता है)
  • robots.txt (तो मैं भूल नहीं है/व्यवस्थापक बाद में जैसे आइटम अस्वीकृत करने के लिए)

• /स्रोत: किसी भी comps, नोट्स, दस्तावेज, विनिर्देशों, आदि शामिल हैं

• /टेम्पलेट्स: यहां प्रारंभ करें! सभी स्थैतिक टेम्पलेट्स बनाएं जिन्हें अंततः सीएमएस या/साइट के ढांचे में पोर्ट किया जाना चाहिए।

  • /_behavior
    • global.js (साइट विशिष्ट कोड, आवश्यकतानुसार एक से अधिक फ़ाइलों में विभाजित किया जा सकता है)

  • /_media: छवियाँ, डाउनलोड करने योग्य फ़ाइलों, आदि आवश्यक

  • /_style: मैं मॉड्यूलर सीएसएस विकास पसंद करता हूं इसलिए मैं आमतौर पर प्रत्येक अद्वितीय अनुभाग के लिए कई स्टाइलशीट समाप्त करता हूं वेबसाइट का। यह Blender के साथ बहुत साफ है - मैं अत्यधिक इस उपकरण की सिफारिश करता हूं!

    • print.css (यह अंततः मिश्रित हो जाता है, इसलिए का उपयोग @media प्रिंट)
    • reset.css (Eric Meyer's)
    • स्क्रीन।सीएसएस (@media स्क्रीन के लिए, हाथ में) आवश्यक

  • /_vendor रूप

  • अतिरिक्त मॉड्यूल: सभी 3 पार्टी कोड (jQuery, shadowbox, आदि)

  • Blendfile.yaml (ब्लेंडर के लिए; ऊपर देखें)

  • टेम्पलेट.html (मूल प्रारंभिक टेम्पलेट; प्रतिलिपि बनाई जा सकती है और प्रत्येक अद्वितीय टेम्पलेट के लिए नाम बदल दिया जा सकता है)

• /परीक्षण: Selenium इकाई परीक्षण

Answer 4

मैं हमेशा लोड और सीएसएस नियमों और जे एस कोड है कि प्रश्न में एचटीएमएल पर नहीं किया जाता है व्याख्या करने के लिए होने से ब्राउज़र रखने की कोशिश। मैं @ बॉबन्स से सहमत हूं कि संगठन के लिए आवश्यक होने पर आपको केवल एक पृष्ठ की शैलियों और स्क्रिप्ट को एक अलग फ़ाइल में तोड़ना चाहिए, लेकिन यदि आपकी साइट बहुत बड़ी है, तो आप उस बिंदु तक पहुंच जाएंगे।

हालांकि, क्योंकि मैं केवल टेम्पलेट आधारित साइट्स का निर्माण करता हूं, इसलिए मुझे आश्चर्य है कि मैं बाहरी फाइलों से क्यों लिंक करता हूं। उदाहरण के लिए, यदि मेरे पास आधार टेम्पलेट है तो मैं उस टेम्पलेट के सिर में रखी गई चीज़ों को मेरी साइट पर सभी पृष्ठों पर लागू किया जाएगा। तो क्यों न सिर्फ मेरी शैलियों और लिपियों को रखा?

दो कारण दिमाग में आते हैं। सबसे पहले ब्राउज़र बाहरी फ़ाइल को कैश कर सकता है और इसे हर पृष्ठ पर पुन: उपयोग कर सकता है जिसमें इसे फिर से लोड किए बिना शामिल किया जाता है। दूसरे डिजाइनर आपके टेम्पलेट्स में चारों ओर आरामदायक पोकिंग नहीं कर सकते क्योंकि वे सादे सीएसएस फाइलों के साथ गड़बड़ कर रहे हैं।

वैश्विक शैलियों के लिए यह सब अच्छा और अच्छा है जो आपकी साइट के प्रत्येक पृष्ठ पर लागू होता है, लेकिन उन वन-ऑफ पृष्ठों के बारे में क्या कुछ शैली है जो कहीं और साझा नहीं की जाती हैं? यदि आपने इस शैली को वैश्विक स्तर पर लागू बाहरी फ़ाइल में जोड़ा है तो आप केवल एक पृष्ठ पर उपयोग की जाने वाली शैली के लिए अपनी साइट के प्रारंभिक लोड समय को बढ़ाएंगे। इसके अलावा, जब आप उस फाइल पर वापस जाते हैं तो महीनों बाद आप भूल गए होंगे कि ये नियम क्या हैं।

मेरा सुझाव है कि किसी भी शैली नियम है कि पर हर एक पेज व्यक्त नहीं है उप टेम्पलेट है कि HTML नियम लागू होता है renders के भीतर <style> टैग में रखा जाना चाहिए। यह वैश्विक स्टाइलशीट से वास्तविक पृष्ठ पर लोड और जटिलता को ले जाएगा जहां शैलियों की आवश्यकता है, और नियमों को संदर्भ दें ताकि उन्हें भविष्य में बनाए रखा जा सके। यदि यह आपके डिजाइनर को डराता है तो उन्हें वैसे भी सीएसएस लिखने की आवश्यकता नहीं है। बस उन्हें फ़ोटोशॉप से ​​चिपकने के लिए कहें और आपको बड़े लड़के के काम करने दें।

Answer 5

बस सुनिश्चित करें कि आप फ़ोल्डर के लिए पूंजी अक्षरों का उपयोग नहीं करते हैं। जब आप विंडोज़ पर विकसित होते हैं और लिनक्स सर्वर पर तैनात करते हैं तो यह आपको काट सकता है।

Answer 6

सीएसएस: मैं केवल एक स्टाइलशीट का उपयोग करता हूं। जैसे ही मैं साथ जाता हूं मैं बस नीचे घूमता रहता हूं। मैं आमतौर पर नियमों के प्रत्येक पृष्ठ-विशिष्ट सेट से पहले एक टिप्पणी करता हूं। Ctrl + F अगर मुझे कुछ संपादित करने की आवश्यकता है।

जावास्क्रिप्ट: आमतौर पर केवल एक लाइब्रेरी, और शायद कुछ प्लगइन शामिल होते हैं। किसी पृष्ठ-विशिष्ट जेएस को सीधे उस पृष्ठ के शीर्षलेख में फेंकने के लिए प्रयुक्त होता है, लेकिन मुझे थोड़ा बदसूरत लगता है और डेटा के साथ 'व्यवहार' मिश्रण करता है।तो मैं एक नया प्रतिमान शुरू कर रहा हूं -

एमवीसीबी - मॉडल, देखें, नियंत्रक, व्यवहार। एमवीसी डेस्कटॉप ऐप के बजाय स्थिर यूआई के साथ बहुत अच्छा है, लेकिन जब आप बहुत सारे जेएस जोड़ते हैं तो मुझे लगता है कि यह अबास्ट्रक्शन की एक अतिरिक्त परत की मांग करता है।

इस प्रकार, अपने मूल फ़ाइल संरचना:

index.php 
app 
    config 
     bootstrap.php    -- code that needs to run before anything else, or functions that don't really fit elsewhere 
     core.php     -- timezone, database, and misc settings 
     routes.php     -- default routes 
    layouts       -- layout/template files 
     flash      -- layouts for one-time popup messages 
    objects       -- all files are stored in the same folder as the controller to keep directories 
              smaller and ease reusability 
     object 
      controller.php 
      model.php 
      routes.php    -- object-specific routes to override default routes 
      behaviours    -- page-specific javascript files 
       action.js   -- included automatically on that page if this file exists 
      views 
       action.php   -- the view for this action 
    public       -- static media files, sometimes called "assets" 
     favicon.ico 
     xrds.xml 
     css 
     img 
     js 
     uploads   
core 
    app.php       -- initializes stuff 
    controller.php     -- default controller 
    dispatcher.php     -- includes everything and calls all the appropriate functions 
    model.php      -- default model that all other models inherit from 
    components      -- helper functions to used in controllers 
    datasources      -- mysql, oracle, flat-file... 
    helpers       -- functions to be used in views and layouts 
    structures      -- model helpers such as tree or polymorphic behaviours 
    utils       -- functions that are useful everywhere 
libs        -- 3rd party libs 

.htaccess

Options -Indexes 

RewriteEngine On 

RewriteCond %{REQUEST_URI} !^/app/public/ 
RewriteCond %{DOCUMENT_ROOT}/app/public%{REQUEST_URI} -f 
RewriteRule .* /app/public/$0 [L] 

RewriteCond %{REQUEST_URI} !^/app/objects/ 
RewriteRule ^([^/]+)/(.+\.js)$ /app/objects/$1/behaviours/$2 [L] 

RewriteCond %{REQUEST_FILENAME} !-f 
RewriteRule .* /index.php?url=$0 [L,QSA]