On 3/28/06, Doug Van Horn <[EMAIL PROTECTED]> wrote:
>
> Disclaimer: I'm new to Python and Django, but I've been coding Java
> since '98.
>
> In thinking about the url definitions in urls.py, it occurs to me that
> a major rewrite of the url patterns could prove to be a pain. For
> example, I have an app where the urls are deployed under /foo/, and I
> have a URL defined as '^bar/\d+/$'.
>
> When drawing a link to that view in HTML from another app I would 'hard
> code' that URL as, say, 'href="/foo/bar/99"'.
>
> Now say I come along and change my foo application, such that the URL
> is newly defined as, '^quux/\d+/bar/$'. Everywhere I've hard coded
> that link will now be affected, requiring code changes and testing.
> I've tightly coupled my app urls.
>
> In response to this problem, my over-engineering brain tells me to
> create 'URL' objects, containing the regex defining the URL as well a
> way to 'construct' a 'real' URL.
>
> In my example, the calling application would now have something like
> bar_url = BarURL(bar=99). I would then use this object to render a
> 'real' url as such, 'href="{{ bar_url.render_link }}"'. The calling
> application would only need to know that a BarURL needs a bar parameter
> to construct a valid URL. The BarURL class would be responsible for
> defining the regex, constructing a valid URL, and somehow picking up
> the deployed application prefix (/foo/ in our case).
>
> Finally, the urls.py module in my foo application would do something
> like 'BarURL.REGEX' where one would normally define the regexes for an
> application, e.g., (BarURL.REGEX, 'app.foo.views.bar'),.
>
>
> Anyway, am I overthinking this whole thing? I'm not asking for a
> patch, but rather advice on whether this kind of thinking/approach
> makes sense in the Django framework? Is it 'pythonic', as they say?
> It seems somewhat OO to me, and I like encapsulating the behavior
> inside a class. I guess I'm just looking for some seasoned expert
> opinions. Well, any opinions really.
>
>
> Thanks!
> doug.
>
>
I think your thought is very well. And I also faced the same situation
as you. And I also think different application need has different url
prefix, and all its functions should be related to the prefix. So a
real application will be:
prefix + function_name + parameters
And these things should be implemented both in urls.py and views or
template code. But now there is not a official method to do that. So I
defined myself pattern to do that:
first, I defined a mapping between application and prefix in
settings.py, just like:
APP_ROOT = {'blog':'blog', 'setting':'setting', 'tags':'tags',
'medias':'medias'}
second, I wrote some function and custom tag in order to get the app's prefix
So in views and template code I can get a certain app's prefix through
by a function get_app_root('blog') (written by myself) or by a custom
tag {% get_app_root "blog" %}. So I only need to deal with
function_name + parameters is ok, just like:
url = get_app_root('blog') + / + 'function_name/parameters/'
in template
<a href="{% get_app_root "blog" %} / functioin_name/parameters">xxx</a>
--
I like python!
My Blog: http://www.donews.net/limodou
NewEdit Maillist: http://groups.google.com/group/NewEdit
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
