Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I started working in a department that uses a CMS in which the entire "filesystem" is like this:

  1. create a named file or folder - this file is given a unique node (ex. 2345) as well as a default "filename" (ex. /WelcomeToOurProductsPage) and apply a template
  2. assign one or more aliases to the file for a URL redirect (ex. /home-page-products - can also be accessed by /home-page-products.aspx)
  3. A new Rewrite command is written on the .htaccess file for each and every alias
  4. Server accesses either /WelcomeToOurProductsPage or /home-page-products and redirects to something like /template.aspx?tmp=2&node=2345 (here I'm guessing what it does - I only have front-end access for now - but I have enough clues to strongly assume)
  5. Node 2345 grabs content stored in a SQL Db and applies it to the template.

Note: There are no actual files being created on the filesystem. It's entirely virtual. This is probably a very common thing, but since I have never run across this kind of system before two months ago, I wanted to explain it in case it isn't common. I'm not a fan at all of ASP or closed-sourced systems, so it may be that this is common practice for ASP developers.

My question, that has taken far too long to ask, is: what are the benefits of this kind of system, as opposed to creating an actual file hierarchy? Are there any drawbacks to having every single file server call redirected? To having the .htaccess file hold rewrite rules for every single alias?

share|improve this question
    
My reason for asking is I have been daydreaming about creating a proprietary CMS and wondered if this type of "file" organization is a good idea. Ideally I'd like to create an AJAX-based system that uses hashchange and JSON/XML instead of server queries. –  philtune Jun 30 '12 at 13:22
    
What you want to use is WebDAV which is for all practical purposes the ultimate RESTful interface. –  Jarrod Roberson Jun 30 '12 at 13:40
1  
The fact that an URL is not based on the file system is pretty common, many CMS (and other systems) do it that way. However one-rewrite-rule-per-page (-and-alias) seems like an awful implementation of that system. –  Joachim Sauer Nov 15 '12 at 13:15
    
a more typical way of doing this is to keep the 'slug' in the database (the page name, 'home-page-products') and use a single rewrite rule to transform '/home-page-products' into 'something.aspx?page=home-page-products'. If you need multiple aliases, you can track those in an alias table, along with the 'id'. –  GrandmasterB Nov 15 '12 at 16:19
add comment

2 Answers

  1. The rewrite-rule-per-alias thing must be awful to manage. You could help somewhat by writing a script that took a spreadsheet or text file or whatever and turned it into a list of rewrite rules.
  2. Filesystems are the bread and butter of an operating system, and so they have been optimized like hell and thus they are fast. There are corner cases, usually related to storing massive numbers of files in single directories, but these can be mitigated too. And you know about symbolic links right?
  3. Could you write an ASP script that does all the rewriting?
share|improve this answer
add comment

Making all your linked pages a redirect is pretty horrible for SEO purposes -- the search engines will just see the somepage.aspx?node=1234 not your "pretty" urls. Rewriting the url behind the scenes is still ugly but a bit better.

You should really take a look at URL routing here -- that is going to do you alot better than dynamic url rewrites. The biggest downside there is that, without alot of voodoo, you are looking at a full app domain bounce anytime you add a page and that is after you get through the mechanical issues of mapping configuration values (the rewrites) to database values.

With URL routing you can setup a route like /{pageName} which will stuff that /home-page-products into the pageName variable. You then have an indexed list of pageNames that are mapped to the actual content. The Url itself never changes or is even rewritten on the back-side and it lets you swap out pages easily. You can even have multiple /{pageName} options go to the same page.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.