Laravel 4: Setting view data used in the layout across all routes

I wanted to include a count of a model in the dashboard menu of my app, but was struggling to find out how I could do this without calling ->with('model_count', Model::count()); in all controller actions, or setting the variable in each controller separately using View::share(), until I discovered ‘View Composers‘ in the Laravel Manual.

If you have data that you want bound to a given view each time that view is rendered throughout your application, a view composer can organize that code into a single location

My example view composer:

View::composer(array('layouts.master'), function($view)
    $view->with('players_count', Player::count());

I define my view composers in app/view_composers.php, which you can add to your app by following these instructions.

Laravel 4 – including new files you’ve created in app/

In Laravel 4 I wanted to add ‘View Composers’ to my app.  But I didn’t want to define these in routes.php or filters.php and couldn’t really work out an appropriate place for it to go.  So I decided I’d create a new file in app directory called view_composers.php.

I expected (incorrectly) that composer dump-autoload would automatically suck this file in to the list of automatically included PHP files.

But actually you need to tell your app to load these files when the app starts.

So how do you do this?  Well thanks to a newly added chapter to CodeBright (‘where does it go?’), I read that Dayle recommends modifying the file below to do this:


I just added the code below to the bottom of this file and I was away:

| Require The View Composers File
| I've used View Composers to add common variables across known views. Including...

require app_path().'/view_composers.php';

Now I’m convinced by… Sass

My current job role partially tasks me with trying to optimise our web site production processes, finding opportunities for us to improve productivity and quality.  Part of this process involves working closely with front end developers (who have a stronger focus on HTML and CSS authoring than perhaps I generally do) to marry up the bespoke software we implement using PHP & MySQL, and the user interface, typically crafted in HTML and CSS.   I’ve noted for some time the ubiquitous usage of CSS pre-processors and how they have matured and developed, and so felt that I should investigate what benefits usage of such a tool might bring to us as a team that build web sites.

Continue reading

Controlling project budgets as a developer

I’ve not yet had a chance to work in an authentically agile way on any of my projects, but have given a lot of consideration to finding ways for me and my colleagues to try to keep on top of and anticipate problems with available timescales for development tasks.  We still use the waterfall model and rely heavily on software estimates to be able to implement this effectively.  As is explained perfectly in this blog post by Michael Wolfe, software development estimates are very rarely accurate.  As developers, we can help our businesses address this problem before, during and after each project.

Continue reading

Remembering that what you’ve built is better than what you had

As I mentioned in my previous post regarding the available approaches for handheld optimisation of web sites, sometimes the choice we’ve made as a web development company is to provide a specific handheld-optimised experience in the form of what we call a ‘mobile website’.  This is a website based upon the same content management system, base content and functionality as the desktop site, but with more filesize-conscious templates and a design that is more touch aware than relying on small click areas for a mouse pointer.  We have found that this works very well where a ‘desktop redesign’ isn’t required for a web site, as it provides a more cost-effective way for our clients to maximise their mobile conversions.

Continue reading

There is not a “one size fits all” answer to the “handheld device optimised web site” problem

As someone involved in the maintenance of web sites up to 15 years old, a common question I’m answering these days is “What should we be doing about mobile visitors to this web site?”. I find that rather falling to the same answer every single time, I am giving different answers to different people dependent on their situation. And I think this is the approach we should all take right now, providing the solution that’s right for the situation in question, rather than the solution we’re most comfortable providing.

Continue reading

Quality Control and why it matters for your web development business

As web developers, we all-too-often fall in to the trap of releasing new web sites (or more commonly, new functionality on existing web sites) prematurely.  I think this problem is particularly prevalent on the web because of how easy it is to apply changes to our software post-release.  This is in stark contrast to the games industry (where games ship on disks and are in a way much more ‘final’ than a web site release, and where patches can be released they have to go through a long and expensive approval process with the platform vendor e.g. Microsoft or Sony).

Whilst we are blessed with a simple ‘revision’ process, what we don’t consider is the damage that releasing and retrospectively correcting broken web sites does for all involved in the creation or use of the web site.

Continue reading