On 3/30/06, Glenn Tenney <[EMAIL PROTECTED]> wrote:
> But, it didn't seem to get any comments pro or con, so let me try again:
>
> I believe that the Model should have a common method used
> to get a PART of a URL, the part that locates this object. That part
> of the URL might be "place/<objectid>" or "poll/<slug>". But that
> is not an absolute url. It would then be up to the view (in a generic
> view, that should be handled by a dict entry) to pre-pend something in
> front of what the model provide to make it a URL.
>
> perhaps:
>
> In Models: get_url()
> returns a string that can be used by the view to make up a URL that
> uniquely identifies this object.
>
> In urlsconf:
> add to "infodict" -- 'url_view': 'polls'
>
> In the view:
> you form a url from: URL_BASE + 'url_view' + get_url()
> ( URL_BASE might not even be needed )
Since I'm feeling vocal: I saw that and I would suggest that I'm -0
on the idea. It is a decent idea, but it isn't so much a framework
need than it is an application/project pattern need. Sure, people are
decrying that there is no "one way" pattern right now, but I think
until one emerges that we can all agree on, there isn't enough pain in
the current process of brokering between applications to warrant the
effort of establishing that standard.
With that said, you are completely free to use the above pattern, or
something similar to it, in _the existing framework_. The current
thing about the current framework functionality being that it is a
simple minimum and it is reasonably powerful. Here's what you could
do:
Create your get_url() functions as you specified. Then you have a
simple enough get_absolute_url():
def get_absolute_url(self):
return DEFAULT_URL_BASE + self.get_url()
That satisfies both you (you just care about the get_url()) and the
Framework (which, really, the only major Framework part that uses
get_absolute_url() is contrib.shortcuts and contrib.admin, and maybe
by now several template designers are used to it).
If you want a dynamic URL base you are even free to create a
get_url_base_from_view() function and call it from
ABSOLUTE_URL_OVERRIDES, like so:
ABSOLUTE_URL_OVERRIDES = {
'myapp.mymodel': lambda o: magic_get_url_base_from_view() + o.get_url(),
}
Again, zero changes to current functionality and you have your custom
functionality that your end users (aka, other developers) may or may
not thank you for when they set out to customize your application, and
it shouldn't interfere with my (or the next developers) own preferred
way of dealing with things (in some ways I'd heavily argue that the
URL scheme is highly dependent on the type of application in question,
anyway, and we aren't going to agree on a standard pattern).
The only feature I could see a call for in this particular case,
because you are going to have a strong, repetitive pattern here in
your ABSOLUTE_URL_OVERRIDES, and that isn't very DRY, is that maybe
you could use some sort of pattern matching in ABSOLUTE_URL_OVERRIDES
like being able to use 'myapp.*' or '[myapp1, myapp2].*'.
--
--Max Battcher--
http://www.worldmaker.net/
All progress is based upon a universal innate desire on the part of
every organism to live beyond its income. --Samuel Butler
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
