Re: Small URLconf suggestion

OK, I see, thanks. It was just my point view that you devs might consider for the future. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to

Re: Creating "lazy" foreign keys

Not sure I follow you. You mean overriding the set property of a ForeignKey/IntegerField? On Feb 23, 6:23 am, "join.toget...@gmail.com" wrote: > What about something like a property()? The set method would act like > normal, but the get method would have some extra

Re: Creating "lazy" foreign keys

What about something like a property()? The set method would act like normal, but the get method would have some extra logic built into it that would take care of everything. On Feb 22, 1:52 pm, Collin Grady wrote: > You completely misread the tone of the email - that

Re: MarkupField

On Sun, Feb 22, 2009 at 8:40 PM, James Turk wrote: > >> First, I don't think you actually addressed the question mentioned in >> the ticket regarding the 3 fields. It seems the question was whether >> there should be three attributes on the Python model instance, >>

Re: MarkupField

I've updated my patch with a way to pass extra options to markdown/ docutils/textile that should handle any of the common cases. I've also moved render_markup into the class so that it is possible to override on an inherited class. > First, I don't think you actually addressed the question

Fwd: FileField.delete_file opening a file when deleting

Begin forwarded message: > From: Ludvig Ericson > Date: February 22, 2009 22:37:16 GMT+01:00 > To: django-developers@googlegroups.com > Subject: FileField.delete_file opening a file when deleting > > django.db.models.fields.files.FileField.delete_file often actually >

Re: MarkupField

I'll admit I'm not a markdown user generally and so I had neglected these extensions with the intent to do something similar to what the markdown filter does to handle this case but forgot before posting this patch. I'll update the patch mirror the way that the template tag works and provide a

Re: MarkupField

I haven't looked too much at the patch, so I can't comment much on the implementation yet, but reading your description and the ticket, I'd to offer some thoughts, based on some of my own thoughts I've had on this in the past. First, I don't think you actually addressed the question mentioned in

Re: Localflavor "US state" field choices

On Sun, Feb 22, 2009 at 5:17 PM, James Bennett wrote: > > Over the past few months we've had a few back-and-forth tugs in the > ticket tracker, and a couple of commits, related to the choice list > for ``django.contrib.localflavor.us.forms.USStateField.`` > > Relevant

Localflavor "US state" field choices

Over the past few months we've had a few back-and-forth tugs in the ticket tracker, and a couple of commits, related to the choice list for ``django.contrib.localflavor.us.forms.USStateField.`` Relevant background: * First, ticket #8425 asked for several choices to be removed, on grounds that

Re: MarkupField

On Sun, Feb 22, 2009 at 4:46 PM, James Turk wrote: > > > What about other types of markup? > Some have suggested supporting more types of markup but to me this > seems outside the scope of contrib.markup which currently only > supports ReST, markdown, and textile. Should

MarkupField

I've needed a model that stored the markup/markup_type/rendered-markup several times and typically just made those fields manually, but just recently when working on a few projects that all needed this behavior I decided to wrap up this behavior as a MarkupField and post it on django snippets

Re: Small URLconf suggestion

On Sun, Feb 22, 2009 at 11:29 AM, rihad wrote: > Nothing, really, It was just a design suggestion. I think that's the basic hang-up you're running into here: we don't really do that kind of development. Every single piece of code in Django exists because someone -- often lots of

Re: Creating "lazy" foreign keys

You completely misread the tone of the email - that *was* my pointer for how to do it - instead of trying to shoehorn it into ForeignKey where it doesn't belong, just use an IntegerField, possibly with model functions to do the querying (which could be made properties to act like fields) to get

Re: Small URLconf suggestion

On Sun, Feb 22, 2009 at 12:29 PM, rihad wrote: > > > > On Feb 22, 7:47 pm, Jacob Kaplan-Moss > wrote: > > On Sun, Feb 22, 2009 at 9:37 AM, rihad wrote: > > > Unless someone kindly proves me wrong, I really do think trailing > > >

Re: Small URLconf suggestion

On Feb 22, 7:47 pm, Jacob Kaplan-Moss wrote: > On Sun, Feb 22, 2009 at 9:37 AM, rihad wrote: > > Unless someone kindly proves me wrong, I really do think trailing > > slashes in the URL should be optional, > > As Russ already said -- did you read his

Re: Small URLconf suggestion

"Those are most *NOT* definitely the same". Typos too early in the morning, sorry about that. On Feb 22, 2009, at 8:29 AM, George Vilches wrote: > > > On Feb 22, 2009, at 7:44 AM, rihad wrote: >> I was just special-casing the backslash, which is special anyway, >> otherwise APPEND_SLASH

Re: Small URLconf suggestion

On Feb 22, 2009, at 7:44 AM, rihad wrote: > I was just special-casing the backslash, which is special anyway, > otherwise APPEND_SLASH wouldn't exist. > Moreover, hello and hello/ (and hello/) _are_ the same URL to > Django, otherwise it wouldn't redirect to the url with the slash >

Re: Small URLconf suggestion

On Feb 22, 4:44 pm, rihad wrote: > amount of trailing slashes number of trailing slashes. Sorry for my English. ;-/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post

Re: Small URLconf suggestion

On Feb 22, 3:55 pm, Russell Keith-Magee wrote: > So - what exactly are you proposing that we change in Django? > > Looking at your proposal as a purely end-user suggestion: using > 'hello/*$' means that hello// will match your URL pattern. > 'hello/?$' would be a

Re: Small URLconf suggestion

On Sun, Feb 22, 2009 at 8:36 PM, rihad wrote: > > Hi, devs, > I'm sure I'm not the only user who doesn't like the look of trailing > slashes in URLs, or more precisely, the difference in behavior that > they imply for Django users. How about simply changing this: > >

Re: Silently capturing all UnicodeDecodeError exceptions in widget rendering

On Feb 20, 10:52 pm, Malcolm Tredinnick wrote: > Yes. Non-developer-controlled content (which is usually what's being > converted by filters) should not be allowed to crash template rendering. > The data coming into the template variables could be from a lot of >

Small URLconf suggestion

Hi, devs, I'm sure I'm not the only user who doesn't like the look of trailing slashes in URLs, or more precisely, the difference in behavior that they imply for Django users. How about simply changing this: (r'^hello/$', hello), to this (r'^hello/*$', hello), so that any

Re: Creating "lazy" foreign keys

Except... I'm not expecting anything. I'm going to work on this regardless, I'm just proposing to share my work in exchange for a few pointers here and there. Sarcasm, and blaming the user, is a very tasteless way of saying no. On Feb 22, 10:52 am, Collin Grady wrote:

Re: Creating "lazy" foreign keys

Seems you could just use an IntegerField and do it yourself, instead of expecting django to adapt itself to your bad db design :) On Sat, Feb 21, 2009 at 5:16 PM, Adys wrote: > > I see what you mean. I agree to an extent - data needs to stay as > clean as possible. But this