views:

40

answers:

3

Stackoverflowers,

I am debating between 2 scenarios for handling the display of a product catalog for a website redesign I am performing. I will be using the IIRF isapi filter to perform the rewriting for an asp.net website.

Here is what the urls will look like

www.domain.com/catalog/productgroup1
www.domain.com/catalog/productgroup2
www.domain.com/catalog/productgroup3
etc...

There will be a total of 8 or 9 product group pages

Scenario 1: I have these pages rewrite to one general purpose page that will look something like this:

www.domain.com/catalog.aspx?group={productgroup}

Then I decide which catalog to display with a switch/case based on the querystring. All of the code for displaying the catalogs would be based off of one page.


Scenario 2: I create a separate page for processing each different catalog page. The rewriting would look something like this then:

www.domain.com/catalog/productgroup1 --> www.domain.com/productgroup1.aspx

Then each catalog page would have it's own .aspx to handle the processing and display of that group of items.


I am leaning towards scenario 2 because it would allow me to be more customized for that particular product group, but it would lead to more individual pages to maintain for updates. Scenario 1 is currently how we handle displaying the product groups on the website, so we are familiar with that method, but the code does get a little hairy in places.

What would be the generally accepted best practice for handling this situation and in your experience, what are the advantages/drawbacks of each?

+1  A: 

Use the general purpose page. (Scenario1)

It is definitely a more extensible solution.

You can store customization in the database, and use that to drive various elements on the page, to emulate Scenario2.

John Gietzen
One thing I just thought of, wouldn't having individual pages process faster due to not having to hide/show various elements on a page based on the product group? For individual pages, nothing has to be decided and I can get straight to getting the product information and putting it on the screen. Something worth thinking about or not?
NinjaBomb
Server-side logic is probably not going to be your performance bottleneck (it's usually client or db in my experience).
Chris Pebble
I concur with @Chris here.
John Gietzen
+1  A: 

Do a combination of the two scenarios. Use URL Rewriting to have URL's that map to a generalized catalog page like in Scenario 1. The reason for this is to promote products within a search engine results. Since items in the querystring are generally not accounted for in search indexes, you would have a general catalog page be indexed but not the products themselves.

Agent_9191
At this moment, we do have our individual pages and the catalog pages they came from indexed (pretty well too, if I don't say so myself). My goal is to eliminate almost all of the querystrings we have now and get things a lot cleaner and create even better SEO for the site.
NinjaBomb
A: 

Yeah, the first scenario is the best one. With that, {productgroup} can be a reference to the product group and then you're are more flexible. The code will just take the product group id, fetch the products of this group from database and display or do whatever it wants with them.

The second method is too manual: you have to configure a new url each time you have a new product group.

Hope this helps you take a decision and go ahead!

Pattchen