How do you manage assets in the new Laravel 4? It looks like Taylor Otwell has replaced Asset::add with something new.
What I am trying to do is have Laravel add my CSS and JS files. There were several ways to do this in Laravel 3, but they seem to be gone now. One was Asset::add and the other was HTML. What are the replacements for these?
I use the helper:
<script src="{{ asset('js/jquery-1.9.1.js') }}"></script>
<script src="{{ asset('js/bootstrap.min.js') }}"></script>
See also
vendor/laravel/framework/src/Illuminate/Support/helpers.php
Many other helpers too, e.g. app_path(), various array tools, link_to_route(), link_to_action(), storage_path(), etc.
Laravel 4 doesn't have out of the box asset management. But some packages have been created to handle this kind of thing.
codesleeve/asset-pipeline (my favorite so far)
jasonlewis/basset (had some errors with this)
teepluss/asset (closest to Laravel 3 Asset::add() but doesn't do concatenation or minification)
way/guard-laravel (requires ruby guard gem to run)
This is how I did when I needed to append some .css and .js files only to a specific page:
In my blade template:
<head>
<title>.....</title>
.....
@yield('head')
</head>
And in my specific page blade file:
@extends('template')
@section('head')
{{ HTML::style('css/filename.css') }}
{{ HTML::script('js/filename.js') }}
@stop
...
What about Basset (former Best Asset)?: http://jasonlewis.me/code/basset
I just installed it on L4, still no tests made, but sound promissing.
I made a much simpler version of Laravel 3 Asset class and works perfect in Laravel 4. For me it's all I need! Simply choose a name for the container and add the assets in the final order:
Asset::container('jq_1.10')->add('js/jquery-1.10.1.min.js')->add('css/css.css');
For output:
echo Asset::container('jq_1.10')->asset();
The class:
class Asset {
public static $containers = array();
public static function container($container = 'default')
{
if ( ! isset(static::$containers[$container]))
{
static::$containers[$container] = new Asset_Container($container);
}
return static::$containers[$container];
}
}
class Asset_Container {
public $name;
public $assets = array();
public function __construct($name)
{
$this->name = $name;
}
public function add($source)
{
$type = (pathinfo($source, PATHINFO_EXTENSION) == 'css') ? 'style' : 'script';
$obj = (object)array('type' => $type,'source' => $source);
$this->assets[] = $obj;
return $this;
}
public function asset()
{
$str = '';
foreach($this->assets as $aset){
if($aset->type == 'style')$str .= HTML::style($aset->source);
else $str .= HTML::script($aset->source);
}
return $str;
}
}
These dont exist in Laravel 4 - I think the idea is to use Composer bundles to add them in.
Meido has created a 'port' of HTML, Form and Str classes from Laravel 3 to Laravel 4.
I'm not aware of an Asset port - I think you should view the bundles already on Composer to find one that suits your needs.
In my opinion the best way of doing this, is with the URL::asset() method.
For instance:
CSS
<link rel="stylesheet" href="{{URL::asset('css/style.css')}}" media="screen" />
or
JS
<script type="text/javascript" src="{{URL::asset('js/scripts.js')}}"></script>
You can also use it with images and basically any asset located in your public folder.
ie:
<img scr="{{URL::asset('img/image.jpg')}}}} id="someid">
By using this method, i find it easier to organise and separate my HTML markup from Laravel methods.
Say if i wanted to specify a css file that is to be loaded with the media="print" attribute, the "Laravel" way of doing this is the following:
{{HTML::style("print.css", array('media' => 'print'))}}
While the conventional way, using the {{URL::asset()}} method, is more comprehensive and accessible to front end developers(Which you may be working with in a team project).
<link rel="stylesheet" href="{{URL::asset('css/style.css')}}" media="print" />
You may say that the difference is minimal, but when dealing with plenty of markup attributes ("ids, data-attributes, classes custom-attributes"), the HTML::style(), HTML::image(), HTML::link() methods can turn out to be quite long, and in-comprehensive to html/css/js developers.
It all varies and depends on the developer's style of coding, but in my opinion markup should remain as "raw" as possible, so that it is more accessible to front-end developers.
