Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p><strong>Database = no</strong></p> <p>Don't use the database for this. The CSS/JS files needed to display a view are directly tied to the source code, so keep that info in the source (particularly if you're using an SCM like Git or SVN).</p> <p><strong>CSS/JS = presentation</strong></p> <p>As these files are related to presentation/UI, I'd recommend delegating the "responsibility" of loading them to the views themselves. The controllers &amp; models shouldn't have to "know" anything about the CSS/JS required to display the view.</p> <p><strong>Be modular</strong></p> <p>Organize the files into discrete modular units. Don't have a separate CSS/JS file for every view UNLESS you truly have completely separate functionality on every single view. The more you share these files among views, the better off you'll be.</p> <p><strong>Leverage caching, rather than fighting it</strong></p> <p>I know it's a pain in the ass to rename a file every time you modify it, but it really is a good approach. Using cache invalidating approaches (like URL?time=...) simply puts extra strain on the server and clients for no good reason. Just take the two seconds to rename your "styles.css" file to "styles_v2.css". You'll thank yourself later. (And remember, you don't have to rename it for every single dev change--only when it's stable enough for QA / production).</p> <p><strong>Premature optimization = root of all evil</strong></p> <p>Finally--and most importantly--NEVER PREMATURELY OPTIMIZE! I've seen way too many people minify and gzip their asset files all the time, only to have them overhauled a few days later. Either create a true build process, or wait until things stabilize to worry too much about the fine tuning.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload