SitePoint Sponsor

User Tag List

Page 1 of 2 12 LastLast
Results 1 to 25 of 34
  1. #1
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Best Practices For Clean Urls

    Whenever I read posts related to clean urls, they always seem to be related to setting up apache with mod_rewrite to redirect all requests to a bootstrap file, typically index.php. While rewrite rules can get quite complex, there are a plethora of examples available that handle the most common use cases. Nobody really mentions what you have to change in your application in order to accomodate clean urls, however. I'd eventually like to turn this into a tutorial, but for now I'm posting the best practices I've found. If anyone else has found some useful information along the way, feel free to post and I will incorporate your comments into my final tutorial.
    * * *
    I decided to rewrite the url system for the in-house CMS built by the company I work for, Bright Bridge Studios. I was motivated in part becuase it had been on my list to do for a couple of months, and also in part because I had a paper for school I need to work on, and I was procrastinating I wanted to do something really useful for our system that wouldn't take much time. However, I soon discovered that there is a lot more to using clean urls than mod_rewrite.

    1. Relative urls.
    The first issue we ran across is relative urls. In the existing site, every page was handled by either index.php or pages.php, both in the same folder. Thus, a url for an image, stylesheet, script, or other physical resource such as "images/header.jpg" would look in that same folder. With clean urls, however, a url like /about/ would break relative urls. To fix this, there are two options (that I know of): using a <base> tag, or always using absolute urls. We want our code to work no matter what folder or server it's dropped on, so (for now) relative urls are a must. I suspect some url generation could allow absolute urls to be used without harm.

    2. Url generation
    An initial requirement for us was to allow our site to work with or without clean urls enabled. If a page was accessed directly, ie pages.php, then the standard pages.php?tabid=1&pageid=2 would be generated. If a clean url was used, such as /tab/page/, the rewrite would resolve to our bootstrap which would enable clean urls to be generated. I had a nice little class that would spit out either type of url depending on a clean url flag. Things got really complicated when I started doing, for example, blog posts that didn't fit within our standard url scheme. Thus, I had to create separate methods to handle those specific use cases, and eventually I was passing so much information to these methods that I might as well have had if statements in the urls. The solution I found here was to handle standard urls in a different manner. If a clean url was http://www.site.com/site/blog/post/ then a standard url would be http://www.site.com/index.php?route=/site/blog/post/ and then all I had to do was determine whether to use $_GET['route'] or $_SERVER['REQUEST_URI']. All links could then be displayed like this: <a href="<?php echo $url->render('/site/blog/post'); ?>"> and would never need to know which url system I was using.

    3. Link Anchors
    Our designer uses back to top links in footers using link anchors, or href="#top". We found out after using the <base> tag that link anchors are broken. #top resolves to the url in the base tag, so if you have <base href="http://www.site.com/site/">, then #top links to /site/#top even if you are currently at /site/blog/post/. The solution to this is to paste the current page's name before the hash, so <a href="/site/blog/post/#top">.

    4. Root directories
    Sites aren't always in the site root. For instance, on our development box, we have a folder system of /clients/[client_name]/ that allows every site to be accessed through our own domain. Thus, we need a way to isolate the root directories from the actual url, ie /site/ from /blog/post/ in the examples above. With clean urls, the following line should do just that:
    PHP Code:
    $root_dir str_replace ($_SERVER['DOCUMENT_ROOT'], ''realpath('.')); 
    Here's what's happening:
    PHP Code:
    '/clients/client' str_replace ('/var/www''''/var/www/clients/client'); 
    Thus, any url can be created like this:
    HTML Code:
    <a href="<?php echo $root_dir . '/blog/post/'; ?>">
    Because I don't want to do this with every url, I have the url generator that I mentioned earlier place $root_dir at the beginning of every url. So the above is simplified to:
    HTML Code:
    <a href="<?php echo $url->render('/blog/post/'); ?>">
    As long as the $url object is available, I can print out urls that will work in any directory, on any server.

    Note: It is imperative to not have an ending / at the end of the root dir. We started out doing it that way, and it caused a great deal of headache for us. However, the base tag DOES need an ending slash. If you have done this correctly, physical resources can be located using a relative url (because of the base tag) and clean url pages can be linked to using an absolute url (starting from wherever your bootstrap is contained).

    5. Anything else?

  2. #2
    SitePoint Wizard wheeler's Avatar
    Join Date
    Mar 2006
    Location
    Gold Coast, Australia
    Posts
    1,369
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    just a small note, and you may have overcome this anyway:

    I define a BASE_PATH in my application config, and build all paths as
    Code HTML4Strict:
    <a href="<?php echo BASE_PATH; ?>path/to/something
    . That allows me to work in any folder, and there are no anchor or relative url issues.
    Studiotime - Time Management for Web Developers
    to-do's, messages, invoicing, reporting - 30 day free trial!
    Thomas Multimedia Web Development

  3. #3
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    996
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    I work out where the script is running from and change the base tag accordingly.


    PHP Code:
    $siteURI explode('/'$_SERVER['SCRIPT_NAME']);
    array_pop($siteURI);
    $siteURI 'http://' $_SERVER['SERVER_NAME'] . implode('/'$siteURI) . '/'
    Then set <base href="<?php echo $siteURI; ?>" />

    The site can now be moved around without changing config files, and all my links look like <a href="controller/action/args">...</a>

  4. #4
    SitePoint Enthusiast
    Join Date
    Jul 2005
    Location
    Norway
    Posts
    88
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Everybody keeps talking about clean URL's, but I'm not so sure that their URL's really are clean.. I'll try to explain:

    First, what is an URL? It's a resource identifier. And it should say something about the resource. So, when people are making URL's like this (I have, too): www.site.com/articles/2009/05/11/some-title/, then aren't they saying that this resource is a folder? I think the extention should be .html or .php or whatever to reflect what kind of resource it is.

    If you think about it, this is the kind of convension that's used on other type of resources. For example, a document on a webpage would have a .doc, or a .rtf or something like that. An image would have .jpg or similar, and rss feed would have .rss. A javascript file would have .js and a css file would have .css. So why don't html files get an extension? Why should they look like folders?

    Of course, if you refer to a folder on a website, and it has an index file, you will be served that index file instead of the contents of that folder. But that index file should reflect the contents of that folder, right?

    Say you have a folder named /documents/. Then the index file in there should contain links to the documents below that folder, right?

    Or, if you have a folder named /articles, it should give you all articles, or all categories of articles. If you have folder /articles/some-category/, then it should provide access to articles in that category.. And the same goes for /articles/category/2009, which should reflect articles for 2009 in that category. But then you have /articles/category/2009/05/11/some-article/. That's not a category or a folder, its a specific resource, and I think it should be named accordingly. And besides, you might want to have /some-article.pdf or /some-article.doc or xml, to reflect different versions of that article.

    That's just some thoughts of mine on clean url's.. use it for whatever it's worth

  5. #5
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    996
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    I've never really thought about it like that before but you're 100% correct. I think for future projects my URIs will be ending .html instead of /

  6. #6
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    A directory is also a resource. I really do not see the point in putting an extension when extension-less is perfectly fine. Also there isn't a need for the end "/" to be there.
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  7. #7
    SitePoint Wizard silver trophybronze trophy Stormrider's Avatar
    Join Date
    Sep 2006
    Location
    Nottingham, UK
    Posts
    3,133
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by oeyvind View Post
    Everybody keeps talking about clean URL's, but I'm not so sure that their URL's really are clean.. I'll try to explain:

    First, what is an URL? It's a resource identifier. And it should say something about the resource. So, when people are making URL's like this (I have, too): www.site.com/articles/2009/05/11/some-title/, then aren't they saying that this resource is a folder? I think the extention should be .html or .php or whatever to reflect what kind of resource it is.

    If you think about it, this is the kind of convension that's used on other type of resources. For example, a document on a webpage would have a .doc, or a .rtf or something like that. An image would have .jpg or similar, and rss feed would have .rss. A javascript file would have .js and a css file would have .css. So why don't html files get an extension? Why should they look like folders?

    Of course, if you refer to a folder on a website, and it has an index file, you will be served that index file instead of the contents of that folder. But that index file should reflect the contents of that folder, right?

    Say you have a folder named /documents/. Then the index file in there should contain links to the documents below that folder, right?

    Or, if you have a folder named /articles, it should give you all articles, or all categories of articles. If you have folder /articles/some-category/, then it should provide access to articles in that category.. And the same goes for /articles/category/2009, which should reflect articles for 2009 in that category. But then you have /articles/category/2009/05/11/some-article/. That's not a category or a folder, its a specific resource, and I think it should be named accordingly. And besides, you might want to have /some-article.pdf or /some-article.doc or xml, to reflect different versions of that article.

    That's just some thoughts of mine on clean url's.. use it for whatever it's worth
    You are assuming that a file is the same thing as a resource though, and they aren't necessarily. I think it's perfectly fine to have a resource not have a standard file extension.

  8. #8
    SitePoint Wizard
    Join Date
    Apr 2007
    Posts
    1,401
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    I'm not sure if this have anything to do w/ this thread. But following along w/ clean URL is the RESTful Web Services. They use the clean URL naming convention to make the request. Also, they are very strict on access methods like "get, post, delete," and etc... To me this is when I thought clean URL made sense. For example, Ruby on Rails embrace RESTful architecture.

  9. #9
    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)
    Interesting thread; I have a couple of observations.

    I don't like the term "clean urls". It implies to replace query string parameters with path elements. I know it could mean other things, but this is usually what people make out of it. I'd rather speak of good urls and what makes up a good url.

    A url consists (among other things) of two parts: the path and the query string. They can both used to identify a resource, but they have slightly different semantics. It's generally accepted (I think it even says in the http specs), that the path should be the major category to identify a resource, and the querystring is secondary. This means that if you can construct your url in such a way that it doesn't contain querystring parameters, it's usually better that way. However - and there is a however - it's important to keep in mind what the meaning of the path is. Unlike the querystring, the path is hierarchical. This means that there is only one dimension to it; The querystring on the other hand, can have as many dimensions (keys) as you wish. This means that for arbitrary parameters, you should use the querystring. Trying to blindly cram multiple dimensions into the path is a mistake.

    On the concept of trailing slashes, I'd say that they are a mistake. The main reason why we see them a lot is that Apache (and probably other web servers) by default interprets the path element of a url as a relative filesystem path. This is a fairly meaningful metaphor, since it allows for a simple mapping from url -> file, but it breaks down if you use the web server for things other than serving files. That's why most application frameworks has its own mapping (routing) mechanism. I'm a bit ambivalent on what the best practise is here; In theory, I'd say that urls shouldn't end in slashes (They are separators), but in practise it's a bit of a hassle to reconfigure the web server to match that.

    File extensions are a funny subject. Even on the local file system, they are a bad way of identifying the content-type of a file. For example, how do you handle a file with the extension of .doc? In the case of web servers it gets even funnier, since the file extension is - per default - used to tell the server what to do with the file. Eg. a file ending in .php is interpreted by mod_php. This is completely backwards - The user shouldn't care about that information. This leaves the problem of how the user figures out what type the served content is, and this is where mime types (In particular the content-type header) comes in.

    So, file extensions shouldn't be used to tell the server how to handle content (that's an implementation detail) and it shouldn't be used to tell the user what to expect (they use the content-type header instead). Should we then conclude that file extensions should be abandoned? Well, again there is a clash between the default file-server mechanism of Apache and the needs of web applications. It's very convenient to use Apache for serving static files (images etc.) directly, so for these cases it's probably best to stick with it. It is also a slightly better case here, since the extension will usually match the content-type header sent back (unlike .php which will usually be text/html). For web applications I have found a different use for file extensions, that fits well with the file server dogma. If a resource exists in multiple variations (say, an html and a json variant), I'd use the file extension as a means to request a particular type. In theory this is what the Accept header is for, but since support is sketchy on the client side, I like to have a fallback that works.

  10. #10
    Grumpy Minimalist
    Join Date
    Jul 2006
    Location
    Ontario, Canada
    Posts
    424
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by oeyvind View Post
    I think the extention should be .html or .php or whatever to reflect what kind of resource it is.
    As Stormrider mentioned, you're assuming that a resource can only have one type.

    For example, my system provides a RESTful implementation wherein each URL specifies a resource, eg.
    Code:
    http://www.example.com/path/to/resource
    Chances are that this resource is available in multiple types. For example, if this was the resource representing a person, it might be available as a JSON object (with the person's data in the output), or displayed as HTML (with the same data displayed in a nice layout), or even as an image (such as a business card).

    When the resource is requested, the server uses the browser's Accept header to determine the best MIME type to return. This (generally) assures that the user receives the content in the type that is best for their context. As such, there is no file extension (since no type is "the" representation).

    However, a file extension can be added to the resource to force it into a specific type instead of using the Accept header. So requesting this resource:
    Code:
    http://www.example.com/path/to/resource.html
    ...would force the server to return the HTML representation, regardless of the browser preferences.

  11. #11
    SitePoint Addict ruby-lang's Avatar
    Join Date
    Aug 2007
    Posts
    389
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by allspiritseve View Post
    If a clean url was http://www.site.com/site/blog/post/ then a standard url would be http://www.site.com/index.php?route=/site/blog/post/ and then all I had to do was determine whether to use $_GET['route'] or $_SERVER['REQUEST_URI'].
    I think http://www.example.com/index.php/site/blog/post/ would also work, and look a bit cleaner.

    On the subject of extensions, the main advantage I see is in implementation. It makes knowing if a URL should go through you Front Controller a bit easier -- you just have to check the suffix. There is a secondary advantage: if you intend to provide your content in JSON or XML-based formats, you can use the extension to know what format to return. For example, if /site/blog.html returns your blog's main page, /site/blog.rss could return its RSS feed, and /site/blog/post.json could return a specific post in JSON format for widget consumption.

  12. #12
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by oeyvind View Post
    I think the extention should be .html or .php or whatever to reflect what kind of resource it is.
    One reason I've heard not to have extensions is for security-- if a hacker can't tell what kind of programming language you're using, it just makes it that much harder to hack.

    Another reason (and I learned this way back when I first read about clean urls on alistapart) is to keep backwards-compatible urls. Say you switch to ruby next year. Should you change all those .php files to .rb? That means anyone who ever linked to your .php files will not have a working link anymore. With clean urls, you are free to handle the implementation, and the burden is taken off the user and/or linker.

    Quote Originally Posted by Kyberfabrikken
    On the concept of trailing slashes, I'd say that they are a mistake. The main reason why we see them a lot is that Apache (and probably other web servers) by default interprets the path element of a url as a relative filesystem path. This is a fairly meaningful metaphor, since it allows for a simple mapping from url -> file, but it breaks down if you use the web server for things other than serving files. That's why most application frameworks has its own mapping (routing) mechanism. I'm a bit ambivalent on what the best practise is here; In theory, I'd say that urls shouldn't end in slashes (They are separators), but in practise it's a bit of a hassle to reconfigure the web server to match that.
    Interesting. I've always used them assuming the best practice was to use them.

  13. #13
    SitePoint Addict ruby-lang's Avatar
    Join Date
    Aug 2007
    Posts
    389
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by allspiritseve View Post
    Another reason (and I learned this way back when I first read about clean urls on alistapart) is to keep backwards-compatible urls. Say you switch to ruby next year. Should you change all those .php files to .rb? That means anyone who ever linked to your .php files will not have a working link anymore. With clean urls, you are free to handle the implementation, and the burden is taken off the user and/or linker.
    Quick anecdote: Orkut was originally built in Asp.Net. Since .Net is a non-standard stack for Google, it was subsequently recoded in Java, but in order not to break links and bookmarks, the .aspx extension was kept.

  14. #14
    SitePoint Wizard silver trophybronze trophy Cups's Avatar
    Join Date
    Oct 2006
    Location
    France, deep rural.
    Posts
    6,869
    Mentioned
    17 Post(s)
    Tagged
    1 Thread(s)
    I can't pass by without bringing CoolURIs for the Semantic web to your attention, mentions content negotiation, forking and other ways of handling user agent requests which might be relevant to you.

    Also a discussion on W3Cs Style CoolURIs don't change.

    Quick anecdote #2: I ran a cms for 4 years as asp, when I changed it to php I just changed one server setting and kept the same .asp urls.
    (I did feel like a bit of a traitor though)

  15. #15
    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 oeyvind View Post
    I think the extention should be .html or .php or whatever to reflect what kind of resource it is.
    The .php extension is problematic because you aren't serving back php-files;You're serving html files that just happen to be created with php. So I agree on most of what you said, but you need to distinguish between those two cases.

    Quote Originally Posted by allspiritseve View Post
    Interesting. I've always used them assuming the best practice was to use them.
    I suppose it depends. If I'm not mistaken, the Apache documentation explicitly states that it's their recommended practise to put a trailing slash. This is because the server - by default - will redirect all requests to the slashed version. They had to pick one approach and they went with that one.

    One more thing to keep in mind is that browsers will treat a document coming from foo/bar differently from one coming from foo/bar/. External files and links can be relative, and the browser will resolve them differently in the two cases.

  16. #16
    SitePoint Addict
    Join Date
    Jan 2007
    Posts
    344
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    If I'm not mistaken, the Apache documentation explicitly states that it's their recommended practise to put a trailing slash. This is because the server - by default - will redirect all requests to the slashed version. They had to pick one approach and they went with that one.
    Then that is an apache implementation problem. The trailing slash has a very specific meaning in the standards. It is the default resource at that folder. In practice, this means index.* or default.*, or whatever the configuration of the particular server dictates.

    It is more likely that apache redirerects to /foo/ if, and only if, /foo does not exist. This would be an attempt to recover from the non-existence of /foo as a courtesy redirect. If further, /foo/ does not exist, then the 404 handler comes into play.

    Finally, clean urls, aka seo'd urls are an abomination.

    Nothing wrong with /stop-this.html

    but,

    /hope/to/be/indexed/for-this-spammy-recycled-blog-post-in-a-desperate-attempt-to-monetize-the-site-because-all-the-web-is-my-money-pit-according-to-the-seo-experts-selling-snake-oil/

    is frickin' ridiculous.

    there is a reason tinyurl.com is doing well.

  17. #17
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by plumsauce View Post
    Finally, clean urls, aka seo'd urls are an abomination.

    Nothing wrong with /stop-this.html but,

    /hope/to/be/indexed/for-this-spammy-recycled-blog-post-in-a-desperate-attempt-to-monetize-the-site-because-all-the-web-is-my-money-pit-according-to-the-seo-experts-selling-snake-oil/

    is frickin' ridiculous.
    Oh, I'm sorry, would you prefer /blog.php?type=post&title=hope-to-be-indexed-for-this-spammy-recycled-blog-post-in-a-desperate-attempt-to-monetize-the-site-because-all-the-web-is-my-money-pit-according-to-the-seo-experts-selling-snake-oil

    Much improved.

    Maybe it's not the clean urls that are an "abomination", but rather excessively long titles?

  18. #18
    SitePoint Enthusiast
    Join Date
    Jul 2005
    Location
    Norway
    Posts
    88
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Some people have commented on my post about using extensions, so here follows some responses:

    About trailing slashes: I suppose it looks a little less like a folder if you leave out the trailing-slash. And perhaps even though the resource looks like a folder, it doesn't really give you any real problems, it's more of a preference kind of thing.

    About letting the browser determine the content-type, I think that's really cool. I haven't thought about it like that before, about how different devices or different browsers might want to see the same resource in diffrerent formats but without specifying the extension. I have never had the use for this feature, though, but I'll keep it mind for future projects.

    About not using a .php extension because one day you might want to switch to another technology... I think it depends on the application. If it's a CMS or something, I think that a redesign would not be done in exactly the same way anyway, and people don't really use direct links that much in back-end applications. As for a front-end website, yes, it's probably a good idea to not have a .php extension on URL's that you know won't change over the years. But you could have an .html extension.

    And then about security: I don't think it matters too much if you display the .php extension. There are other ways of finding the back-end language.. like checking the response headers of the webservers, which often includes the apache version and the php version, and you can do a whois search for the domain and go to the webhotel's website and check out which technologies they're offering. If you're on a private server, then you can probably hide it quite well.

  19. #19
    PHP/Rails Developer Czaries's Avatar
    Join Date
    May 2004
    Location
    Central USA
    Posts
    806
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by allspiritseve View Post
    Because I don't want to do this with every url, I have the url generator that I mentioned earlier place $root_dir at the beginning of every url. So the above is simplified to:
    HTML Code:
    <a href="<?php echo $url->render('/blog/post/'); ?>">
    As long as the $url object is available, I can print out urls that will work in any directory, on any server.
    You may want to consider changing that to a way to distunguish the different keys/values easier. Something like this:
    HTML Code:
    <a href="<?php echo $url->render(array('controller' => 'blog', 'action' => 'post')); ?>">
    Or the Symphony approach:
    HTML Code:
    <a href="<?php echo $url->render('controller=blog&action=post'); ?>">
    That way you are linking directly to what you want to in your application (the exact controller and action you want to execute) instead of a static URL path that could change at some point. It also lets anything extra in the array that doesn't match the route be appended to the end as a query string automatically.

  20. #20
    SitePoint Member
    Join Date
    Dec 2008
    Posts
    21
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I prefer to use a central routing script that interprets the query:

    http://example.com/?Article.show.11
    http://example.com/?Thread.show.22&page=3

    Code:
    <a href="?Article.show.11">link</a>
    It's fairly short, doesn't require htaccess files, doesn't interfere with relative links to real files, and allows you to use relative URLs without calling any functions in your template. You could use it to represent pseudo-hierarchical content as well:
    http://example.com/?article.2009.7.17

    As an added bonus, you could rename your main router file, and all those relative URLs would still work without any modification to the code. Hashes after the URL work without any problems too. For example, if you're on a page http://example.com/?article.show.1, you can link to an anchor on the current page simply by saying:
    Code:
    <a href="#anchor-name">link</a>
    This would lead you to http://example.com/?article.show.1#anchor-name .

    The "main" page could be linked to as href=".", of course.
    Caffeine Web Framework - reinventing the wheel since 2004.
    MicroWSS - simple SOAP web services server in Java.

  21. #21
    SitePoint Guru Chroniclemaster1's Avatar
    Join Date
    Jun 2007
    Location
    San Diego, CA
    Posts
    784
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    The .php extension is problematic because you aren't serving back php-files;You're serving html files that just happen to be created with php. So I agree on most of what you said, but you need to distinguish between those two cases.
    But isn't that true in every case? Every .php page is just XHTML, CSS, and Javascript. No browser in the world processes or even understands PHP or any other language, that's why they're server side.
    Whatever you can do or dream you can, begin it.
    Boldness has genius, power and magic in it. Begin it now.

    Chroniclemaster1, Founder of Earth Chronicle
    A Growing History of our Planet, by our Planet, for our Planet.

  22. #22
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Czaries View Post
    You may want to consider changing that to a way to distunguish the different keys/values easier. That way you are linking directly to what you want to in your application (the exact controller and action you want to execute) instead of a static URL path that could change at some point. It also lets anything extra in the array that doesn't match the route be appended to the end as a query string automatically.
    Are you suggesting some intermediate layer that translates the controller/action into a valid url based on routes? That seems kinda complicated. What's wrong with just using the url?

    Quote Originally Posted by Chroniclemaster1
    But isn't that true in every case? Every .php page is just XHTML, CSS, and Javascript. No browser in the world processes or even understands PHP or any other language, that's why they're server side.
    Hmmm... so maybe every page should be .html, if an extension is to be used?

  23. #23
    Web developer chrisranjana's Avatar
    Join Date
    Jan 2001
    Location
    chennai , tamil nadu , India
    Posts
    710
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Excessive long titles also should be considered "not clean" urls.
    Chris, Programmer/Developer,
    Laravel Php Developers, Ruby on Rails programmers,
    Moodle, Opencart, Magento, Geodesic Classifieds/Auctions,
    www.chrisranjana.com

  24. #24
    Guru in training bronze trophy SoulScratch's Avatar
    Join Date
    Apr 2006
    Location
    Maryland
    Posts
    1,838
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    File extensions pertaining to the language used by a web application is not necessary, it's a waste of typing and a user doesn't need to remember the web application's specific file extension. I believe in clean urls, as is the case with most modern MVC based frameworks.

    I honestly think any web application that relies on file extensions such as ".php" is outdated and needs to be updated to a better more elegant system.
    Cross browser css bugs

    Dan Schulz you will be missed

  25. #25
    SitePoint Zealot Luke Morton's Avatar
    Join Date
    Jul 2005
    Location
    Essex, England.
    Posts
    125
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by isroman View Post
    I prefer to use a central routing script that interprets the query:

    http://example.com/?Article.show.11
    http://example.com/?Thread.show.22&page=3

    Code:
    <a href="?Article.show.11">link</a>
    It's fairly short, doesn't require htaccess files, doesn't interfere with relative links to real files, and allows you to use relative URLs without calling any functions in your template. You could use it to represent pseudo-hierarchical content as well
    Is performance not impacted by using an interpretation script of your own compared to using .htaccess or httpd.conf to route scripts?
    Luke Morton
    UK Web Explorer| lukemorton.co.uk


Tags for this Thread

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
  •