Controllers: Asset Management: Unterschied zwischen den Versionen

Aus CodeCoupler Wiki
Zur Navigation springen Zur Suche springen
Tm (Diskussion | Beiträge)
Keine Bearbeitungszusammenfassung
Tm (Diskussion | Beiträge)
 
(13 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
All the assets of your web-application can be placed inside of your application folder or at the root of your webfolder. In both places you will find a folder named "assets". In there you will find subfolders named img, css, js and etc. The names are self-explanatory. You can put your assets in there and use any deep hierarchy of subfolders.
== Summary ==


The assets at the top of your web folder will be available to all your applications (if you have). Every application can override assets from the top of your web folder by creating an asset with the same name.  
All the assets of your web-application can be placed inside a folder named '''assets'''. You can use any folder hierarchy you want.


Assets will be compiled or otherwise modified. The result will be saved into subfolders named "compiled". As long as the original file will not be modified, these compiled versions will be delivered for future requests instead of compiling all the time. Furthermore the clients will be informed about the last modification date. As long as the browser hold a up-to-date version of the asset, the asset will not be streamed again. Instead the library will send a 304 response, which means that the browser should use the it's cached version.
Assets will be based on the type compiled or otherwise modified before sending them to the client:


Also the etag identification of a file will be contemplated before a asset will be send to the browser. This has an additional advantage with serving compiled css or javascript files. Unimportant modification in the original file (like insert an empty line) results into the same compiled version and thus into the same etag. Browser will be told to use it's cached version and the asset will not be streamed.
* Images will be downscaled for small displays
* SCSS will be compiled to CSS
* JavaScript will be compressed


Every asset handler can decide if a compilation is necessary. If an asset do not need to be compiled the system use something like a link to the original file. These technique will be used by the image compiler, to save space for useless duplication of images.
=== Features ===


In the most cases you do not have to delete the compiled assets. The controller will recognize a new version of the origin asset, and will delete the cached one by itself. But removing all the contents inside of the folders "compiled" can be done everytime safely. This caches will be rebuild automatically.
'''Caching of compiled files:'''
 
The compiled version will be cached and as long as the original file will not be modified, these compiled versions will be delivered.
 
In the most cases you do not have to delete the compiled assets. The controller will recognize a new version of the origin asset, and will delete the cached one by itself. But removing all the contents inside of the folders holding a compiled version can be done everytime safely. This caches will be rebuild automatically.
 
It could be useful to delete the entire cache from time to time (e.g. after heavy reconstructions of your assets), because there is no garbage collection. The system will not recognize deletion of original files and the compiled version will stay.
 
'''Support of Browser Caching:'''
 
Browsers caching techniques are also supported and files will not be delivered at all if they are cached by the browser.
 
Clients will be informed about the last modification date and the Etag hash-value of the requested file. As long as the browser hold a up-to-date version of the asset, the asset will not be streamed again. Instead the library will send a 304 response, which means that the browser should use the it's cached version.
 
The handling of Etag has an additional advantage with serving compiled css or javascript files. Unimportant modification in the original file (like insert an empty line) results into the same compiled version and thus into the same Etag. So browsers will be told to use it's cached version and the asset will not be streamed.
 
'''Space Saving Handling:'''
 
Furthermore every asset handler can decide if a compilation is necessary. If an asset do not need to be compiled the the original file will be send to the client. These technique will be used for example by the image compiler, to save space for useless duplication of images.
 
'''Environment Dependence:'''
 
The output of some asset types depends on the environment of your CodeIgniter instance (depending on the constant "ENVIRONMENT"). JavaScript files will be compressed for example if you set your environment to '''production''' or '''testing'''.


== General Usage ==
== General Usage ==
Zeile 15: Zeile 39:
=== Links to Assets ===
=== Links to Assets ===


Assets will be linked from your html source always pointing to the path '''assets/ASSET_TYPE/PATH_TO_ASSET/FILENAME_OF_ASSET'''.
Assets will be linked from your html source always pointing to the path '''assets/PATH_TO_ASSET/FILENAME_OF_ASSET'''.


To link for example to your css assets named '''style.css''' that you have saved in the folder '''application/assets/css/mySubfolder/style.css''' use the following tag:
To link for example to your css assets named '''style.css''' that you have saved in the folder '''application/assets/some_subfolder_if_needed/style.css''' use the following tag:


<syntaxhighlight>
<syntaxhighlight lang="html">
<link rel="stylesheet" href="assets/css/mySubfolder/style.css" type="text/css" />
<link rel="stylesheet" href="assets/some_subfolder_if_needed/style.css" type="text/css" />
</syntaxhighlight>
</syntaxhighlight>


Zeile 27: Zeile 51:
Behind the asset name you can add a slash and a flag for special purposes (especially for debugging):
Behind the asset name you can add a slash and a flag for special purposes (especially for debugging):


* '''off:''' The compiler will not be used. The original asset file will be delivered.
* '''/off''' The compiler will not be used. The original asset file will be delivered.
* '''force:''' The asset will be compiled even if the compiled version is up-to-date.
* '''/force''' The asset will be compiled even if the compiled version is up-to-date.
* '''live:''' Like '''force''' the asset will always compiled. But it will compile the asset as it would be compiled in a production environment.
* '''/development''' Deliver always the asset as it would be compiled in a development environment.
* '''auto:''' This is the standard flag. The asset will be recompiled if the cached version is out-of-date. If you set this flag or leave it, the behaviour is exactly the same.
* '''/testing''' Deliver always the asset as it would be compiled in a testing environment.
 
* '''/production''' Deliver always the asset as it would be compiled in a production environment.
Using the flag '''live''' (in a development environment of course) can be confusing. If you call an asset with the flag '''live''' a new compiled version will be saved into the cache. If you call the next time the asset without this flag the system will recognize an up-to-date cached asset and you will get delivered all the time the "live"-version of the compiled asset. You can reverse this by calling the asset with the flag '''force'''.
* '''/force/development''' Combination of the above options.
* '''/force/testing''' Combination of the above options.
* '''/force/production''' Combination of the above options.


Here an example how to use these flags:
Here an example how to use these flags:
Zeile 38: Zeile 64:
<syntaxhighlight>
<syntaxhighlight>
Retrieve your stylesheet at the "normal" way:
Retrieve your stylesheet at the "normal" way:
http://domain.tld/assets/css/mySubfolder/style.css
http://domain.tld/assets/style.css


Retrieve your stylesheet as it would be in a production environment:
Retrieve your stylesheet as it would be in a production environment:
http://domain.tld/assets/css/mySubfolder/style.css/live
http://domain.tld/assets/style.css/production


Retrieve your original stylesheet without the use of the compiler:
Retrieve your original stylesheet without the use of the compiler:
http://domain.tld/assets/css/mySubfolder/style.css/off
http://domain.tld/assets/style.css/off
</syntaxhighlight>
</syntaxhighlight>


Zeile 53: Zeile 79:
=== Images ===
=== Images ===


Images placed inside the folder "img" will be resized accordingly to the users display size. High density displays like retina displays will be detected and small mobile devices. For this reason you should use high resolution images from the beginning. The controller will serve the client an image with an optimized size automatically. The only thing you have to pay attention to, is the correct marking of the used <img>-Tags.
Imagefiles with the extensions '''jpg''', '''jpeg''', '''gif''' and '''png''' will be resized accordingly to the users display size. All types of displays should be detected, from high density displays like retina displays down to small mobile devices. For this reason you should use high resolution images (twice as big as displayed) from the beginning. The controller will serve the client an image with an optimized size automatically. The only thing you have to pay attention to, is the correct marking of the used '''img''' tags and set a little JavaScript into yout page.
 
The required JavaScript will be automatically inserted if you use the master template library. If you do not use the master template library you can add it manually:
 
<syntaxhighlight lang="html">
<script>document.cookie='resolution='+Math.max(screen.width,screen.height)+("devicePixelRatio" in window ? ","+devicePixelRatio : ",1")+'; path=/';</script>
</syntaxhighlight>
 
You should add this snippet as soon as possible in your '''head'''. Here is a best practice example:
 
<syntaxhighlight lang="html">
<head>
    <meta charset="..." />
    <meta http-equiv="x-ua-compatible" content="...">
    <script>document.cookie='resolution='+Math.max(screen.width,screen.height)+("devicePixelRatio" in window ? ","+devicePixelRatio : ",1")+'; path=/';</script>
    [...]
</head>
</syntaxhighlight>
 
The '''img''' tag mus have always the correct sizes:
 
<syntaxhighlight lang="html">
<img width="150" height="50" src="..." />
</syntaxhighlight>


An example: Acoording to the given design you have to place an image of 150x50 pixels onto the page. In this case you will save a double-sized image into the img folder with 300x100 pixels. The most important thing now, is to write your <img>-Tag with the correct sizes: <img width="150" height="50" src="..." />. That's all. Everything else will be done by the img-controller. Retina-displays will show a sharp image and mobile browsers will get a downsized image.
'''An example:'''


For now PNG, GIF and JPG are supported.
Acoording to the given design you have to place an image of 150x50 pixels onto the page. In this case you should save a double-sized image into the img folder with 300x100 pixels. The most important thing now, is to write your '''img''' tag with the correct sizes: '''<img width="150" height="50" src="..." />'''. That's all. Everything else will be done by the library. Retina-displays will show a sharp image and mobile browsers will get a downsized image.


Used library: http://adaptive-images.com/
Used library: http://adaptive-images.com/
Zeile 63: Zeile 112:
=== Stylesheets ===
=== Stylesheets ===


Sometimes everyone miss features that don't exist in CSS yet like variables, nesting, mixins, inheritance. This is now possible by using SCSS. To learn more about this CSS-Extension read the basic introduction here: http://sass-lang.com/guide But you do not have to use SCSS. If you dont want or need it, just use simple CSS as always.
Stylesheetfiles with the extensions '''css''' or '''scss''' will be compiled as SCSS. You can use variables, nesting, mixins, inheritance etc. and the library will produce the CSS for you. If you dont want or need it, just use simple CSS as always.


Depending on the constant "ENVIRONMENT" the served stylesheet will be compressed if it was set to "testing" or "production". If set to "development" it will be only normalized. In case of a compiler error a css comment will be inserted at the beginning of your stylesheet. The stylesheet will be delivered uncompiled.
To learn more about SCSS read the basic introduction here: http://sass-lang.com/guide


Only SCSS is supported, not SASS!
Furthermore the stylesheet will be compressed in a testing or production CodeIgniter environment. Otherwise it will be only normalized.
 
In case of a compiler error a css comment will be inserted at the beginning of your stylesheet and the stylesheet will be delivered uncompiled.


Used library: http://leafo.net/scssphp/
Used library: http://leafo.net/scssphp/


== JavaScript ==
=== JavaScript ===
 
JavaScript files with the extension '''js''' will be automatically minified if you are on production or testing CodeIgniter environment. Otherwise it will be left untouched.


You Javascript files will be automatically minified if you are on production environment (depending on the constant "ENVIRONMENT"), so that it can be delivered to the client quicker. Otherwise it will be left untouched. In case of a compiler error a JavaScript comment will be inserted at the beginning of your script. The file will be delivered uncompiled.
In case of a compiler error a JavaScript comment will be inserted at the beginning of your script and the file will be delivered uncompiled.


Used library: https://github.com/tedious/JShrink
Used library: https://github.com/tedious/JShrink


== Other Binaries ==
=== Other Binaries ===


For other files (for example pdf-files for download) the folder "etc" was scheduled. For now no special processing will be done for these files. Just put your files inside of the folder "assets/etc" being prepared for future enhancements.
For other files for now no special processing will be done. Just put your files inside of the assets folder being prepared for future enhancements.

Aktuelle Version vom 5. November 2017, 16:39 Uhr

Summary

All the assets of your web-application can be placed inside a folder named assets. You can use any folder hierarchy you want.

Assets will be based on the type compiled or otherwise modified before sending them to the client:

  • Images will be downscaled for small displays
  • SCSS will be compiled to CSS
  • JavaScript will be compressed

Features

Caching of compiled files:

The compiled version will be cached and as long as the original file will not be modified, these compiled versions will be delivered.

In the most cases you do not have to delete the compiled assets. The controller will recognize a new version of the origin asset, and will delete the cached one by itself. But removing all the contents inside of the folders holding a compiled version can be done everytime safely. This caches will be rebuild automatically.

It could be useful to delete the entire cache from time to time (e.g. after heavy reconstructions of your assets), because there is no garbage collection. The system will not recognize deletion of original files and the compiled version will stay.

Support of Browser Caching:

Browsers caching techniques are also supported and files will not be delivered at all if they are cached by the browser.

Clients will be informed about the last modification date and the Etag hash-value of the requested file. As long as the browser hold a up-to-date version of the asset, the asset will not be streamed again. Instead the library will send a 304 response, which means that the browser should use the it's cached version.

The handling of Etag has an additional advantage with serving compiled css or javascript files. Unimportant modification in the original file (like insert an empty line) results into the same compiled version and thus into the same Etag. So browsers will be told to use it's cached version and the asset will not be streamed.

Space Saving Handling:

Furthermore every asset handler can decide if a compilation is necessary. If an asset do not need to be compiled the the original file will be send to the client. These technique will be used for example by the image compiler, to save space for useless duplication of images.

Environment Dependence:

The output of some asset types depends on the environment of your CodeIgniter instance (depending on the constant "ENVIRONMENT"). JavaScript files will be compressed for example if you set your environment to production or testing.

General Usage

Links to Assets

Assets will be linked from your html source always pointing to the path assets/PATH_TO_ASSET/FILENAME_OF_ASSET.

To link for example to your css assets named style.css that you have saved in the folder application/assets/some_subfolder_if_needed/style.css use the following tag:

<link rel="stylesheet" href="assets/some_subfolder_if_needed/style.css" type="text/css" />

Special Flags

Behind the asset name you can add a slash and a flag for special purposes (especially for debugging):

  • /off The compiler will not be used. The original asset file will be delivered.
  • /force The asset will be compiled even if the compiled version is up-to-date.
  • /development Deliver always the asset as it would be compiled in a development environment.
  • /testing Deliver always the asset as it would be compiled in a testing environment.
  • /production Deliver always the asset as it would be compiled in a production environment.
  • /force/development Combination of the above options.
  • /force/testing Combination of the above options.
  • /force/production Combination of the above options.

Here an example how to use these flags:

Retrieve your stylesheet at the "normal" way:
http://domain.tld/assets/style.css

Retrieve your stylesheet as it would be in a production environment:
http://domain.tld/assets/style.css/production

Retrieve your original stylesheet without the use of the compiler:
http://domain.tld/assets/style.css/off

Asset Types

For now the following assets will be processed as follows:

Images

Imagefiles with the extensions jpg, jpeg, gif and png will be resized accordingly to the users display size. All types of displays should be detected, from high density displays like retina displays down to small mobile devices. For this reason you should use high resolution images (twice as big as displayed) from the beginning. The controller will serve the client an image with an optimized size automatically. The only thing you have to pay attention to, is the correct marking of the used img tags and set a little JavaScript into yout page.

The required JavaScript will be automatically inserted if you use the master template library. If you do not use the master template library you can add it manually:

<script>document.cookie='resolution='+Math.max(screen.width,screen.height)+("devicePixelRatio" in window ? ","+devicePixelRatio : ",1")+'; path=/';</script>

You should add this snippet as soon as possible in your head. Here is a best practice example:

<head>
    <meta charset="..." />
    <meta http-equiv="x-ua-compatible" content="...">
    <script>document.cookie='resolution='+Math.max(screen.width,screen.height)+("devicePixelRatio" in window ? ","+devicePixelRatio : ",1")+'; path=/';</script>
    [...]
</head>

The img tag mus have always the correct sizes:

<img width="150" height="50" src="..." />

An example:

Acoording to the given design you have to place an image of 150x50 pixels onto the page. In this case you should save a double-sized image into the img folder with 300x100 pixels. The most important thing now, is to write your img tag with the correct sizes: <img width="150" height="50" src="..." />. That's all. Everything else will be done by the library. Retina-displays will show a sharp image and mobile browsers will get a downsized image.

Used library: http://adaptive-images.com/

Stylesheets

Stylesheetfiles with the extensions css or scss will be compiled as SCSS. You can use variables, nesting, mixins, inheritance etc. and the library will produce the CSS for you. If you dont want or need it, just use simple CSS as always.

To learn more about SCSS read the basic introduction here: http://sass-lang.com/guide

Furthermore the stylesheet will be compressed in a testing or production CodeIgniter environment. Otherwise it will be only normalized.

In case of a compiler error a css comment will be inserted at the beginning of your stylesheet and the stylesheet will be delivered uncompiled.

Used library: http://leafo.net/scssphp/

JavaScript

JavaScript files with the extension js will be automatically minified if you are on production or testing CodeIgniter environment. Otherwise it will be left untouched.

In case of a compiler error a JavaScript comment will be inserted at the beginning of your script and the file will be delivered uncompiled.

Used library: https://github.com/tedious/JShrink

Other Binaries

For other files for now no special processing will be done. Just put your files inside of the assets folder being prepared for future enhancements.