Re: Clean URL Design: List Views and Details Views

2009-04-17 Thread birkin 

On Apr 16, 9:29 am, Aidas Bendoraitis 
wrote:

> ...and there should be either a black list of words for
>  like del.ici.ous and flickr.com does, or there
> should be another way to differentiate between slugs and
> controlling words...

This may be obvious, but in case it's not, options are extended by the
fact that urls.py allows one to easily create multiple patterns that
can address the same url segment, possibly making it easier to
maintain the 'black list of words'.

Knowing that the first pattern that matches will be used, you could
have:

(r'^products/product_(?P[^/]+)/$',
'the_app.views.productDetail' ),
(r'^products/sorted_by_(?P[^/]+)/$',
'the_app.views.productList' ),
(r'^products/ten_most_popular_products/$',
'the_app.views.topProducts' ),
(r'^products/$', redirect_to, {'url': '/your_store/products/
sorted_by_price/'} ),

...here the first three address the same url segment. This method
would also allow you to get some characters into the url segment not
permitted by the built-in slug code.

-Birkin
---

On Apr 16, 9:29 am, Aidas Bendoraitis 
wrote:
> Hello,
>
> Recently, we are solving a conceptual question of designing clean urls
> for list and detail views of objects with slugs.
>
> Let's say we have products with their slugs. In the naive way, the
> list view could be accessed by
>     /products/
> and the detail views could be accessed by
>     /products/myproduct/
> where "myproduct" is a slug of a product.
>
> Problems appear when you want to filter or sort list of products by
> different parameters, have a possibility to add another product, or
> have pagination. In those cases
>     /products/by-popularity/
>     /products/featured/
>     /products/page5/
>     /products/add/
> etc.
> would clash with
>     /products//
> and there should be either a black list of words for 
> like del.ici.ous and flickr.com does, or there should be another way
> to differentiate between slugs and controlling words. In my opinion,
> the black-list approach is very limited and doesn't make your website
> extensible. So let's see what other options are.
>
> 1. One of the approaches is to use special symbols for the controlling
> words, which are not allowed in slugs, like in last.fm or wikipedia
> does. So the list urls might look like this:
>     /products/sort-by:popularity/
>     /products/filter-by:featured/
>     /products/page:5/
>     /products/action:add/
>     /products/myproduct/
>     /products/myanotherproduct/
> or
>     /products/+by-popularity/
>     /products/+featured/
>     /products/+page5/
>     /products/+add/
>     /products/myproduct/
>     /products/myanotherproduct/
>
> 2. Another way is to use a special symbol like a dot together with the
> primary key as a part of the url for product-details page, i.e.:
>     /products/by-popularity/
>     /products/featured/
>     /products/page5/
>     /products/add/
>     /products/123.myproduct/
>     /products/456.myanotherproduct/
> or
>     /products/by-popularity/
>     /products/featured/
>     /products/page5/
>     /products/add/
>     /products/myproduct.123/
>     /products/myanotherproduct.456/
>
> 3. Using a prefix for product details:
>     /products/by-popularity/
>     /products/featured/
>     /products/page5/
>     /products/add/
>     /products/prod_myproduct/
>     /products/prod_myanotherproduct/
>     /products/prod_featured/
>
> 4. Using a separate namespace for product details:
>     /products/by-popularity/
>     /products/featured/
>     /products/page5/
>     /products/add/
>     /products/product/myproduct/
>     /products/product/myanotherproduct/
> or
>     /products/by-popularity/
>     /products/featured/
>     /products/page5/
>     /products/add/
>     /products/details/myproduct/
>     /products/details/myanotherproduct/
> or
>     /products/by-popularity/
>     /products/featured/
>     /products/page5/
>     /products/add/
>     /products/unit/myproduct/
>     /products/unit/myanotherproduct/
>
> 5. Using upper case for controlling words:
>     /products/BY-POPULARITY/
>     /products/FEATURED/
>     /products/PAGE5/
>     /products/ADD/
>     /products/myproduct/
>     /products/myanotherproduct/
>
> 6. Using plural for managing lists and using singular for managing
> details:
>     /products/by-popularity/
>     /products/featured/
>     /products/page5/
>     /products/add/
>     /product/myproduct/
>     /product/myanotherproduct/
>
> 7. Using the controlling words before the type of list:
>     /by-popularity/products/
>     /featured/products/
>     /page5/products/
>     /add/products/
>     /products/myproduct/
>     /products/myanotherproduct/
>
> What approaches do/would you use and why? What would be best for a
> future-proof website? Are there any valuable resources about URL
> design?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.

Re: Clean URL Design: List Views and Details Views

2009-04-17 Thread Col Wilson 

/products/by-popularity/
/products/featured/
/products/page/5/
/products/add/
/products/elvis/
/product/in-the-ghetto/
/product/jail-house-rock/
/product/love-me-tender/

On Apr 16, 2:29 pm, Aidas Bendoraitis 
wrote:
> Hello,
>
> Recently, we are solving a conceptual question of designing clean urls
> for list and detail views of objects with slugs.
>
> Let's say we have products with their slugs. In the naive way, the
> list view could be accessed by
>     /products/
> and the detail views could be accessed by
>     /products/myproduct/
> where "myproduct" is a slug of a product.
>
> Problems appear when you want to filter or sort list of products by
> different parameters, have a possibility to add another product, or
> have pagination. In those cases
>     /products/by-popularity/
>     /products/featured/
>     /products/page5/
>     /products/add/
> etc.
> would clash with
>     /products//
> and there should be either a black list of words for 
> like del.ici.ous and flickr.com does, or there should be another way
> to differentiate between slugs and controlling words. In my opinion,
> the black-list approach is very limited and doesn't make your website
> extensible. So let's see what other options are.
>
> 1. One of the approaches is to use special symbols for the controlling
> words, which are not allowed in slugs, like in last.fm or wikipedia
> does. So the list urls might look like this:
>     /products/sort-by:popularity/
>     /products/filter-by:featured/
>     /products/page:5/
>     /products/action:add/
>     /products/myproduct/
>     /products/myanotherproduct/
> or
>     /products/+by-popularity/
>     /products/+featured/
>     /products/+page5/
>     /products/+add/
>     /products/myproduct/
>     /products/myanotherproduct/
>
> 2. Another way is to use a special symbol like a dot together with the
> primary key as a part of the url for product-details page, i.e.:
>     /products/by-popularity/
>     /products/featured/
>     /products/page5/
>     /products/add/
>     /products/123.myproduct/
>     /products/456.myanotherproduct/
> or
>     /products/by-popularity/
>     /products/featured/
>     /products/page5/
>     /products/add/
>     /products/myproduct.123/
>     /products/myanotherproduct.456/
>
> 3. Using a prefix for product details:
>     /products/by-popularity/
>     /products/featured/
>     /products/page5/
>     /products/add/
>     /products/prod_myproduct/
>     /products/prod_myanotherproduct/
>     /products/prod_featured/
>
> 4. Using a separate namespace for product details:
>     /products/by-popularity/
>     /products/featured/
>     /products/page5/
>     /products/add/
>     /products/product/myproduct/
>     /products/product/myanotherproduct/
> or
>     /products/by-popularity/
>     /products/featured/
>     /products/page5/
>     /products/add/
>     /products/details/myproduct/
>     /products/details/myanotherproduct/
> or
>     /products/by-popularity/
>     /products/featured/
>     /products/page5/
>     /products/add/
>     /products/unit/myproduct/
>     /products/unit/myanotherproduct/
>
> 5. Using upper case for controlling words:
>     /products/BY-POPULARITY/
>     /products/FEATURED/
>     /products/PAGE5/
>     /products/ADD/
>     /products/myproduct/
>     /products/myanotherproduct/
>
> 6. Using plural for managing lists and using singular for managing
> details:
>     /products/by-popularity/
>     /products/featured/
>     /products/page5/
>     /products/add/
>     /product/myproduct/
>     /product/myanotherproduct/
>
> 7. Using the controlling words before the type of list:
>     /by-popularity/products/
>     /featured/products/
>     /page5/products/
>     /add/products/
>     /products/myproduct/
>     /products/myanotherproduct/
>
> What approaches do/would you use and why? What would be best for a
> future-proof website? Are there any valuable resources about URL
> design?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Clean URL Design: List Views and Details Views

2009-04-17 Thread Philipp Bosch 

I agree on that it's not a good ideo to have actions in GET
parameters. For things like sorting, pagination and the like it's
propably a good idea because you are only changing the view on the
same data. But "add" is a completely new thing. In HTTP terms it
should propably be a PUT request to /products/, but that is currently
not possible with browsers.

I would also say that Aidas' option #6 is not the way to go because
having two separate trees (/products/ and /product/) would lead to
confusion. And it would be against the goal of decoupling of django
apps because you would have to put at least two lines in your root
URLconf when you should propably try to delegate the whole URL
handling to the URLconf of the app itself, like

  (r'^products/(.*)$', include('products.urls')),

I did some research and found the following quotes related to that
topic:

"Use a 'gradual unfolding methodology' for exposing data to clients."
– http://www.xfront.com/tsld060.htm

"You'll know you've got a good URI design when it's easy to extend
hierarchies by tacking on additional path variables." – Richardson/
Ruby – RESTful Web Services, p118

I think there is no perfect solution to that problem you are dealing
with. I have used the /products/myproduct.123/ approach in the past
and it worked fine for me. So I would either go for that one or for
the prefix approach (/products/+add/) but probably with another prefix
as last.fm. Maybe an underscore _ but I'm not sure. Both are not
beautiful but not completely ugly as well.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Clean URL Design: List Views and Details Views

2009-04-16 Thread Aidas Bendoraitis [aka Archatas] 

> /products/?action=add
> /products/?action=print
> /products/?action=rss
> /products/myproduct/?action=rss
> /products/myproduct/?action=print
>
Those are examples of ugly (not clean anymore) urls.

In such a case, you would need to have a wrapper view in Django, which
would return the results of specific views depending on the passed
"action" parameter. That's not a nice way as you can't use the default
urls.py for defining the views like "add_product", "export_pdf", etc.
there in the default Django way.

Aidas
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Clean URL Design: List Views and Details Views

2009-04-16 Thread Marcin Mierzejewski 

Hi Archatas,

On Apr 16, 4:07 pm, "Aidas Bendoraitis [aka Archatas]"
 wrote:
> > 8. Using parameters
> >      /products/?sort=popularity
> >      /products/?filter=featured
> >      /products/?page=5
> >      /products/add/
> >      /products/myproduct/
> >      /products/myanotherproduct/
> In this case, you still need to have a black list of words like "add",
> "export", "print", "rss", "send-to-friend" or any other. So this is
> not the best way to go.

/products/?action=add
/products/?action=print
/products/?action=rss
/products/myproduct/?action=rss
/products/myproduct/?action=print

Best regards,
Macin

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Clean URL Design: List Views and Details Views

2009-04-16 Thread Aidas Bendoraitis [aka Archatas] 

> 8. Using parameters
>      /products/?sort=popularity
>      /products/?filter=featured
>      /products/?page=5
>      /products/add/
>      /products/myproduct/
>      /products/myanotherproduct/

In this case, you still need to have a black list of words like "add",
"export", "print", "rss", "send-to-friend" or any other. So this is
not the best way to go.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Clean URL Design: List Views and Details Views

2009-04-16 Thread Aidas Bendoraitis [aka Archatas] 

Here are the advantages and disadvantages I see myself:

> 1. One of the approaches is to use special symbols for the controlling
> words, which are not allowed in slugs, like in last.fm or wikipedia
> does.
(+) url rules for the app might be defined in a separate file
(+) shortness
(-) unusual/unnatural

> 2. Another way is to use a special symbol like a dot together with the
> primary key as a part of the url for product-details page
(+) url rules for the app might be defined in a separate file
(-) IDs shouldn't be shown to people (technologies should serve real
live but not vice versa).

> 3. Using a prefix for product details
(+) url rules for the app might be defined in a separate file
(+) shortness
(-) unnecessary not humanized wording

> 4. Using a separate namespace for product details
(+) url rules for the app might be defined in a separate file
(+) clean naturally-looking separation
(-) URL is long
(-) where would /products/product/ lead?

> 5. Using upper case for controlling words
(+) url rules for the app might be defined in a separate file
(-) weird and shouting too much

> 6. Using plural for managing lists and using singular for managing
> details
(+) url rules for the app might be defined in a separate file
(+) naturally conceived
(+) shortness
(-) where would /product/ lead?
(-) requires two files for url rules if the urls are defined in each
app
mentioned in: http://www.xml.com/pub/a/2005/04/06/restful.html

> 7. Using the controlling words before the type of list:
(-) some urls look realy weird
(-) can't be used in the app level

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Clean URL Design: List Views and Details Views

2009-04-16 Thread Andrew Ingram 

Ok, best practices time.

Segments:
Only introduces a new segment if it indicates a page that is a logical
descendant of the previous, traversing a category hierarchy would be
the typical example

/books/thrillers/

Query Parameters:
Used to define the viewing parameters of the current level in the
hierarchy, you'd use this for sorting, pagination and arguably
filters.

/books/thrillers?page=2=a-z=discontinued

It might not look pretty, but this is the way URL syntax works, now
you could arguably have 'discontinued' as another url segment but once
you start down that line of thought you end up with some fairly deep
url structures that could logically be in any order (creating a huge
number of possible combinations)

I typically overload a single level in the hierarchy with multiple
functions by using different slug formats to differentiate between
different view functions. You end up with some limitations but you
keep fairly short and logical URLs.

Regards,
Andrew Ingram


2009/4/16 Marcin Mierzejewski :
>
> Hi Aidas,
>
>> 7. Using the controlling words before the type of list:
>>     /by-popularity/products/
>>     /featured/products/
>>     /page5/products/
>>     /add/products/
>>     /products/myproduct/
>>     /products/myanotherproduct/
>
> 8. Using parameters
>     /products/?sort=popularity
>     /products/?filter=featured
>     /products/?page=5
>     /products/add/
>     /products/myproduct/
>     /products/myanotherproduct/
>
> Best regards,
> Marcin
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Clean URL Design: List Views and Details Views

2009-04-16 Thread Marcin Mierzejewski 

Hi Aidas,

> 7. Using the controlling words before the type of list:
>     /by-popularity/products/
>     /featured/products/
>     /page5/products/
>     /add/products/
>     /products/myproduct/
>     /products/myanotherproduct/

8. Using parameters
 /products/?sort=popularity
 /products/?filter=featured
 /products/?page=5
 /products/add/
 /products/myproduct/
 /products/myanotherproduct/

Best regards,
Marcin
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---