This forum doesn’t allow zip attachments, so I’ve posted the patch here:

Input.php Patch

This patch is for the Input.php file in /system/libraries

To enable GET parameters, you’ll need to change your config to use PATH_INFO.  Look for the following line in /application/config/config.php:

Change it to:

The patch for Input.php are pretty minor.  I’ve added a new member variable to the input class that tells you if you are involved in a postback or not.  Usage:

Finally I changed the post() method of the Input class to check both the $_POST and the $_REQUEST.  It checks post first, then request.  If specified in the config, it’ll XSS clean them both.

I understand that the main developer feels strongly about using GET, but my angle is that GET should “modify” the resource so that your URL’s point to “resources” and your GET parameters “act” on those resources.

Anyways, I hope this is helpful to someone.  We’re using it in production on a public API we’re developing for our site.

Thanks,

Jon Gilkison
massify.com

Errm please explain again why we need $_GET ?

gazza - 10 May 2007 01:42 AM

Errm please explain again why we need $_GET ?

If I want to track affiliate on every single page, I will do:

http://www.example.com/dir/page1234?aff=xxxx

Do you have a better way to implement this without using $_GET?

How about:

http://www.example.com/dir/page1234/aff/xxxx

Then you can use either of these:

Check URI Class in the User Guide.

Yeah

Do you have a better way to implement this without using $_GET?

linux pretty much said it all.

I’m a bit of a formalist when it comes to RESTful URLs.

Let’s say you want to get a list of users but filter them by certain criteria.  You want that criteria bookmarkable by end users.  This requirement alone rules out using POST variables for your filtering, and using URI segments would be unmanageable. 

Let’s say your resource endpoint looks like:

http://www.massify.com/people/

By default this is a list of everyone on your site.  But you need to filter by four or five fields out of, let’s say, fifteen total fields that could be filtered on.  For this example, I want to see everyone that’s within 15 miles of the zipcode 11231 that have joined within the last 10 days.  How would you structure your URI so that was a) possible and b) semantic?  The answer is that you can’t.

Without GET, you’d have to come up with some insane URI scheme that would be hard to manage and that would ultimately end up defeating the purpose of RESTful URL’s.  Which url is more descriptive, eg. semantic?

http://www.massify.com/people/11231/5/10

http://www.massify.com/people?zip_code=11231&max_distance=5&joined_before=5-1-07

I suppose you could do something like:

http://www.massify.com/people/zip_code/11231/max_distance/5/joined_before/5-1-07

But that scheme doesn’t really work for CI because CI will now look for a method called zip_code and 404 because it can’t find it.

My personal belief is that URL’s should be:

http://whatever.com/<OBJECT>[/<ACTION>/<IDENTIFIER>]?<PARAMETERS>

For example:

http://whatever.com/people/detail/jawngee

To each their own, I think my patch opens up the best of both worlds.

linuxbz - 10 May 2007 07:49 AM

How about:

http://www.example.com/dir/page1234/aff/xxxx

Then you can use either of these:

$aff = $this->uri->segment(4);

$array = $this->uri->uri_to_assoc();
$aff = $array['aff'];

Check URI Class in the User Guide.

This is a total trap:

What happens when you need to restructure your URI segments? 

Two side effects:  You have to change your code, and whatever bookmark or links no longer work because you are using indexing to fetch parameters instead of named keys as you would get with $_REQUEST.

I would not use the first one for the reason you gave.

The second, using

will give you named keys with only the restriction that they should be in pairs.  You can even change the offset if you want some “hardwired” after controller/function.

linuxbz - 10 May 2007 07:49 AM

$aff = $this->uri->segment(4);

My goal is to tracking EVERY single page. So your segment(4) is not general. GET method is still the best and easiest way to achieve my goal.

will give you named keys with only the restriction that they should be in pairs.

Your second solution is difficult to implement too because of this restriction.

I’ve done similar things with $this->uri->uri_to_assoc(); for displaying sorted data. I got a quite large number of params, and managed to make it work nicely, by providing default values when not everything is given:

domain.com/products/search/term/aaaa/cat/57/ord/p/dir/a/from/12/to/34/loc/gbe&esp/

so that’s 7 params.

My only good reason for using GET was simple search forms without constructing the url with javascript. I ended up using post method, posting to a function that would take post data, construct the segmented url and redir to that url, so it’s bookmarkable and everything, which turns out to be almost a transparent process for the end user.

But why should we overload the server with 2 requests just for one search (POST and GET) when we could just do a GET and act on the arguments ? Javascript doesn’t sound good either.
These are 2 hacks for a non existent problem. I understand that it’s nicer to use just PATH_INFO, but is GET itself that bad to be forbidden ?
I’ll just go with the patch, thank you jawngee.

Normally I’d avoid using GET vars in CI apps, but sometimes it is unavoidable, such as implementing a facebook app with CI (facebook supplies the URI get vars, I can’t control that.)

To work around this, I simply “undo” the CI GET var clobbering:

Now $_GET has the GET vars again.

Thanks for the patch! I’ve just started using it. Have you experienced any problems with it? Seems to work fine for me…. but just wanted to make sure again..

Why patch Input.php when you can extend it to use your own logic?

All I do to enable $_GET is to put this file (MY_Input.php) in my application/libraries folder:

I think thats a much more elegant solution as no patching is required!

You still need the following in your config file:

Sounds good Al!! I’ll try it right away!

Oh, one more thing. Make sure your subclass_prefix is ‘MY_’ (in your config file):

Otherwise you will need to rename the MY_Input class and file to <WHATEVER>_Input.