I am currently working on some experimental Pretty URL's code which I'm hoping to integrate into the next major release of Etomite and wanted to open a discussion about them here... Feel free to chime in and ask questions or provide ideas... Before doing so, however, please make sure you understand the difference between Friendly URL's, Friendly Aliases, and Pretty URL's... I'll try to explain the different variations of Pretty URL's here but won't be covering Friendly URL's or Friendly Aliases in this initial post...
Now, before I go much further I think I should state my stance on Pretty URL's... I don't believe that they make any difference as far as SEO is concerned and my view is shared by many, including some SEO experts... The simple fact is that URL's are not used by modern search engines as weight for their ranking algorithms... Content is king as far as search engines are concerned... In fact, few search engines even pay attention to the keyword or description meta tags, or any meta tags for that matter... The biggest thing that can cause ranking issues is piss poor markup validation in my personal opinion... Aside from that it's all about the content... I've been known to tell more than one client "We can't put enough lipstick on that pig to improve search engine ranking!" due to the shoddy work done by a previous developer (or 17 year old kid down the block)...
Pretty URL's are being used in several different variants currently... First there is {url}/virtual/path/to/current/page which serves as breadcrumbs traversing the internal document tree with the first part after {url} being the parent folder nearest the root of the document tree and /page being the alias of the document rendered... Then there is {url}/shop/books/php/123 which might mean &action=shop&category=books&subcategory=php&itemnum=123 and a logic structure needs to be used in order to decipher the parts of the URL into useful data... Yet another method is {url}/action/shop/category/books/subcategory/php/itemnum/123 where the components after {url} are actually $key=>$value pairs... It should be noted that {url} could contain a script name like index.php or a FURL like shop.html or a document alias like /shop/... As you can see, it can get pretty complicated depending on the intended use... Now, for a simple Blog script only one of these simpler methods would be used, like the first example, because virtually all visitor side request would be geared towards reading existing blog entries... The trickier methods come into play when running a more complex web application which might make use of multiple modules or for the everyday runnig of Etomite...
So, now that I've totally confused everyone, let me explain how I have envisioned usage as it pertains to Etomite... It is my goal to be able to use any of the methods mentioned without the use of mod_rewrite for ease of implementation... This also means that Windows servers will be able to use the implementation without ISAPI or other software or configurations... Simply set how you want Etomite to handle Pretty URL's and away you go...
Of course there will be questions like whether or not this will cause resource paths to break... The answer to that question is "No"... And then there is the question of whether internal links will be automagically converted to Pretty URL's to which the answer is "perhaps" or "optionally"...
Many MVC's use one of the methods listed... Code Igniter, Zend Framework, and several others expect the controller to sort out what the pieces are to be used for based on their order of appearance... Unfortunately, this is not always the best course of action... For example, CI pretty much writes off any notion of using $_GET - a concept that I find absurd... Therefore, in my implementation I am allowing $_GET to be constructed on the fly as the URL is parsed, depending on the method used... By that I mean that you will optionally be able to access parts of the URL using either $_GET[0|1|2] or $_GET[$key]=>$value... I am not aware of ANY software available today that gives this level of diversity... I've also taken the idea of optionally overwriting existing $_GET[$key] values if they already exist due to a mixed method configuration... I'd much rather have this option than to simply say that $_GET cannot be used...
Anyway, this is something I'm working on... It's a deep concept so keep in mind the fact that I may not have fully explained all of the many facets of it here... Granted, if you aren't using Etomite to do some heavy development then is is more or less a non-issue... However, for those of us who try to wring out every bit of power we can muster from within Etomite, this may be one feature that helps make Etomite shine... Also keep in mind that I'm looking at not turning Etomite into a complex directory based MVC but, rather, an internally based MVC platform... I'll try to make some example code available in the near future...
Your comments and questions are welcomed...
Pretty URL's
Started by
Ralph
, Jul 14 2009 06:21 PM
3 replies to this topic
#1
Posted 14 July 2009 - 06:21 PM
#2
Posted 14 July 2009 - 11:40 PM
I guess this akin to what I do with the urls for image pages on most of my gallery sites.
For each gallery (subject, media, or artist depending on the site) I have one page inside etomite that 'holds' the images and displays them all as an overview, and then another page that displays any one of the images, based on a parameter. At the time I put this together, google said it didn't fully take note of parameters to html pages, and so sites that relied on parameters to present different pages wouldn't be properly crawled (this was at least one of the reasons for friendly URLs in the first place!). As a result for these image pages I create a URL that embeds the parameter into the main part of the url:
eg http://www.mikefinle...and Stream.html goes to the page with alias 'monochrome-landscape-images', the image to be shown is image number 76, and the image title is 'Woodland Stream' (space converted to '+'). I don't use mod-rewrite directly (the hosting company sensibly doesn't give me that level of access (I think), but use the .htaccess rewrite rules to convert it back to the format that etomite accepts with an additional parameter for the image that the snippet then picks up and uses to select an image.
oops ... the full url parts are is http://www.mikefinley.co.uk/ monochrome-landscape-images__p76__Woodland+Stream.html without the space after the site - this forum seems to think the words are too long!
For each gallery (subject, media, or artist depending on the site) I have one page inside etomite that 'holds' the images and displays them all as an overview, and then another page that displays any one of the images, based on a parameter. At the time I put this together, google said it didn't fully take note of parameters to html pages, and so sites that relied on parameters to present different pages wouldn't be properly crawled (this was at least one of the reasons for friendly URLs in the first place!). As a result for these image pages I create a URL that embeds the parameter into the main part of the url:
eg http://www.mikefinle...and Stream.html goes to the page with alias 'monochrome-landscape-images', the image to be shown is image number 76, and the image title is 'Woodland Stream' (space converted to '+'). I don't use mod-rewrite directly (the hosting company sensibly doesn't give me that level of access (I think), but use the .htaccess rewrite rules to convert it back to the format that etomite accepts with an additional parameter for the image that the snippet then picks up and uses to select an image.
oops ... the full url parts are is http://www.mikefinley.co.uk/ monochrome-landscape-images__p76__Woodland+Stream.html without the space after the site - this forum seems to think the words are too long!
Edited by mikef, 14 July 2009 - 11:43 PM.
#3
Posted 15 July 2009 - 01:13 PM
Correction
Just wanted to let folks know that Code Igniter does have several URI handler features similar to those I have been or will be working on... I dug through their API last night and found several methods within classes that provide some of the functionality but not all... The more I look through that code the more I dislike it due to code overload... Somebody in that camp has been method happy to the extreme... Instead of using one method (function) more than one way they force you to remember a handful of similar functions and their usage criteria... That just doesn't fit with my coding mindset at all... Almost looks like someone there once worked at Microsoft and was used to insuring job security...
Just wanted to let folks know that Code Igniter does have several URI handler features similar to those I have been or will be working on... I dug through their API last night and found several methods within classes that provide some of the functionality but not all... The more I look through that code the more I dislike it due to code overload... Somebody in that camp has been method happy to the extreme... Instead of using one method (function) more than one way they force you to remember a handful of similar functions and their usage criteria... That just doesn't fit with my coding mindset at all... Almost looks like someone there once worked at Microsoft and was used to insuring job security...
#4
Posted 18 July 2009 - 09:58 AM
I like the concept of pretty URL's but is scares me regarding the impact this will have on development. I applaude the cross-platform implamantation and usage (and non-reliance on .htacess). My biggest concern is to what level of implementation it can be switched on at i.e. how many levels deep? and according to what pats of the site (sub diretories excluded)? and where in the site (is a shopping cart excluded)? I love the idea but the number of additional configuration settings that can be added to allow for backward compatability with old code and 3rd party integration may cause more headaches than it is worth. When you look at the number of variables that may need to be catered to (levels, areas, keys=->values, areas or levels, exceptions etc) there is literally an unlimited number of options that will need to be catered for to make it configured for all specific installations. Maybe just on or off may suffice for new installations??? Love the idea, the implementation scares me.
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users











