Unconventional

Are you looking for a way to resolve things like translation, validation and config from the Laravel IoC? Look no further! Make yourself a service provider (whether in a common tools package or in your project) and add the following to it in the register method: $this->app->bind('Symfony\Component\Translation\TranslatorInterface', function ($app) { return $app['translator']; }); $this->app->bind('Illuminate\Config\Repository', function ($app) { return $app['config']; }); What you've done is mapped all the string-registered services to their most abstract but also most specific types.  Config is a good example of where you should be binding the class name and not an interface because the only interfaces it implements are ArrayAccess, and that's obviously wrong! :) Happy constructor-injecting!

At my job, we've been doing a lot of learning and development using Taylor Otwell 's Laravel 4 PHP framework.  As we've become more familiar with it, we've had to come up with better ways to structure our projects outside of what the documentation indicates and the default distribution that is provided. If you've been working with Laravel 4 for any amount of time or come with experience from another framework and are just getting started, you've probably noticed that there are a lot of different ways to cut up your projects. Choice is nice, but sometimes it can be paralysing or misleading. Concrete Advice This post is done in such a way that you can just skim the headings, but if you want a detailed explanation in each section, feel free to read in where necessary. While I can't say the entirety of my advice is in practice throughout the community, I can say that we are starting to use it, and to very good effect at my job.  Especially consider...

For anyone configuring their own error handlers in Laravel 4.x, a feature suggestion I made has been implemented to have the handlers placed at the top of the queue rather than bottom. This default behaviour makes more sense given that as you get further into your app, you'll likely be defining handlers less likely to return a response, or more likely to want to pre-empt other error handlers entirely. While that's a safe assumption, there's still the mechanism to add a handler to the bottom of the pile with pushError() if you end up needing it still. Here's a quick reminder of how you can use either of these features: App::error(function (Exception $exception) { /* Your handler here! */ }); App::pushError(function (Exception $exception) { /* Your handler here! */ });

I've had a bit of a mental break over the past few weeks thanks to the North American holiday season.  This has given me a chance to focus more on some of my other interests like gaming. My darling wife  +Kristy Trauzzi  (ooh, new G+ integration for blogger!) got me a Wii U for xmas and it's been an absolute blast. The upgrade process from the old Wii allowed me to export all the Miis I've created over the years.  Another neat feature is that I can spit them out onto an SD card!  So, if you're a Little Britain fan like us, you might recognize these two.  Of course, I've included the QR codes should you desire their company... I don't like it!

If it isn't already obvious from my previous posts, I've been spending a lot of time on the client side of things with JavaScript and the Dojo toolkit. I had a chance last weekend to show off a little bit of Dojo and once I got past the lightweight technique for bootstrapping it from the server , my demonstration suddenly got a lot less glamorous. I think part of it got lost amidst what resembled gruelling swing form code.  I was lucky in that I already had some completed forms to show off, so it was possible to show the kind of experiences you can deliver when you use a good client-side framework. There was however a takeaway for me which after a lot of thinking, I think I've managed to figure out... It's Holding you Back! Your server side form library is killing your UX, coupling your model to the view and tying down your options client-side. I've worked with forms in Symfony 1.4 extensively and have become quite adept at bending them to whatever need ma...

If you're puzzling over how to create the usual password and confirmation fields using Dojo,  try out this approach that I came up with for a project I'm working on: var passwordCheck = new ValidationTextBox({ id: "password-check", placeholder: "Password again...", type: "password", intermediateChanges: true, invalidMessage: "The value you have entered does not match the password you have chosen..." }); this.password = new ValidationTextBox({ name: "password", id: "password", placeholder: "Password...", type: "password", intermediateChanges: true, onChange: function () { passwordCheck.set("pattern", this.value.replace(/[-[\]{}()*+?.,\\^$|#\s]/g, "\\$&")); if(passwordCheck.value) { passwordCheck.validate(); } } }); It's really simple and keeps everything lean, relying on as little implementation code as possible.  Simply put, every time the pa...

If you're using Dojo and Rails & are having some issues with asyncs to your server being rejected, consider employing the following in your xhr or JsonRest : headers: { "X-CSRF-Token": query("meta[name='csrf-token']").attr("content") } In my particular situation, I was trying to do HTTP POSTs and Rails was terminating my session likely because it perceived the lack of a CSRF token as a hijack attempt.  The code here simply adds the token as an HTTP header in the request. I think once I've had some time with this fix, I might look at subclassing these objects for my project and pre-populating the header.  Then I'll simply substitute my implementations for the default Dojo ones. Which - come to think of it - would probably make for a good case when discussing the advantages of AMD . Fear not, if you happen to be using jQuery and are experiencing this issue, here's an equivalent solution .