On Thu, Mar 30, 2006 at 03:07:01PM -0500, Max Battcher wrote:
> I hate to say it, but Routes and most of the other schemes presented
> _do_ feel over-engineered. The current URL patterns system is fast
> and clean. The get_absolute_url() pattern is simple one, and yes it
> might break the
> I hate to say it, but Routes and most of the other schemes presented
> _do_ feel over-engineered. The current URL patterns system is fast
> and clean.
I actually agree 100%. And my earlier post indeed smacks of
overengineering. And in my current smallish project I don't intend to
do any of
On 3/30/06, ToddG <[EMAIL PROTECTED]> wrote:
>
> I'm not sure if this was earlier missed or ignored by people [nobody
> explictly ruled it out], I can't help but think Django's URL handling
> will either drift towards re-implementing Routes:
> http://routes.groovie.org/ or staying as it is.
I'm not sure if this was earlier missed or ignored by people [nobody
explictly ruled it out], I can't help but think Django's URL handling
will either drift towards re-implementing Routes:
http://routes.groovie.org/ or staying as it is. (note the lastest
version has a nice feature where you can
I'm going to type out loud for a little bit. I'm hoping to better
define the problem so we can think about solutions more clearly (or go
find ones as solved by other frameworks).
Django has the concept of an application, a reusable chunk of
functionality which can be reused in many different
Is it possible to do it all in urls.py? I don't know much about
Python, yet, but could you have two way look-up. urls.py has the URL-
>View handled. Could you stick in a dictionary based on classes (and
PKs, maybe) that would return the appropriate URL?
Todd
On Mar 29, 2006, at 10:38 AM,
On 3/29/06, James Bennett <[EMAIL PROTECTED]> wrote:
> On 3/29/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > And now you're encoding URLs (which are, in my mind, definitely
> > presentation-related) in the models?
>
> It's not something new; it's been this way since the first public
>
On 3/29/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> And now you're encoding URLs (which are, in my mind, definitely
> presentation-related) in the models?
It's not something new; it's been this way since the first public
release of Django. Adrian and others have said elsewhere that it's
On 3/29/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Adrian Holovaty wrote:
> > The convention is to put the URL-creation logic in your models, in a
> > get_absolute_url() method. Here's a quick example:
> >
> > class Person(meta.Model):
> > gender =
Adrian Holovaty wrote:
> The convention is to put the URL-creation logic in your models, in a
> get_absolute_url() method. Here's a quick example:
>
> class Person(meta.Model):
> gender = meta.CharField(maxlength=1) # 'm' or 'f'
> full_name = meta.CharField(maxlength=50)
>
>
On 3/29/06, Arthur <[EMAIL PROTECTED]> wrote:
>
> > > "correct" and just as simple, and each time I've failed. As far as
> > > I'm concerned, if someone can come up with a way to do this that's
> > > stupidly simple then I'm all for a change, but at the same time
> > > get_absolute_url() is a
On Tue, Mar 28, 2006 at 08:44:48PM +0200, Arthur wrote:
> That's similar to what I do. The get_absolute_url() concatenates a
> _BASE_URL from settings.py or from the top of models.py with
> what you call get_id_for_url. This isn't completely clean but easy to
> change if you remember where to
> > "correct" and just as simple, and each time I've failed. As far as
> > I'm concerned, if someone can come up with a way to do this that's
> > stupidly simple then I'm all for a change, but at the same time
> > get_absolute_url() is a wart I'm willing to live with.
>
> In the model you want
On 3/28/06, pbx <[EMAIL PROTECTED]> wrote:
> I think rolling functionality similar to ABSOLUTE_URL_OVERRIDES into
> URLconfs is the way to go. As others have pointed out,
> get_absolute_url() doesn't cover enough ground and creates unnecessary
> coupling.
You realize that because
On Tue, Mar 28, 2006 at 12:19:39PM -0600, Jacob Kaplan-Moss wrote:
> "correct" and just as simple, and each time I've failed. As far as
> I'm concerned, if someone can come up with a way to do this that's
> stupidly simple then I'm all for a change, but at the same time
>
On Mar 28, 2006, at 8:55 AM, pbx wrote:
> I think rolling functionality similar to ABSOLUTE_URL_OVERRIDES into
> URLconfs is the way to go. As others have pointed out,
> get_absolute_url() doesn't cover enough ground and creates unnecessary
> coupling.
>
> Simon expresses it well here:
>
>
I think rolling functionality similar to ABSOLUTE_URL_OVERRIDES into
URLconfs is the way to go. As others have pointed out,
get_absolute_url() doesn't cover enough ground and creates unnecessary
coupling.
Simon expresses it well here:
A sed won't work in all situations as it relies on the fact that you
constuct the URL in a particular way. What if the URL is constructed
dynamically in a template? Or in code?
Not to mention the fact that it breaks application encapsulation. If I
have ten integrated apps deployed a syntax
Adrian Holovaty wrote:
>The convention is to put the URL-creation logic in your models, in a
>get_absolute_url() method.
>
Thank you Adrian and others for this info! All this time I was honestly
thinking that hard-coded urls in templates are some kind of evil that
need to be dealt with in
I like the URLs at the model. Think in terms of URI (Uniform
Resource Identifiers). The .get_absolute_url() tells how the model can
be found. It's part of the "rules that give access" to data.
On 3/27/06, Glenn Tenney <[EMAIL PROTECTED]> wrote:
> Models are, in part, an abstraction of the
On Mon, Mar 27, 2006 at 04:21:09PM -0600, Adrian Holovaty wrote:
> The convention is to put the URL-creation logic in your models, in a
> get_absolute_url() method. Here's a quick example:
> ...
> You're right to imply that this goes against the DRY principle,
> because you have to define URLs in
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
Perhaps for a rainy day (very future release):
http://routes.groovie.org/
--~--~-~--~~~---~--~~
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
On 3/27/06, Doug Van Horn <[EMAIL PROTECTED]> wrote:
> 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
On Monday 27 March 2006 13:23, Doug Van Horn wrote:
> 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/$'.
> Anyway, am I overthinking this whole thing?
Yes. The major pattern in Django is that your model objects should have a:
def get_absolute_url(self):
return "/bar/%s/" % (self.id)
Then when you change the URL scheme you can either update your model
objects, or in cases where there are
What about mod_rewrite? And urls.py (afaik) can serve two different
paths to the same view.
On 3/27/06, Doug Van Horn <[EMAIL PROTECTED]> wrote:
>
> When drawing a link to that view in HTML from another app I would 'hard
> code' that URL as, say, 'href="/foo/bar/99"'.
--
Julio Nobrega -
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
28 matches
Mail list logo
