If you take a look, you’ll notice that URLObject, being a subclass of
unicode, can be used *directly* within the template and it'll render
out to the URL without any magic.
In addition, you can ensure that the URLObject is host-relative by
doing `url.without_host()` (or {{ url.without_host }} in a template).
That'll produce http:///path/foo/bar/ URLs; for schema-relativity too
just do url.without_host().without_schema(). It’s ugly but it works.
You could also implement a HTTP-specific convenience wrapper (i.e.
url.relative()).
If you want to determine whether a URLObject is host-relative, just
use {% if url.host %} from the template. Again, you might want to add
a simple is_relative() convenience method.
--
Zack
On 13 Sep 2009, at 18:17, Ivan Sagalaev wrote:
>
> Jacob Kaplan-Moss wrote:
>>>> schema, domain, path, query, fragment = urlsplit(obj.url())
>>
>> That's not in any way intitutive for a new user in the way that
>> `obj.url().schema` is.
>
> After thinking of it a bit more I agree about new users. My main
> concern
> though was about not using an established pattern.
>
>>> Oh... And for template authors we could just make 5 filters
>>> returning
>>> those parts:
>>>
>>> {{ obj.url|domain }}
>>
>> So we need *five* new built-in filters instead of `{{ obj.url.domain
>> }}`? Why? What if I want to access the username or password? Do we
>> "just" add two more filters?
>
> Looks like I shouldn't have posted that follow-up :-). It was only an
> afterthought. Actually I think we don't need even those 5 filters
> because there are no clear use cases for all of them. If we need
> schema-
> and host-relative URLs then we need exactly two filters:
>
> {{ obj.url|schema-relative }} (or better "protocol-relative")
> {{ obj.url|host-relative }}
>
> I think it's better than, say:
>
> //{{ obj.url.domain }}{{ obj.url.path }}?{{ obj.url.query }}
>
> The filter is also useful for {% url %}-generated URLs using {% filter
> %}. Which I believe is not doable with url-as-an-object thing.
>
> Thoughts?
>
> >
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
