Monday, October 24, 2011

CakePHP 2.0 : Autoloading Classes

The CakePHP 2.0 migration guide talks a lot about autoloading of classes.  For users of CakePHP, not much as changed.  There are just some new rules to follow when dealing with loaded classes.

Here are some guidelines that I'll be following:

  • When dealing with models in a controller, use $this->loadModel().  This should be nothing new.  If you're in a component, and have a reference to the operating controller, then $this->Controller->loadModel() will be more your style.
  • When dealing with models everywhere else, use ClassRegistry::init().  In fact, unless you need to load the model in to your current instance, $MyModel = ClassRegistry::init('MyModel') should be the usage.
  • When referencing a class, use App::uses().  Let us say that you have a model that needs to access a library that is going to do some REST, RPC or SOAP calls for you.  Before the class definition, you might have App::uses('MyRPCLib','Lib');  and in the code, you need $MyRPC = new MyRPCLib();  Autoloading only loads the class, it does not instantiate it.
  • When referencing a file that does not have classes, use App::import().  Usually used for Vendor files containing functions.
If you're finicky, you might also have App::uses('ClassRegistry','Utility'); at the top of any file using the ClassRegistry class.  However, if your application has any models defined, then chances are, ClassRegistry has already been loaded, as a part of the Model class.

It is highly recommended to have App::uses('ClassRegistry','Utility') at the top of any file using the ClassRegistry class.  In fact, it's highly recommended to have an App::uses() statement for any class that has not been previously seen in any given file.  This becomes relevant when you are setting up tests, and your component tests don't know where to load the Component class from.

Thursday, October 20, 2011

Preparing for CakePHP 2.0 : Views

CakePHP 2.0.0 has been released for a couple of days now.  I've been watching it go through the release candidate releases, but I haven't got my feet wet, or hands dirty until yesterday.

For anyone considering converting their CakePHP 1.X app to CakePHP 2.0, I recommend reading the migration guide, then reading the manual, from start to finishing, then read the migration guide again.

As a learning exercise, I'm converting one of my smaller projects to CakePHP 2.0.0.  I think I may have even skipped CakePHP 1.3, and jumped straight from CakePHP 1.2.

I've been following the migration guide, and as awesome as it is, there's so much stuff to think about.

So far, my approach has been as follows:

  • Delete the old cake directory, and global vendors and plugins, if they're empty.
  • Add in the new lib directory, containing the new Cake directory, and the global vendors and plugins directories.
  • Rename the app directories to match the new naming conventions.
  • Move app_controller.php to Controllers.
  • Update the Config files such as core.php, bootstrap.php and database.php.
  • Rename the controllers, components, models, behaviours, datasources, and helpers to the new naming convention.
  • Get a basic screen working! For me, that was the login screen, and even then, it was only the GET side of things that I wanted to get doing.
Make sure you're using some sort of source control, and check in after each step, or as often as you feel you need to do.  

If you're using Git and Windows, watch out for directory renames.  I ended up in a strange situation, where my app/config directory was split into app/config and app/Config in Git, even though there was only one app/Config directory on disk. I temporarily renamed to app/Configs, committed the change, then changed it back to app/Config.  That seemed to do the trick.

After getting the GET side of the login screen going, I've decided to convert all my Views first.  View conversion is fairly standard.  Even if you're not converting to CakePHP 2.0 right now (you're waiting for the first point release, right?) here are some things you can start doing now to make the conversion easier.

  • Stop using e(). It's gone in CakePHP 2.0, so just use echo.  There are a whole bunch of other functions that are going the way of the dodo, so perhaps hunt them down, and use PHP native alternatives now.
  • Start using echo __('Text', true); for your translatable strings, instead of relying on the echo inside __().  When you migrate, you can remove the ", true" at your leisure.  This is quicker than having to insert echo.
  • Stop using local variables for helpers.  You might have been in the habit of using $html->link().  You'll want to stop that now, and use $this->Html->link() instead, since the former won't work in CakePHP 2.0.
That's about all I've been doing with my views for the moment.  I've also been enjoying __() acting like sprintf(), and I've been able to remove sprintf() statements in quite a few places.

One of the things you can't prepare for is $this->data becoming $this->request->data, but that should be a search and replace.

One thing I'm not going to enjoy is converting the LdapDataSource to CakePHP 2.0.  Hopefully it shouldn't be a big deal, but it plays an important part of the login process.  Actually, it looks like CakePHP has an LDAPSource, but the conversion it not completed.  That might be a golden opportunity to contribute something back.

Thursday, October 6, 2011

Website Design : Things a programmer doesn't see

It's a bit of a misleading title, since I'm not actually going to give you a list of things that a web programmer doesn't see when it comes to web design.  That is firmly in the domain of "I don't know what I don't know", and I don't know web design.

But the chaps over at Primate do.  And I'm continually impressed with their contributions to expanding my knowledge of web design on their, for want of a better term, community site, 8 Gram Gorilla.

I've been following the gaming blog of one of the founders, Gordon, for some time, so when I saw that he'd started his own company (well, it might be a joint venture) and then put together 8 Gram Gorilla, I got very excited.  Gordon is quite an engaging blogger, and seeing that he also does web design (actual design, not just web programming code monkery*), I get a warm feeling like I'm witnessing brilliance.  If I was still working in the UK, I'd want to work for those guys.  Not sure that they'd take me with my lack of Ruby experience, but geez, it would be worth dropping tools for a few weeks, just to make a solid dent, and wrap my skull around those Ruby code blocks.

Any way, the gorilla has given me Compass/Sass this year, and now it's given me the grid system, from this article.  And not just one grid system, but two!  960.gs and 978.gs.  I didn't even know these were a thing!  The Holy Grail is nice and all, but I could have been using a grid system to position elements in a layout.

And now, having read a bit about these grid systems, and the tools that they provide for changes in CSS, particular when it comes to variable browser widths (like when you rotate your phone, and expect everything to make use of that extra width), the bubbles are beginning to form in my mind.  I've got some projects coming up, some changes to apply some of this grid system brilliance.

The question on my mind now is "What is best practice for using Compass/Sass and external CSS like 960.gs?".  Do you rename the CSS supplied by the grid system to .scss, and have it included in your Compass/Sass build?  Or do you keep the two separate, and define yourself a rule that your own CSS should never ever reference the classes supplied by the grid system.  Maybe this is a question for Stack Overflow.  But not tonight.  It's getting late, and my cockatiel has been waiting patiently on my shoulder while I read about web design and grid systems, and then blog it all.

* Monkery: Monkery is to monkey, as dickery is to dick, the type of dick that Wil Wheaton will block you from his Twitter and Google Plus for being.