Thats what APC/any-other-mem-caching-extension is for.Originally Posted by mwmitchell
| SitePoint Sponsor |
Thats what APC/any-other-mem-caching-extension is for.
I totally agree. It's abuse of the URI-concept. Using slashes rather than ampersands doesn't magically turn your querystring into a URI. There may be an esthetic reasoning behind it, but I don't think that qualifies as an argument.
The common $module/$action URI-mapping is also questionable. The location-part of a URI should designate the location of a resource, but in this case, only the first part does this location, while the last part is a command on that resource. Ideally the command should be expressed through the HTTP-method. Since this is not not always practical, it must be propagated over either the location or the querystring (or headers, but this isn't practical either) - I do think that it would have been more correct to use the querystring, than the location.
Sorry, I'm not sure what you mean! Can you explain?
> IMHO, I see no advantage of using paired params in the path, over using the query string.
That's the same thought that I had, so this reduces (by an amount) or routes required but it also simplifies things some what. When you actually think about it, you are more concerned from a useability point of view, of a user going to somewhere sane, such as
Knowing that, that is a default, rather than be bothered about additional parameters, such a sort order, etc. Friendly urls or not, people still to some extent, expect to see ?column=date&orderby=asc in their urls.Code:www.domain.com/products/category/dvds/
Also, I don't see the point of having ?column=date&orderby=asc making the point and the purpose of routes pointless either; So the best bet is just to follow the validation of the provided routes and do what you will with the remainder of the path
Instead of loading the routing configuration/setup/whatever per request, read it once, and store/cache it in APC.
http://uk.php.net/manual/en/function.apc-store.php
http://uk.php.net/manual/en/function.apc-fetch.php
Yes. Setting up a default for orderby to asc, means it only has to appear in urls atmost 50% of the time for sorting desc.> IMHO, I see no advantage of using paired params in the path, over using the query string.
That's the same thought that I had, so this reduces (by an amount) or routes required but it also simplifies things some what. When you actually think about it, you are more concerned from a useability point of view, of a user going to somewhere sane, such as
Knowing that, that is a default, rather than be bothered about additional parameters, such a sort order, etc. Friendly urls or not, people still to some extent, expect to see ?column=date&orderby=asc in their urls.Code:www.domain.com/products/category/dvds/
Also, I don't see the point of having ?column=date&orderby=asc making the point and the purpose of routes pointless either; So the best bet is just to follow the validation of the provided routes and do what you will with the remainder of the path
I see. But what I mean is I don't want to set up routes everytime I build an application. It'd be nice to have good urls built to a specific/pre-defined structure without having to do anything, as an option that is. Using them as pairs does just that. Do you see what I mean?
I do understand what all of you are saying though. I'm rethinking this and doing some reading. Thanks for your useful comments.
-matt
OK, so in your opinion... does it seem more correct to use routing (not paired params) for parameters and a strict "real" location path for the controller and action? Something like:
/products/view/54
I realize that this isn't RESTful, but I can't see the point in implementing that REST because we don't have DELETE or PUT? I can see how you'd want to come as close as possible though. In which, the url above would be:
/products/54
Is that correct?
It seems so much more managable (for a programmer?) if you don't map/route your controllers, and let the filesystem provide the mapping. I do like the routing of extra parameters though, in comparison to paired params.
Opinion is important to keep in mind. I wouldn't claim to be able to tell the one true way to create URI's. It's not an absolute. But I will hold on to a distinction between location and querystring, where the location should describe the object, and the querystring describes what you want to do with it.
I think that /products/54 makes much more sense than /products/view/54. Or more obvious: /products/54?action=delete instead of /products/delete/54
I suppose that's true, but taken to the extreme, then we should use pagecontrollers ...
Very nice work! That's similar to what I've been working on -- the filesystem is the routing system, and the request handler is smart enough to know how to fallback to actions in default pages if possible. The main difference in my system is I don't use key/value/key/value parameter pairs like you do, I just have a list of parameter values. The dev user can always alter that if they wish.
I think routing is a fundamental aspect of a framework and I don't like any of the programmed or configured approaches to routing that most frameworks use (including RoR). Computers already have a routing system: it's called the filesystem. So let's use it.
All IMHO,
Jared
Willowgarden: rapid application platform for PHP 5
xajax: fast and easy PHP Ajax library
Web software architecture blog: The Idea Basket
I don't think it's wrong to use the query string, but I don't like the practice of having stuff like index.php?param=value&so=on. What happens if you change your backend from php to something else? Old urls will either break, or you will have to use the php extension on your new solution even though you're really using something else. The argument for pretty URLs ( other than being, well, prettier ) is that it provides consistent URIs that don't change. By decoupling your URLs from your current backend, you ensure that the URIs last longer.
OK, I have something more lightweight here. The controllers are mapped by filesystem, the actions are the first path param and the remaining params are handling by mapping. One of my goals was to make is as simple as possible.
Any comments?
-m
As you know, URLs should describe resources. In the absence of other types of requests than GET and POST, assigning further data into the URL itself is a must, but still a hack. In this respect I don't think either way is more wrong than the other.
I agree. I wouldn't put actions in the query string, though, but that may be just out of habit.I think that /products/54 makes much more sense than /products/view/54. Or more obvious: /products/54?action=delete instead of /products/delete/54
Actually I don't think DELETE et al would make any difference. This is one place where I think maybe REST is a bit off target.
There are an infinite number of actions, you could apply to a resource. Say I have a resource "user", identified by the URI /users/ezku. If I need to remove that user entirely, issuing a DELETE on it would be fine, but what if I just want to close the account, but keep the resource. Which method is right then? Trying to create a standard vocabulatory of actions is just non-sense. The only general auumption that can be made is that a request either reads data or it changes state. GET and POST sufficiently covers this. It's the TwoIsAnImpossibleNumber rule in effect.
I don't think it's just habit. The request-method tells if we are reading the resource or changing it's state. If you are POST'ing, you would need to specify further in which way you are changing the data; Are you updating, or are you deleting, or something completely different? This information shouldn't be part of the URI, since it's not part of the resource itself, but rather something, you're doing with the resource.
I really see only two possibilities within HTTP - headers or querystring. The latter is the only practical choice with current browsers, although XmlHttpRequest opens up for using headers for the task.
OK how about:
/destroyer/product/54
/creator/product/54
/editor/product/54
More seriously, I'm think that I'm going to go with $_GET['view'] for changing view states. And $_POST['do'] for incoming data. Something like:
VIEW
/admin/products/
/admin/products/54/?view=edit
/admin/products/54/?view=delete
/admin/products/?view=create
What about the fact that it says products (plural) and then there is a single id? It's going a little far but would it technically need to be /product/54/?view=edit and then /products/ for the list view?
-matt
EDIT: Now I can see where filesystem mapping has some drawbacks. Config routing would let you push completely different urls to a single controller. Hmm...
I suppose that could work, but I don't like it. Putting the verb before the data, detatches the method from the resource - it's like procedural programming, where /products/54?view=edit is analogous to object oriented programming.
I think the plural makes sense. /admin/products is a collection of products. /admin/products/54 is a product from this collection.
exactly.
OK, sorry to keep dragging this out but...
I've been going with the filesystem method of mapping controllers. Previously, I said something about having routing for products and for product, so they both go to the same controller. But really, it seems to make even more sense that those 2 urls get 2 different controllers. Because they are doing different things. So there is no need to route, and in fact routing could make things more complicated code wise and *possibly* more confusing for something coming into the framework. I think it'd be a better choice to create a seperate controller for each url, and either extend or use composition to handle the duplicate code problem.
I'm going to post a new version of what I have shortly.
-matt
New version of what I have going. I should explain what my goal is here. I'm trying to make a *simple* url to controller routing framework. What I have posted is about as far as I plan on going with it, with the exception of implementing view handling. This is the sort of thing I need most of the time when I build sites. The URL routing is important to me because it is the most fundemental part of my goal. Please have a look and let me know what you think...
-matt
Sorry to revive this thread, but I'm working on something at the moment and am reluctant to have a pre-generated set of routes. Instead, I see a possible mix of filesystem-based and rule-based routes. Suppose that the first few subdirectories mapped to the filesystem. By few, I mean that it would map to the first available and existing controller (eg: /admin/products/ would map to /admin/products_controller.php whereas /articles/ would simply map to articles_controller.php). Now, since we now know what controller to call, we can ask the controller for its routing information to map routes to actions and to determine the proper item.
What do you think of a hybrid system like this?
Edit:
Just noticed Serberus' post on the first page. I think we had the same idea. I have gone ahead and implemented it in my code and it seems to work fine. What were your initial gripes with this scheme of url mapping?
Last edited by b1ind; May 30, 2006 at 08:55.
In case you need a PHP URL mapper but want something much simpler I have written a simple URL mapper for PHP that uses a simplified URI Template syntax and is available in a single PHP file. I've called SimpleUrlMapper for PHP, it is open-source with a BSD license and it is hosted on Google Code. It does not use an MVC approach because in some cases MVC is either overkill or is not easily doable such as when you need a RESTful mapper to work inside an existing framework (i.e. inside WordPress, for example.)
It's not meant to be all things for all people but for those who need what it has to offer it should save a day or two of coding. You can find it here.
I really like the way symfony handles routing.
http://www.symfony-project.org/book/...Routing-System
You can control how URLs are written (module, action, parameter stack) on a per action basis.
I don't like the way you have to setup rules to interpret the URI and then use link helpers in the view to generate links. Assuming you've broken your app up into MVC components, the controllers should know how to invoke their own methods via web requests anyway, so why can't they just pass the necessary info over to the view rather than requiring brains in the templates?
I agree. My own framework has a simple method where www.example.com/controller/handler simply calls the Controller::Handler() method, with any additional parameters left to the handler itself to interpret and, well, handle.
Posting Permissions
Bookmarks