Welcome Guest, Not a member yet? Register   Sign In
A more-useful uri_to_assoc

just 2 words needed: GREAT mod.


There are some major issues I see with xwero's implementation. The code doesn't separate the parameters from the controller chain, so a search on the uri can be problematic. While not always recommended, you could have a controller named search, and a parameter called search. With xwero's code, it would return the wrong pair. Additionally, if a parameter passed was the same name as another parameter.

For example: what.com/users/search/id/id/5.

$this->uri->segment('id') would return key value pair of id => 'id'

The op's code would return id => '5' because it takes the key value pairs after the controller chain or re-routed chain.

jazzfanatic less Miles more Armstrong Wink

I think it's an edge case most urls will have uniquely named segments. You could add the number of the segment as a parameter to the function but i think it would make the function too complex and a bit confusing for a few more cases.

I don't think it is as uncommon as you think, but I guess it depends on what you are using it for. For a very large app where you want to avoid all "edge cases" I would recommend the more complete approach. In the end, the usage for either is just as easy. I just know sometimes people get caught up more in being elegant rather than be fully bug free. I don't feel the original suggestion is bloated or complicated enough to really warrant using something that doesn't cover all the bases simply because the code is simpler.

Even with a very large app you can make non repeating urls. The idea of the segmented urls is to make them human friendly, humans only repeat themselves if they think it's needed.

Developers are taught to think of meaningful class and method names and you are suggesting to make urls confusing. If the controller is search you could name the parameter query. And the url you shown looks more like a the the mistake (double the). Elegant doesn't have to stand in the way of bug free.

If every function covers every base i think you will have very complex functions, where functions are supposed to be as simple as possible to make the app as light as possible. If you think like that you aren't going to use CI as many (all?) of the libraries have bases they don't cover.

I think you are misunderstanding my example as I forgot the function name. My custom routes make me forget it sometimes.

I put - what.com/users/list/search/id/id/5

and meant


users would be the controller, and search, and id are the parameters. I was simply saying that the value of a parameter could be the name of a parameter simply from user input or selection that has nothing to do with the programmer choosing poor controller names.

The function suggested is still very lightweight, and it separates the parameters from the controller, just like GET works. There are good reasons in a url like http://www.this.com/what.html?this=that, that a standard GET only takes what is after the ?. I think it is pretty nice to not worry about accessing anything but the parameters, but hey, it is just my opinion. I think one reason I like it so much, is that I have the router hacked so that we can go as deep into the folders as possible. So if I had what.com/members/profile/sharing/edit/save/1, and sharing is the controller with edit as the function, with the first example I just have save => 1 as the only pair. I do agree, for the general person yours works well, just the first example is an option if you want.

[eluser]Benjamin Midget[/eluser]
A GET simulation is worthless in my opinion if it cannot be trusted to fetch appropriate data.

A common example:

User searches for category and tags.

If the user searches for category: "tags" (which they should be able to do--they can search for anything they want), then you have just what jazzfanatic illustrated: site.com/products/search/category/tags/tags/something.

The most common use for GET is giving a search a hard-coded URL that can be shared and revisited. Thus, I'd argue that jazzfanatic's situation is actually a fairly common problem someone would run into with a GET simulation.

An app that cannot hold up to possible user searches, I'd argue, is broken. This is the exact reason why my implementation doesn't break upon searches. Thus if CI were to include this functionality (which I believe they should because they don't allow actual GET data), they'd have to use the version that accurately mimics GET.

The later version looks great, no doubt, but realistically operates as nothing more than a hack.

I recognize there could be problems but i still believe the percentage is minimal even with user input. Benjamin's example made it a little clearer but having a category tags and being able to add tags as a keyword still is far fetched IMO. Why should a visitor use forward slashes in his input and why should the code depend on it, if it's not a part of the site structure?

If you are not comfortable using the segment method mod i provided you could use a method that wraps the uri_to_assoc method
function get_sim($start,$key,$not_found = false)
   $pseudo_get = $this->uri_to_assoc($start);

   return (isset($pseudo_get[$key])) ? $pseudo_get[$key] : $not_found ;
I tried to create a function that doesn't make the use of the segment methods more complex adding a get like functionality.

[eluser]Benjamin Midget[/eluser]
If there are problems with the code, why use it?

Theme © iAndrew 2016 - Forum software by © MyBB