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...
December was a month of a lot of self-reflection. It is for everyone, I think, especially with the New Year at the end of it. I think a lot of people in our industry suffer with the same problem I have suffered with recently, and that’s feeling that keeping up with changes and developments is almost a full time job in itself.
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.
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.
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.
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.
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.
How to comment your code is covered exhaustively on pretty much every programming blog I’ve ever read, but that doesn’t stop me from feeling the need to write this post, a post offering my feeling on comments, concluding with how I use ‘scaffold commenting’ as a framework for writing my own code.
It’s been some time since I’ve written here, but in helping a colleague with an approach to a problem today, it occurred to me that a very good question to ask as a developer is why am I writing this code?.
After several months of having to work around a really annoying issue with random mod_rewrite rules in my .htaccess files failing, I’ve finally got to the bottom of the problem. It’s all down to a component of mod_negotiation called MultiViews, which intercepts requests to file paths that do not exist and makes a ‘best guess’ as to which file to serve (a colleague informs me that this can be useful when making use of HTTP/1.1 content negotiation).