Monthly Archives: March 2012

Query Strings in CodeIgniter

Posted on by
1

CodeIgniter really does not like query strings. It's just downright mean.

  1. $this->uri->uri_string() removes the query string. Why?
  2. current_url() from the url helper removes the query string. Why?
  3. You can use query strings instead of segment-based urls such as http://example.com?c=controller_name&m=method_name instead of http://example.com/controller_name/method_namebut they have a nasty warning:

If you are using query strings you will have to build your own URLs, rather than utilizing the URL helpers (and other helpers that generate URLs, like some of the form helpers) as these are designed to work with segment based URLs.

Not a good deal! Plus there are no built-in helpers or libraries to grab the query string and do stuff with it.

But why use query strings at all? I thought segments were better?

  1. Unlike URI segments, query string segments are all optional. If you have 5 key/value pairs, you can include just items 1 and 5 if you want.
  2. Unlike URI segments, query string segments can be put in any order. If you have the same 5 items you can order them like 4,5,3,1,2 if you want.

These are big deals, because they are a giant pain in the ass with segments. For instance, let's say you have 5 segments and you just want to change segment 5 from the default. You have to send the default values for segments 1-4 first! So your url ends up looking something like this:

http://example.com/1/true/false/0/fifth_segment

Looking at that url it makes no sense. You don't know what 1, true, false, or 0 refer to. But you are forced to type them all. What happens if one of these default values change? Or if the order changes? Or if you have to add or remove a segment? You have to change all your URLs! What a pain in the ass!!

Now segment-based urls are fine for hierarchical websites such as /products/outdoor/chainsaws/12. But for web applications, they totally suck. The way I see it there are two possible ways to fix this in CodeIgniter. You can either extend the URI and URL classes or write a new helper/library. I chose not to mess with URLs and just create a helper so I could use it in a view by just calling a function without $this->helper_name-> in front. So here's my query_string_helper:

Query String Helper
Download

It has just two functions:

  1. query_string($add, $remove, $include_current)This just echoes the query string with no params.
    1. Param 1 allows you to add an array of items to the query string.
    2. Param 2 you can either send a string of a key you want to remove or send an array of keys you want to remove.
    3. Param 3 lets you ditch the current query string if you want and just make a new one.
  2. uri_query_string( same params as above ) This includes the full current uri with the query string on the end. It allows you to manipulate the query string in the same ways as above.

Now you can just replace all your $this->uri->uri_string() or current_url() calls with uri_query_string() and you're good to go!

Getting CIUnit to work with Sparks

Posted on by
1

I recently got bit by the Sparks bug again. If you don't know, Sparks is like CodeIgniter's version of Ruby Gems. It's a command-line-based package manager that lets you install stuff for CodeIgniter quickly and keep it up-to-date. It's a great idea and I want to port my libraries over to this system.

So I thought I'd try to get Kenji's CIUnit working with Sparks. His wiki says to just change one line in MY_Loader.php (which is created by Sparks) and you're good to go. I found this to not be the case, so I did a little digging. Here's what you need to do to get them to play nice together:

If you haven't already, start by installing Sparks.

In application/core/MY_Loader.php change this:

define('SPARKPATH', 'sparks/');

to this:

define('SPARKPATH', APPPATH . '../sparks/');

Then in application/third_party/CIUnit/core/CIU_Loader.php change this:

class CIU_Loader extends CI_Loader {

to this:

class CIU_Loader extends MY_Loader {

Then you should be good to go. CD back to your root/tests in the terminal and hit phpunit. If you've loaded sparks, they should now work without erroring out. Huzzah!

console.log() and Internet Explorer

Posted on by
1

The Problem

I use console.log() in javascript all the time for debugging. It's a great way to display errors without printing them on the screen. Sometimes I forget to delete them all before deploying live code. Come to find out that if even one console.log exists in your javascript, IE will stop dead when they see it and throw a small javascript error. They do not understand console.log unless the F12 developer tools are open.

One thing to keep in mind is that console.log will actually work if you have the IE developer tools window open, even if it's minimized to the bottom of the IE window. It will even work if you open the developer tools and completely close them. So everything will seem fine, but when a customer visits the site in IE7, they will run into errors. (IE7 does not include developer tools but they can be installed as an add-on) This is a huge problem!

The Solution

Fortunately solutions exist for this, courtesy of Arlo Carreon. You could of course remove all console.log method calls for production code, which you should do. But what if you forget one? That's where this solution comes in. Declare this function at the top of your JS:

var console = console || {
    log:function(){},
    warn:function(){},
    error:function(){}
};

This will replace the console object in IE with empty methods for the usual console commands. No more javascript errors! I highly recommend you put this at the top of ALL of your custom javascript code. Now if only Microsoft would patch IE to allow for console.log() to fail silently if developer tools are not open!