Re: Updating the organization of the Django Project

Looks good, Aymeric! +1 On Thursday, July 24, 2014 1:30:13 AM UTC+12, Aymeric Augustin wrote: > > Hello, > > I’ve been working on updating our organization: > https://github.com/django/django/pull/2947 > > This proposal attempts to address several issues with our current > organization. There

Re: [GSOC] Weekly update

Hi Daniel, The proposal looks interesting - I've only skimmed it so far but one question: you mention User.get_model() several times -- do you mean User.get_meta()? On Saturday, May 24, 2014 7:05:02 AM UTC+12, Daniel Pyrathon wrote: > > Hi all, > > In the last days I have built a documentation

Re: Proposal to add a secure JSON encoding template tag

I like the idea, I've been using a custom script that does the first mode of this tag nearly exactly the same way (with the same security escaping). Not the biggest fan of the second mode of operation since like you say, it's not compatible with strict CSP. Why not just encourage people to do it

Re: Docs relating to splitting test files

On Saturday, May 3, 2014 6:10:39 AM UTC+12, Cal Leeming [Simplicity Media Ltd] wrote: > > This approach seems to work fine, but doesn't appear to be mentioned > anywhere in the Django docs (or at least, I couldn't see it). > > Would this be a valid candidate for a docs patch? > Hi Cal, The 1.6

Re: Cleaning up manage.py and import paths

Great job on getting the ball rolling on this, Carl! +1 on the whole idea Similar to what Russ and Luke are saying, I'd also prefer it if startproject dropped manage.py and the project Python package in the current working directory (with overwrite checks first). -- You received this message

Re: Custom transform in django docs

+1 to removing this non-standard documentation workaround. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/X7cbiXXSXyEJ. To post to this group, se

Re: django-irc-logs.com

Any update on this, Jannis? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/hA8I02L9m90J. To post to this group, send email to django-developers@g

Re: Test fails when setting MESSAGE_TAGS

It's a bug, open a ticket. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/h5dOinC2zCEJ. To post to this group, send email to django-developers@go

Re: Form Rendering API Proposal

On Tuesday, July 12, 2011 4:17:08 AM UTC+12, Gregor Müllegger wrote: > > Hm, hidden fields are something that I have not taken into account after > our > latest iteration. I think they are a bit special-cased and might need > attention even if we drop changing-the-widget feature. > Agreed, it'd

Re: Decision for ticket #6362 - Remove blank spaces with strip when validating the data

To clarify, didn't even notice we were talking about models.Field, I'm +0 for a 'strip' attribute on the form's field, nothing on the model. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://

Re: Decision for ticket #6362 - Remove blank spaces with strip when validating the data

On Sunday, July 10, 2011 12:06:34 AM UTC+12, Andrew Ingram wrote: > > I'm on the fence here, I like the idea of a strip flag, but I do agree that > it seems too specific. Perhaps something more generic, eg: > > myfield = models.CharField(max_length=255, text_filters=[StripFilter, > UpperFilter])

Re: Form Rendering API Proposal

Thanks for the followup reply, Carl. Yes, I think I was a bit confused regarding "for". Sounds fine. Your points about scope creep and keeping the proposal as achievable as possible is also noted. If we're going to keep things simple, why are we introducing the idea of inline "using" templates?

Re: Form Rendering API Proposal

On Saturday, July 9, 2011 12:19:44 AM UTC+12, Gregor Müllegger wrote: > > [...] So we decided to skip changing a widget totally in the form > rendering. > Displaying a form and anything else that happens in the template has a > representational purpose, so we saw it would be out of scope for the

Re: [GSoC form-rendering] Weekly Check-in

On Wednesday, July 6, 2011 2:30:12 AM UTC+12, Gregor Müllegger wrote: > > Hi, Chris. > > Seems that I'm now unemployed as GSoC Student, > looks like you already did all the work! ;-) > I prefer to show prototype code than just discussing things. It's more fun :) > Besides this, great work. If

Re: [GSoC form-rendering] Weekly Check-in

Hi Gregor, I've just put up a new version of django-forms [1] which implements a similar version of the proposal with the main difference being "extends". Take a look. 1. https://github.com/SmileyChris/django-forms -- You received this message because you are subscribed to the Google Groups

Re: Reversing translated urls in templates

On Monday, July 4, 2011 1:42:37 AM UTC+12, brocaar wrote: > > What about not implementing this as a url tag but as a translation- > override tag? Then it is not only possible to specify the language to > use for your URL translation, but as well for other translatable > content. Example: > >

Re: Form Rendering API Proposal

On Tuesday, June 28, 2011 11:56:41 PM UTC+12, Gregor Müllegger wrote: > > However I think these templatetags could go into a thirdparty app. > -0, changing a label / help text at least are pretty common cases - the template designer shouldn't be at the mercy of the python form settings. I'm glad

Re: Form Rendering API Proposal

Oh, and one more critical one: How does the form in python have knowledge of the widget which the field was rendered with as picked by the template? This is critical since building the form's data requires using the widget's value_from_datadict. -- You received this message because you are sub

Re: Form Rendering API Proposal

How do I override a field's label or help text? Specifically, help text may need to look something like: [[Can this person manage {{ site.name }}?]] How are HTML classes specified for rows which are required / contain errors? (and one more slightly obscure one, probably out of scope...) How doe

Re: Allow disabling choices in a

On Saturday, June 4, 2011 4:50:12 AM UTC+12, Jody McIntyre wrote: > > I can't think of a more concise way of clearly representing that 'bananas' > is disabled while still allowing it to have a label [...] > I'd say it would be more backwards compatible, and still reasonably concise to just hav

Re: need add RELATIVE_URL_ROOT as a default settings for project?

On Thursday, May 26, 2011 1:12:36 PM UTC+12, Russell Keith-Magee wrote: > > There is a separate discussion about whether LOGIN_URL should be > easier to use -- in particular, whether it should allow the use of > named URLs. > I know that it's not exactly the solution that the discussion was about,

Re: Filtering on Many2Many Related Objects

Isn't the first suggestion (__contains) achievable already by just chaining two filters: Group.objects.filter(persons=p1).filter(persons=p2) ? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-deve

Re: Field lookup types and backwards incompatibility

3. Change lookups to be uppercase (start the process of deprecating the current lowercase ones) -- 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 th

Re: Suggestion: a new "nature" field in Trac

On Friday, April 1, 2011 8:04:30 PM UTC+13, Julien Phalip wrote: > > Updating the 1800 open tickets is a big task, and to avoid duplicating > work I have set up a spreadsheet to coordinate our efforts: > > https://spreadsheets.google.com/ccc?key=0AoGUYlz9V54IdFQtbEpyZTctQzhhQTlfMWdmWGt2a3c&hl=en

Re: [GSoC] Revised form rendering

Haven't got time for a full review of this proposal right now, but I've done a lot of thinking about this area already and am more than happy for anyone to steal my ideas and compare thoughts. Shoot me an email off-list or catch me on #django (as SmileyChris) if you want to discuss more persona

render_to_* vs Template.render

After hunting down a very elusive bug, I found the cause to be due to the fact that render_to_string leaves the context in a different state than it started (due to the context stack being pushed before rendering, and then not popped). This behavior differs from a standard Template.render call

Re: Ticket #15124: BooleanField should not use False as default (unless provided)

On Friday, January 21, 2011 12:35:58 PM UTC+13, Karen Tracey wrote: > > Rather, a BooleanField that raises an error on an attempt to save an > instance that has no value set is what's being asked for. The quiet always > defaulting to False does seem rather odd to me as well. > The current behavi

Re: Ticket #15124: BooleanField should not use False as default (unless provided)

For good or bad, in Django a BooleanField is only ever supposed to be True or False. A default of False seems the logical equivalent to the default of '' on a not-null CharField. If you want a nullable boolean, you should use the separate NullBooleanField. -- You received this message because

Re: Proposal for inclusion of two additional default template tags.

I'm not opposed to the idea of an inline macro tag, but it doesn't need to be core. Here's how I'd write it (using django-ttag - untested and just off the top of my head) class Template(ttag.Tag): """ Provides the contents of this tag

Re: Session/cookie based messages (#4604)

On Oct 13, 8:34 am, Tobias McNulty wrote: > Before we get too far, I'd appreciate hearing feedback from one or > more of the core devs (and from some of the folks who were involved in > this discussion back when it was happening on the ticket) on the wiki > page[1] and the general direction this

Re: Revisiting #8245: admin.py errors under runserver cause app to disappear

I haven't looked hard at the fix, but I hit the bug a lot and agree that it would be great if this was fixed :) On Oct 4, 3:12 am, Carl Meyer wrote: > Anyone have thoughts on this? It would be really nice to get this > fixed so admin.py errors don't break the runserver, and I think the > updated

Re: Adding signing (and signed cookies) to Django core

On Sep 25, 1:56 pm, Ian Lewis wrote: > [...] unless accessing > COOKIES gives you raw values of ALL cookies and SIGNED_COOKIES > attempts to unsign ALL cookies. That seems really clunky. Yes, all cookies would stay in COOKIES. SIGNED_COOKIES would be a lazy dict-like object, not a plain dictiona

Re: Adding signing (and signed cookies) to Django core

+1 on the concept of a signing module. On Sep 25, 7:48 am, Marty Alchin wrote: > The one downside to using get() directly, as opposed to an altogether > new method, is that get() doesn't raise a KeyError when a value > doesn't exist. That means if anyone's wrapping request.COOKIES[key] in > a t

Re: Session/cookie based messages (#4604)

On Sep 21, 12:05 pm, Russell Keith-Magee wrote: > On Mon, Sep 21, 2009 at 6:13 AM, Chris Beaven wrote: > > >> One of the questions that needs to be answered > >> is "why should [a session based notification system] be shipped with > >> Django?"

Re: Session/cookie based messages (#4604)

> One of the questions that needs to be answered > is "why should [a session based notification system] be shipped with Django?" > Another piece of the puzzle that is missing from my perspective is any > discussion of how session-based messaging interacts with the existing > contrib.auth messagin

Re: Revisit ticket 2713?

Yeah, named urls didn't direct fix the problem. I've submitted a new patch. Now someone just needs to write the tests :P --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this grou

Re: FileFields and file ownership

On Aug 12, 3:08 pm, Malcolm Tredinnick wrote: > One of the reasons we *don't* delete files automatically [...snip] Just a correction: Django currently *does* delete files automatically when a model instance is deleted. --~--~-~--~~~---~--~~ You received this messa

Re: Session-based messages (Contrib-05, #4604)

On Jan 7, 4:20 am, "Jacob Kaplan-Moss" wrote: > I'd like to see this moved into an external app so that we can > de-couple it from the 1.1 release. If it proves to be popular and > stable, we could then consider it for 1.2. As a fun weekend 2h project, I started (and finished): http://code.googl

Re: Resize images on demand

Hi John, Probably the best thing to do is look at the contrib.thumbnails patch and see if there's something you could add to it: http://code.djangoproject.com/ticket/4115 On 5/16/07, John Sutherland <[EMAIL PROTECTED]> wrote: > > Morning, > > Sorry, I'm a little late to join this discussion. > >

Re: Resize images on demand

On 5/16/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > The other alternative might be to cache the file sizes and return it > that way. The benfit is that the filenames are cleaner but the > downside might be the complexity. Or we just keep it the way it is ;) Is there really that much bene

Re: Resize images on demand

Hrm... I can see how the name could be a bit confusing, but the reasoning is that that IS what the thumbnail was created with and that's how it decides whether there is a thumbnail for it or not. If you were to call it "240x192" then we wouldn't know that there was an existing cached thumbnail un

Re: Resize images on demand

On 4/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > In other words, I want the width to always be 75 but the height can > vary based on the specifics of the image. Does this make sense? If > this is what I'd like to do, how would I do it with the tag as it > stands now? Well without spec

Re: Resize images on demand

On 4/23/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > I downloaded the patch and got it to work. I have a couple of > observations based on usage. > > - If we continue to use the format "150x200" to specify the size, we > may want to do a string.lower() on the input. I originally had a >

My current solution to auto-escaping

Having to remember to escape every variable node in an html template when it's the normal behaviour seems so un-DRY.What I wanted was a way of adding the escape filter to every variable node (eg {{ object.name }}) without changing the core django code.So I made a block tag which can add filters to