Re: URL design

[Luis Zárate]

I can test this right now but based in my experience in re I think could be
like this

url(r'^(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P([a-zA-Z0-9_\-]+)/){7})$',
views.item_list)

Be worry with / in views

El viernes, 3 de junio de 2016, Горобец Дмитрий 
escribió:
> Hello, guys.
> I have the following URL patterns in my urls.py module and I'd like to
refactor them:
>
>
url(r'^(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/$',
views.item_list, name="item_location_category"),
>
url(r'^(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/$',
views.item_list),
>
url(r'^(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/$',
views.item_list),
>
url(r'^(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/$',
views.item_list),
>
url(r'^(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/$',
views.item_list),
>
url(r'^(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/$',
views.item_list),
>
url(r'^(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/$',
views.item_list),
>
url(r'^(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/$',
views.item_list),
>
url(r'^(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/$',
views.item_list)
>
> Example:
>
> http://mysite.com/london/cars/
>
> http://mysite.com/london/cars/new/
>
> http://mysite.com/london/cars/new/audi/
>
> http://mysite.com/london/cars/new/audi/a4/
>
> http://mysite.com/london/cars/new/audi/a4/2016/
>
> http://mysite.com/london/cars/new/audi/a4/2016/white/ etc...
>
> And it shouldn't be query parameter.
>
> Does anyone have any suggestions?
>
> Thank you.
>
> --
> You received this message because you are subscribed to the Google Groups
"Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/123e209e-3921-4399-affc-be8b4c67c6d9%40googlegroups.com
.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
"La utopía sirve para caminar" Fernando Birri

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAG%2B5VyNpneVSXBhz3FN%3DmmuOL%2Bcoe6Z4s0p-kh4B1B0M1P_B6w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

URL design

[Горобец Дмитрий]

Hello, guys.

I have the following URL patterns in my urls.py module and I'd like to 
refactor them:

url(r'^(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/$',
 views.item_list, name="item_location_category"),
url(r'^(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/$',
 views.item_list),
url(r'^(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/$',
 views.item_list),
url(r'^(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/$',
 views.item_list),
url(r'^(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/$',
 views.item_list),
url(r'^(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/$',
 views.item_list),
url(r'^(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/$',
 views.item_list),
url(r'^(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/$',
 views.item_list),
url(r'^(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/(?P[a-zA-Z0-9_\-]+)/$',
 views.item_list)


Example:

http://mysite.com/london/cars/

http://mysite.com/london/cars/new/

http://mysite.com/london/cars/new/audi/

http://mysite.com/london/cars/new/audi/a4/

http://mysite.com/london/cars/new/audi/a4/2016/

http://mysite.com/london/cars/new/audi/a4/2016/white/ etc...


And it shouldn't be query parameter.


Does anyone have any suggestions?


Thank you.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/123e209e-3921-4399-affc-be8b4c67c6d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: URL design - why the trailing slash?

[kRON]

Nope, no caveat there. You'r perfectly free to design your own URLs as
you like.

Ultimately, means you can also have a conflicting situation where you
decide you don't want to have a trailing `/` but you include URLs from
a 3p django application that do.

On Jan 28, 1:54 am, Brett Thomas  wrote:
> Most of the URLConf examples I run across use a trailing slash on all 
> URLs:www.example.com/profile/
>
> I'm not sure why, but I don't like this. I think it looks nicer 
> without:www.example.com/profile
>
> Are there any performance or security reasons to use the trailing slash in
> Django? Seems like there could be some quirk with regular expressions that
> I'm not thinking of...
>
> Thanks --
> Brett

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: URL design - why the trailing slash?

[FxFocus]

On Jan 28, 12:54 am, Brett Thomas  wrote:
> Most of the URLConf examples I run across use a trailing slash on all 
> URLs:www.example.com/profile/
>
> I'm not sure why, but I don't like this. I think it looks nicer 
> without:www.example.com/profile
>
> Are there any performance or security reasons to use the trailing slash in
> Django? Seems like there could be some quirk with regular expressions that
> I'm not thinking of...
>
> Thanks --
> Brett

You may find the *Common Middleware* documentation of interest in this
regard...

http://docs.djangoproject.com/en/dev/ref/middleware/#module-django.middleware.common

regards,
Ed

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: URL design - why the trailing slash?

[Graham Dumpleton]

On Jan 28, 11:54 am, Brett Thomas  wrote:
> Most of the URLConf examples I run across use a trailing slash on all 
> URLs:www.example.com/profile/
>
> I'm not sure why, but I don't like this. I think it looks nicer 
> without:www.example.com/profile
>
> Are there any performance or security reasons to use the trailing slash in
> Django? Seems like there could be some quirk with regular expressions that
> I'm not thinking of...

If you don't have a trailing slash for something which is an internal
node, ie., can have child pages, and you use a relative URL rather
than absolute URL, then the relative URL will be resolved incorrectly
by the browser.

For example, if at '/some/path/' and returned HTML uses 'child.html',
then browser will resolve it as:

  /some/path/child.html

if accessed as '/some/path' and returned HTML uses 'child,html', then
browser will resolve it as:

  /some/child.html

which isn't want you want.

So, you use trailing slash if you want relative URLs in responses.

Either way, you should use one of the other and not allow both at the
same time. That is '/some/path/' and '/some/path' should not both
work. If you do allow both, then search engines will have multiple
entries for same resource. Also may stuff up caching systems or at
least reduce their efficiency as will keep multiple copies.

Graham

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: URL design - why the trailing slash?

[Eugene Wee]

Hi,

On Thu, Jan 28, 2010 at 8:54 AM, Brett Thomas  wrote:
> Most of the URLConf examples I run across use a trailing slash on all URLs:
> www.example.com/profile/
>
> I'm not sure why, but I don't like this. I think it looks nicer without:
> www.example.com/profile

I believe that it is just a matter of personal preference: some people
like to always have a slash appended (or never appended) for
consistency. I prefer to append a slash when the page is some kind of
category, but leave it out when it is a "leaf node". (I noticed that
this is what the W3C website does.)

> Are there any performance or security reasons to use the trailing slash in
> Django? Seems like there could be some quirk with regular expressions that
> I'm not thinking of...

I do not know about performance, but I doubt there is a security
issue, otherwise it would not have made sense to make the APPEND_SLASH
setting behave the way it does, i.e., a slash is not appended if the
initial URL (without a trailing slash) can be found in the URLconf.

Regards,
Eugene Wee

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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.

URL design - why the trailing slash?

[Brett Thomas]

Most of the URLConf examples I run across use a trailing slash on all URLs:
www.example.com/profile/

I'm not sure why, but I don't like this. I think it looks nicer without:
www.example.com/profile

Are there any performance or security reasons to use the trailing slash in
Django? Seems like there could be some quirk with regular expressions that
I'm not thinking of...

Thanks --
Brett

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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

[birkin]

On Apr 16, 9:29 am, Aidas Bendoraitis <aidas.bendorai...@gmail.com>
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 <aidas.bendorai...@gmail.com>
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/
>  

Re: Clean URL Design: List Views and Details Views

[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 <aidas.bendorai...@gmail.com>
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

[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

[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

[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

[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

[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

[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

[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
-~--~~~~--~~--~--~---

Clean URL Design: List Views and Details Views

[Aidas Bendoraitis]

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: URL design for security?

[Ned Batchelder]

Right: an integer id is not sensitive information.  The problem arises 
(as in your original example), when a malicious user can edit the URL to 
change the id to another that he is not allowed to see, and your 
application lets him see it.  It's that last part you have to prevent.  
After using the authorization system to determine who the user is, you 
need an authentication system to guarantee that users only see data they 
are authorized to see.

--Ned.

John Shaffer wrote:
> On 7/14/07, Rogelio <[EMAIL PROTECTED]> wrote:
>   
>> yet.  I guess I was
>> thinking that even if the user was logged in, the URL still would be
>> showing potentially
>> sensitive info.  I was thinking maybe I needed to create some random
>> sequence of
>> letters/numbers, store that in a model field and use it as the pk
>> 
>
> Use the default:
> http://www.djangoproject.com/documentation/model-api/#automatic-primary-key-fields
>
> A student's row number isn't sensitive.
>
> >
>
>
>   

-- 
Ned Batchelder, http://nedbatchelder.com


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: URL design for security?

[John Shaffer]

On 7/14/07, Rogelio <[EMAIL PROTECTED]> wrote:
> yet.  I guess I was
> thinking that even if the user was logged in, the URL still would be
> showing potentially
> sensitive info.  I was thinking maybe I needed to create some random
> sequence of
> letters/numbers, store that in a model field and use it as the pk

Use the default:
http://www.djangoproject.com/documentation/model-api/#automatic-primary-key-fields

A student's row number isn't sensitive.

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: URL design for security?

[Rogelio]

Thanks for the replies.  No, I haven't incorporated authentication
yet.  I guess I was
thinking that even if the user was logged in, the URL still would be
showing potentially
sensitive info.  I was thinking maybe I needed to create some random
sequence of
letters/numbers, store that in a model field and use it as the pk
which would then
up in the URL params.  Probably overkill with my limited experience.
I'll take a look
at the authentication module and try some tests.  Thanks again.

Rog


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: URL design for security?

[Tim Chase]

> So my newbie question is:  Is there a way a better way to design/
> obfuscate the URL scheme when dealing with sensitive information?   I
> know once I get some sort of authentication in place that will help,
> but the idea of showing sensitive info in a URL still has me
> concerned.


The simple answer is "don't put anything sensitive in the URL".
In this case, that would mean not exposing things like SSNs in
the URL.  Since the teacher_id/student_id isn't sensitive,
they're fine in the URL.  However, you don't want people
accessing these URLs if they're not permitted to access them.

Enter Django's contrib.auth module.

Using Django's built-in "auth" module, it's dead-easy to do and
allows you to decorate your views with "login_required".  For
some example code, I'm just guessing at your models, but if one
student can have more than one teacher (as is often the case),
you'd have a M2M relationship between them.  However, if grades
are related to this relationship, you'd have to jockey the M2M
yourself.

I assume models like

# models.py
class Teacher(Model):
  user_id = ForeignKey(auth.User)
  # rest of definition

class Student(Model):
  # definition

class Class(Model): # don't know if this name is bad
  student = ForeignKey(Student, related_name='classes')
  teacher = ForeignKey(Teacher, related_name='classes')
  # rest of definition

class Grades(Model):
  class = ForeignKey(Class)
  grade = CharField(...)



# views.py
from django.contrib.auth.decorators import login_required
from django.shortcuts import get_object_or_404

@login_required
dev view_grades(request, student_id):
  # you don't need the teacher's ID in the URL
  # because they're linked to the request.user
  # the query would then look something like this
  try:
student_id = int(student_id)
  except:
raise Http404
  this_teachers_students = \
Student.objects.select_related().filter(
  classes__teacher__user_id =
  request.user.id
  )
  student = get_object_or_404(
this_teachers_students,
student_id
)
  ...


If the user isn't logged in and tries to request the view, they
get redirected to the login form.

If the user is logged in, but doesn't teach this student, they
should get a 404, because for them, this student doesn't exist.
You could customize it and return a more truthful HTTP error such
as a 403 (Forbidden) because the object might or might not be
found, but either way, they're not permitted to go poking around
here.

-tim





--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: URL design for security?

[skam]

Are you using authentication? It's better to handle security policies
in your application instead of hiding informations in URLs
Have a look at http://www.djangoproject.com/documentation/authentication

Bye,
Massimo


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

URL design for security?

[Rogelio]

Hi,

I'm starting to write a grade book type application.  There will be
many teachers that will be logging in to access their student
records.  The student record will contain student grades and sensitive
info such as student ID number.  In the model each teacher will have a
primary key (pk) and each student will have a primary key.  So if
teacher (with pk=21) logs in and wants to update the grade for student
(pk=197), the URL I'm calling to retrieve that view is "/grades/
21/197" (ie, on the teacher page there would be a list of student
names each being an  as shown).   I feel like
by using this scheme
I'm giving away too much info in the URL.  Some other teacher (or
person) who is NOT teacher (pk=21)
could just enter that URL and look at some other teacher's grades just
by "guessing" what pk to
plug into the URL.  What if the student pk was actually his SSN, then
I wouldn't want that as part of the URL for sure.

So my newbie question is:  Is there a way a better way to design/
obfuscate the URL scheme when dealing with sensitive information?   I
know once I get some sort of authentication in place that will help,
but the idea of showing sensitive info in a URL still has me
concerned.

Thanks in advance.
Rog


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---