SitePoint Sponsor

User Tag List

Page 2 of 2 FirstFirst 12
Results 26 to 49 of 49

Thread: URL mapping

  1. #26
    SitePoint Wizard Ren's Avatar
    Join Date
    Aug 2003
    Location
    UK
    Posts
    1,060
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by mwmitchell
    Nice. Thanks for that I should have looked at that earlier. That's the kind of thing I want to add. I think there is a need though for a pre-setup default style of routing. It'd be a drag to set up routes for every application/request.
    -matt
    Thats what APC/any-other-mem-caching-extension is for.

  2. #27
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ren
    IMHO, I see no advantage of using paired params in the path, over using the query string. So /myapp/listview?sort-by=name&per-page=4.

    Perhaps using the defaults, sort-by=name and per-page=4 this would reduce to /myapp/listview.
    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.

  3. #28
    SitePoint Guru
    Join Date
    May 2003
    Location
    virginia
    Posts
    988
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ren
    Thats what APC/any-other-mem-caching-extension is for.
    Sorry, I'm not sure what you mean! Can you explain?

  4. #29
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    > 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

    Code:
    www.domain.com/products/category/dvds/
    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.

    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

  5. #30
    SitePoint Wizard Ren's Avatar
    Join Date
    Aug 2003
    Location
    UK
    Posts
    1,060
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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

  6. #31
    SitePoint Wizard Ren's Avatar
    Join Date
    Aug 2003
    Location
    UK
    Posts
    1,060
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    > 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

    Code:
    www.domain.com/products/category/dvds/
    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.

    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
    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.

  7. #32
    SitePoint Guru
    Join Date
    May 2003
    Location
    virginia
    Posts
    988
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ren
    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
    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

  8. #33
    SitePoint Guru
    Join Date
    May 2003
    Location
    virginia
    Posts
    988
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    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.
    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.

  9. #34
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by mwmitchell
    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?
    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


    Quote Originally Posted by mwmitchell
    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.
    I suppose that's true, but taken to the extreme, then we should use pagecontrollers ...

  10. #35
    SitePoint Enthusiast
    Join Date
    Aug 2005
    Location
    Santa Rosa, CA
    Posts
    67
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by mwmitchell
    I've been working on a mapping sceme for urls to controllers and actions. At this point it works fine. I don't know if I've every seen anyone doing it quite like this so I wanted to get some feedback.
    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

  11. #36
    SitePoint Enthusiast
    Join Date
    Nov 2005
    Location
    Norway
    Posts
    26
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    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 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.

  12. #37
    SitePoint Guru
    Join Date
    May 2003
    Location
    virginia
    Posts
    988
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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
    Attached Files Attached Files

  13. #38
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    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.
    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 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 agree. I wouldn't put actions in the query string, though, but that may be just out of habit.

  14. #39
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ezku
    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.
    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.

    Quote Originally Posted by Ezku
    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 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.

  15. #40
    SitePoint Guru
    Join Date
    May 2003
    Location
    virginia
    Posts
    988
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    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
    OK how about:
    /destroyer/product/54
    /creator/product/54
    /editor/product/54

    I guess that could work right? Kind of kidding but an action could be a resource, if it were an looked at as an application?

  16. #41
    SitePoint Guru
    Join Date
    May 2003
    Location
    virginia
    Posts
    988
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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...

  17. #42
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by mwmitchell
    /editor/product/54
    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.

    Quote Originally Posted by mwmitchell
    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?
    I think the plural makes sense. /admin/products is a collection of products. /admin/products/54 is a product from this collection.

    Quote Originally Posted by mwmitchell
    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...
    exactly.

  18. #43
    SitePoint Guru
    Join Date
    May 2003
    Location
    virginia
    Posts
    988
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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

  19. #44
    SitePoint Guru
    Join Date
    May 2003
    Location
    virginia
    Posts
    988
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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
    Attached Files Attached Files

  20. #45
    SitePoint Enthusiast
    Join Date
    Feb 2004
    Location
    Montreal
    Posts
    77
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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 07:55.

  21. #46
    SitePoint Member
    Join Date
    Oct 2006
    Posts
    14
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  22. #47
    SitePoint Enthusiast
    Join Date
    Jan 2003
    Posts
    91
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  23. #48
    SitePoint Addict
    Join Date
    Feb 2007
    Posts
    251
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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?

  24. #49
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by cuberoot View Post
    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.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •