Asset Pipeline In Rails 3.1.0

Asset pipeline tillhandahåller ett ramverk för att sammanfoga och minifiera eller komprimera JavaScript- och CSS-tillgångar. Det lägger också till möjligheten att skriva dessa tillgångar på andra språk som CoffeeScript, Sass och ERB. I Rails 3.1 är rails-tillgångspipeline aktiverad som standard. Det kan inaktiveras i config/application.rb genom att placera denna rad i applikationsklassdefinitionen:

config.assets.enabled = false

vi kan också inaktivera tillgångspipelinen medan vi skapar en ny applikation genom att passera alternativet —skip-sprockets.

rails nytt appnamn –skip-sprockets

Funktioner i tillgångspipeline:

1. Sammankoppla tillgångar

Den här funktionen är viktig i en produktionsmiljö, eftersom den kan minska antalet förfrågningar som en webbläsare måste göra för att rendera en webbsida. Webbläsare är begränsade i antalet förfrågningar som de kan göra parallellt, så färre förfrågningar kan innebära snabbare laddning för ansökan.

Räls 2.x introducerade möjligheten att sammanfoga JavaScript- och CSS-tillgångar genom att placera :cache => true i slutet av metoderna javascript_include_tag och stylesheet_link_tag. Men denna teknik har vissa begränsningar. Till exempel kan den inte generera cacharna i förväg och den kan inte transparent inkludera tillgångar som tillhandahålls av tredje parts bibliotek.

2.Minifiering eller komprimering av tillgångar

För CSS-filer görs komprimering genom att ta bort blanksteg och kommentarer. För JavaScript kan mer komplexa processer tillämpas. vi kan välja från en uppsättning inbyggda alternativ eller ange våra egna.

3. Det tillåter kodning av tillgångar via ett språk på högre nivå, med förkompilering ner till de faktiska tillgångarna. Språk som stöds inkluderar Sass för CSS, CoffeeScript för JavaScript och ERB för båda som standard. I äldre versioner av Rails-tillgångspipeline finns alla tillgångar i underkataloger till offentliga såsom bilder, javascript och stilmallar.

Med tillgångspipeline är den föredragna platsen för dessa tillgångar nu app/tillgångar-katalogen. Filer i den här katalogen betjänas av Sprockets-mellanvaran som ingår i sprockets pärla. Tillgångar kan fortfarande placeras i den offentliga hierarkin. Alla tillgångar som är offentliga kommer att visas som statiska filer av applikationen eller webbservern. vi bör använda app/tillgångar för filer som måste genomgå en viss förbearbetning innan de visas.

I produktionen förkompilerar Rails dessa filer till publika/tillgångar som standard. De förkompilerade kopiorna serveras sedan som statiska tillgångar av webbservern. Filerna i app/tillgångar serveras aldrig direkt i produktionen.

När vi genererar en ställning eller en styrenhet genererar Rails också en JavaScript-fil (eller CoffeeScript-fil om coffee-rails juvelen finns i Gemfile) och en Cascading Style Sheet-fil (eller SCSS-fil om sass-rails finns i Gemfile) för den kontrollanten.

Tillgångsorganisation:

Den största praktiska skillnaden mellan Rails 3.0- och Rails 3.1-appar är en ändring av platsen för tillgångsfiler som bilder, stilmallar och JavaScript-filer. I tidigare versioner av Rails tillgångspipeline fanns alla dessa filer i den offentliga/katalogen:

offentliga/bilder/

public/stylesheets/

public/javascripts/

I Rails 3.1 och Rails 3.2.3 skiljer sig platsen för dessa filer beroende på om de är skapade av oss eller kommer från en extern leverantör. I det här fallet finns filerna i app-/tillgångarkatalogen:

app/tillgångar/bilder/

app/tillgångar/formatmallar/

app/tillgångar/javascripts/

När det gäller kod eller bilder från externa leverantörer använder vi katalogen leverantör/tillgångar:

leverantör/tillgångar/bilder/

leverantör/tillgångar/formatmallar/

leverantör/tillgångar/javascripts/

Manifestfiler

Dessa är vanliga js- eller css-filer som innehåller direktivprocessorer, kommentarsrader följt av en =

// …

//= kräver jquery

//= kräver jquery_ujs

//= require_tree .

Eller:

/* …

*= kräver_själv

*= require_tree .

Dessa manifestfiler refererar till och inkluderar andra tillgångar som de är beroende av. require_directory och require_tree låter oss kräva hela kataloger och deras barn, require_self inkluderar även alla js eller css i själva manifestfilen.