Re: Don't assume that missing fields from POST data are equal to an empty string value.

Optional or required is not the same thing as important. It is entirely valid to have important but optional fields on a model. For example, a field that contains a string reference to a python callback function that modifies the behaviour of some model methods when set. We use this on a

Re: Don't assume that missing fields from POST data are equal to an empty string value.

Tom, the problem is not caused by using `exclude`, it is caused by not using `fields`. If you use `exclude` or simply don't specify `exclude` or `fields` then all fields will be included. Thanks for your other example and description of the problem, I just wanted to clarify that it is not only a

Re: Don't assume that missing fields from POST data are equal to an empty string value.

ot;". > > Neither error condition is optimal, however A has the additional downside > that this error is completely outside of the control of the developer whereas > B is the result of developer error and is under his control. > > > > > > > > On Tuesday, Januar

Re: Don't assume that missing fields from POST data are equal to an empty string value.

Ian, I agree that there are a lot of different ways that form data can be submitted to Django, including near endless combinations of multiple Django forms, multiple HTML forms, AJAX, etc. If we reduce the scope of our discussion and consider only a Django form (forgetting HTML forms and AJAX)

Re: Custom managers in reverse relations

Instead of trying to dynamically change the manager used for reverse relations or any manager/queryset (either by getting and then throwing away the default manager, or some other method), or applying manual filters to achieve the same result, there is another alternative. Instead of: {{{

Re: Feature Request: Client side validation classes for forms

I found that Alex's `django-ajax-validation` works pretty well for this and I think it works the way you described. Perhaps it could be updated and included into Django core, if there is good support for it. https://github.com/alex/django-ajax-validation/ Cheers. Tai. On Feb 4, 8:03 am, Adrian

Re: auth.User usernames

I created a generic `accounts` app which has (among other things) it's own `Profile` model with a username field and a OneToOneField pointing at `User`. I added an authentication backend to my settings that checks usernames from my model. Of course there are other supporting components, forms,

Re: auth.User usernames

It's not that hard to just set up a OneToOneField back to User, and use signals to automatically create a User when you create your own User/Profile. Then you can still make use of 3rd party apps that rely on contrib.auth or contrib.sessions, and also make use of groups from contrib.auth, etc.

Re: Newline stripping in templates: the dnl way

I definitely want to see a resolution to this issue. Django templates when white space matters (e.g. plain text emails) are painful. But, I don't think adding {# to the end of lines is easy to understand at a glance, it doesn't even convey a hint of meaning like "dnl" does, but either option is

Re: Newline stripping in templates: the dnl way

content. 99% of the time this is the right thing to do, and we just need a deprecation path and new template tag so that template authors can opt-in to the new behaviour now. Cheers. Tai. On Feb 25, 4:37 am, Tobia <tobia.confo...@gruppo4.eu> wrote: > Tai Lee wrote: > > I don

Re: Newline stripping in templates: the dnl way

I think this discussion is focusing on template tags, not template variables. Maybe even a subset of template tags (e.g. block level tagsif, for, block, filter, etc). Template variables and inline tags (e.g. now) shouldn't have white space stripped. In 100% of cases I can think of I either

Re: Newline stripping in templates: the dnl way

On Feb 29, 8:15 am, Leon Matthews wrote: > Would it be feasible to add some logic, something along the lines of: > > "Template lines containing just tags with no literal content do not > produce a line in the output  (unless of course the tag itself > produces one)" I

Re: Pretty Django model instaces updating

This is easy to achieve in your own code. Create your own BaseModel class that all your models subclass. Instead of using `.filter().update()`, do this: def update(self, **kwargs): """ Updates the fields specified in `kwargs` and then call `save()`. """ if kwargs:

Re: Tagging 1.4 django release in Subversion

How come? The release that can be downloaded from the site already must correspond to an SVN revision number, right? Why not tag it as such so that people can easily get the same code from SVN as from the release tarball? Cheers. Tai. On Sunday, 25 March 2012 22:02:30 UTC+11, Florian

Django should not use `force_unicode(..., errors='replace')` when parsing POST data.

I've just created an essay *cough* I mean ticket about the way Django silently mangles POST data that is incorrectly encoded, and how this can send someone (like me) down the rabbit hole trying to debug it, thanks to "current transaction aborted" database errors. This shouldn't normally

Re: Django should not use `force_unicode(..., errors='replace')` when parsing POST data.

I agree that it is not an ideal user experience to raise an exception while decoding POST data. However, I think the alternatives are arguably just as bad, or even worse. I consider silently replacing characters in user data to avoid an exception while decoding to be a silent data loss /

Re: auth.user refactor: the profile aproach

I like this proposal because I am a big fan of a stripped down `User` model which is basically just an ID, whic provides a common hook into groups/permissions and other django and 3rd party profiles. What I don't like is the magical `data` bag (accessing `User.data` and filter lookups), the

Re: auth.user refactor: the profile aproach

I'm not so sure that it's necessary or even desirable to solve the "general" problem of swappable models. If anyone can swap any model by changing a setting, that sounds like a recipe for confusion to me. Seems to me that the main benefit of the swappable models approach is just to avoid

Re: auth.user refactor: the profile aproach

Are we really sure that we can or should stomach a swappable User model as a special case? It's highly likely that I am missing something (or a few things), but aren't the main benefits of swapping the User model just to avoid making a backwards incompatible change, and to avoid making

Re: auth.user refactor: the profile aproach

On 06/04/2012, at 3:09 AM, Ian Lewis wrote: > The good part about swappable user models is that you don't need to > necessarily fix the model's DB fields in advance. Your identifier and > password's length and other properties can be user defined and can be > reflected in the DB. > > Django

Re: auth.user refactor: the profile aproach

scheme migrations, and duck typing a single model for use with multiple pluggable apps. Cheers. Tai. On 06/04/2012, at 7:42 AM, Anssi Kääriäinen <anssi.kaariai...@thl.fi> wrote: > On Apr 5, 11:29 pm, Tai Lee <real.hu...@mrmachine.net> wrote: >> But I still don't see how a sw

Re: auth.user refactor: the profile aproach

Alex Ogier, Is it really better to require users to create their own User model that behaves like an admin user, instead of just shipping with a self contained admin user (as a profile model) without the auth component? If the auth app was purely a stub to connect different profiles and

Re: auth.user refactor: the profile aproach

Tom, Thanks for raising those issues. I would just like to add that I hope to see fields currently in `User` that are required by the admin (is_staff, etc.), moved to an admin profile model, and not simply made available through mixins that are still required by every `User` model that gets

Re: auth.user refactor: the profile aproach

Alex, I think the problem with this aspect of your proposal is that it signals a green light for other pluggable apps to follow Django's lead and provide mixing which must be added to their `User` model in order to use the pluggable app, instead of creating a profile model for their pluggable

Re: auth.user refactor: the profile aproach

ofiles. > > It should be used for generic-esque data about a User. e.g. Email, phone > number, name, etc. > > It should not be used for app specific data about a user, e.g. Default > Gallery, Notification Settings, etc. > On Tuesday, April 10, 2012 at 6:01 PM, Tai Lee wrote:

Re: Admin site: Appropriateness of HTTP 500 when using non-allowed query strings

I agree with this. HTTP 500 error should not occur due to users attempting to subvert the system somehow. HTTP 500 errors should only be returned when an unhandled exception occurs (which shouldn't happen). Cheers. Tai. On Tuesday, 10 April 2012 21:34:07 UTC+10, 3point2 wrote: > > The admin

Re: GitHub migration planning

This seems odd to me. Django is generally a very open and community oriented project, which strives to consult with the community and achieve a consensus, resorting to a BDFL decision when necessary, after all sides have put their case. Maybe I wasn't following closely enough (apologies if

Re: ModelForm.Meta.overrides

Overall, I like this patch. I think it's a little unbalanced that we provide `Meta.widgets` but no clearly documented way to override other properties on fields without replacing entire fields. I think the doc changes are pretty helpful to users who are looking for a way to do this, and it is

Streaming HttpResponse revisted. Any core devs, please take a look if you can :)

I'd like to re-visit the discussion surrounding #7581 [1], a ticket about streaming responses that is getting quite long in the tooth now, which Jacob finally "accepted" 11 months ago (after a long time as DDN) and said that it is clear we have to do *something*, but *what* remains to be seen.

Re: Streaming HttpResponse revisted. Any core devs, please take a look if you can :)

It sounds like the preferred solution is still "don't do that", which I think corresponds most closely with option 1. Simply consuming generator content in `HttpResponse.__init__()` in all cases would prevent some of the surprising behaviour we are seeing, but it would completely break any

Re: Streaming HttpResponse revisted. Any core devs, please take a look if you can :)

After discussion with akaarai and mYk on IRC, I have two updated proposals. OPTION 6: 1. Consume `HttpResponse.content` on first access, so that it can be read multiple times and eliminate the current buggy behaviour (e.g. `response.content != response.content`) when a generator is passed in

Re: Streaming HttpResponse revisted. Any core devs, please take a look if you can :)

I have updated the patch on my GitHub repository after some discussion on IRC with Anssi. The patch applies on master again now, it consumes generator content on access instead of on assignment, and raises a PendingDeprecationWarning if you create an HttpResponse with stream_content=True and

Re: Streaming HttpResponse revisted. Any core devs, please take a look if you can :)

Hi Aymeric & Anssi, Thanks for your feedback. I have updated my branch with an implementation of a new `HttpStreamingResponse` class plus tests and updated the ticket. Please take a look and let me know if this is moving in the right direction, and if there is any other feedback. If the

Re: Streaming HttpResponse revisted. Any core devs, please take a look if you can :)

Docs have been added (patch should be complete now) and pull request has been opened, at Anssi's request. https://groups.google.com/d/topic/django-developers/RrNPfuJxnlM/discussion Cheers. Tai. -- You received this message because you are subscribed to the Google Groups "Django developers"

Re: Update on localflavor move

Hi Aymeric & Adrian, I didn't see any further discussion or consensus on the issue of the generic localflavor. The 1.5 docs and (accelerated) deprecation of localflavor are a little hazy regarding the generic localflavor. The 1.5 docs say that it hasn't been removed (yet), but doesn't say it

Re: HttpResponseStreaming, ticket #7581, and [soc2009/http-wsgi-improvements] Final(?) status update

On Aug 15, 3:19 am, ccahoon wrote: > This is the case, yes, if the HTTP and GZip middleware are not used. > We had to modify both of those to make sure they didn't consume the > content generator to find the Content-Length. I imagine, IF we wanted > to, setting the

Re: Session/cookie based messages (#4604)

On Oct 14, 10:45 am, Tobias McNulty wrote: > > Okay, let's pick something other than 'messages' and stick to it.  I'm > fine with "notifications", "notices", and maybe even "notes", but the > last one is a little ambiguous.  Other ideas? My personal bike shed is named

Re: Reversing URL for a view with namespaces

Speaking of the ways in which a namespace can be specified or provided, #11642 might be relevant here. http://code.djangoproject.com/ticket/11642 It feels a little cumbersome to me to require users to either manually specify a namespace or import a different object (than just the usual urls

Re: Model validation incompatibility with existing Django idioms

It makes sense to me that the developer should first check that their form is valid and second check that their model object is valid when calling ModelForm.save(commit=False). This could be done by having the developer check the result of model.full_validate() before calling model.save(), or by

Re: Model validation incompatibility with existing Django idioms

On Jan 9, 12:36 am, Honza Král wrote: > On Fri, Jan 8, 2010 at 11:59 AM, koenb wrote: > > > On 8 jan, 10:03, James Bennett wrote: > > >> Suppose I have a ModelForm and call save(commit=False) to get the > >> instance so

Re: Django Design Czar

It feels like a catch 22 situation. We need someone to champion and shepherd design changes into trunk, but we can't assign such a role to somebody who hasn't met the criteria that each core committer must meet. To quote the Django documentation, any design czar or core designer should have "a

Re: Fixing middleware/view decorator handling of content iterators

See also #7581, which has a patch that I have been using in my local Django branch for over a year without issue. My use case is that I need to generate large amounts of data in CSV format and stream the response to avoid timeouts. I wouldn't mind `HttpResponse` consuming `content` immediately if

Re: Fixing middleware/view decorator handling of content iterators

On Feb 21, 7:46 am, Forest Bond wrote: > Okay, I think "disabled_middleware" is a bad name because it doesn't actually > imply that all middleware should be disabled.  Anyway, it seems like > middleware > could just check if isinstance(response,

Re: Fixing middleware/view decorator handling of content iterators

I didn't think about the author of a `HttpResponse` subclass needing to know all potential middleware that will not work with that particular response class. That is definitely a problem. However, I don't think that exposing a capabilities based API on `HttpResponse` is the answer. If we do that,

Re: Proposal: Revised form rendering

Regarding the DOCTYPE problem, I don't think it's appropriate to set the DOCTYPE as a setting for an entire project. As many have pointed out, each bundled app could define a different DOCTYPE in their base templates. It doesn't make sense to apply a DOCTYPE setting to the context of a form

Re: Proposal: Revised form rendering

I really like the idea of using Django templates instead of generating markup in Python, which should enable designers (who don't know and don't want to know Python) to customise markup in almost any way they like. We just need to add a few hooks that will make it easier to override specific

Re: Proposal: Revised form rendering

Hi Russ and Carl, On Jul 14, 5:55 am, Carl Meyer wrote: > Hi Russ, > > On Jul 13, 12:11 pm, Russell Keith-Magee > wrote: > > > My manifestation of this problem is slightly different -- it's the > > issue of how to ship a widget library that can

Re: Proposal: Revised form rendering

Hi Carl, On Jul 14, 11:44 am, Carl Meyer wrote: > > I totally agree with this. I think very similar results can be > achieved in the form-rendering system just with an optional parameter > to a "form/render_form" tag that specifies a "base path" for finding > template

Re: Proposal: Revised form rendering

On Jul 14, 11:15 pm, Russell Keith-Magee wrote: > > I'm not wildly enthusiastic about this. You've posted this snippet (or > something like it) a couple of times, and every time my immediate > reaction has been "You're in a twisty maze of endtemplatedir tags, all >

Re: HttpResponse: freeze API, read_once

I'm going to try and preempt a possible objection that has been raised in previous discussions on this subject. Won't this change require a lot of repetitive logic to be shifted into middleware functions? All middleware authors will now need to inspect the response and find out if they can make

Re: HttpResponse: freeze API, read_once

e manually and return that, rather than using a helper function like direct_to_template? Cheers. Tai. On Sep 15, 2:25 pm, Tai Lee <real.hu...@mrmachine.net> wrote: > I'm going to try and preempt a possible objection that has been raised > in previous discussions on this subject. > &g

Re: ANN: Improving our decision-making and committer process

On Sep 30, 7:22 pm, Russell Keith-Magee wrote: > What is also needed is a whole lot more people volunteering. Any > suggestions on how to get more people doing the entirely unglamorous, > but completely necessary work will be gratefully accepted. I'd like to suggest (1)

Re: ANN: Improving our decision-making and committer process

Hi Jacob, Thanks for your feedback. > For (1) check out http://code.djangoproject.com/wiki/Reports(it's > linked in the nav). If there's anything missing there, please feel > free to add it -- it's a wiki page. Let me know if you need help > figuring out the linked query syntax. I wasn't able

Re: ANN: Improving our decision-making and committer process

Hi Russ, On Oct 5, 11:48 am, Russell Keith-Magee wrote: > There have been a couple of suggestions recently that the contributing > guide should be distilled into a specific HOWTO for new users. I > suppose the idea here would be for the contribution guide to be the >

Re: Model proxy instance does not equal the respective model instance

I think that since Proxy models only affect the methods, properties and way the data is used (not the actual underlying data itself), it is appropriate to compare User and UserProxy as equal. To not treat them as equal, you will need to be sure that you never pass a UserProxy object to a 3rd party

Re: RFC: Add a "needinfo" state to triaging

I like the idea of needmoreinfo as a resolution, which makes it clear to the reporter that they need to take the next step to re-open the ticket with more info. I don't think that closed with "invalid" and a comment makes this as clear. However, I think there's another problem area where we need

Re: Doc. patch

The following two tickets are fairly trivial, with docs and tests, both accepted by a core dev 7 plus months ago. http://code.djangoproject.com/ticket/12398 http://code.djangoproject.com/ticket/13291 This one is 2 years old and has no docs (but I'm not sure if they are required). It was marked

Re: RFC: Add a "needinfo" state to triaging

I'm in favour of closing tickets with "need more info, re-open when you have it or if you disagree" because it clearly puts the onus back on the reporter to re-open the ticket after addressing the feedback in order to see any progress. Leaving tickets "open" with potentially yet another status or

Re: RFC: Add a "needinfo" state to triaging

This has been my experience, as well. I know this is an open source project and that we're all volunteers, but I have found it it extremely disheartening and a discouragement to further contribution when I have invested the time to do the right thing and submit a detailed report, with patch and

Re: RFC: Add a "needinfo" state to triaging

I believe that only the reporter, owner, and CCs are notified when an update is made, not anyone who added a comment. Unless a reviewer adds themselves to the CCs when providing feedback or assigns the ticket to themselves (which would be unlikely, when leaving feedback that the reporter needs to

Re: Enabling context access in simple_tag

I've been using the patch from #1105 in my local branch of Django for a long time now. To be honest, I've hit the need to have access to the existing context in a simple_tag far more frequently than the need to return a single value as a named variable in the context, and I'm definitely +1 on

Some tickets that need love before 1.3 feature freeze.

There are a few tickets that I believe are or should be RFC that I would like to see committed before the 1.3 feature freeze kicks in, which I just heard was very soon now. If anyone has time, could they please review the following and bump to RFC or provide additional feedback if they're not yet

Re: Small decision needed on #15025

I just discussed this with Don on IRC. An example of the use case described is at: http://djangosnippets.org/snippets/1016/ The fix for this use case is easy. Pass a list of `(button.func_name, button.short_description)` tuples as `buttons` in the context instead of passing a list of callables.

Re: Small decision needed on #15025

If we can, I would be in favour of treating the old behaviour as a bug and not having to support it while it follows a deprecation path. However, either way, if the new behaviour stays (and I definitely think it should) I think we should update the docs to clarify that there was a change in

Re: Small decision needed on #15025

On Jan 13, 5:06 am, Don Spaulding wrote: > > I can't speak to the number of templates actually in the wild that > rely on the old behavior.  I will say that the debug template has been > "relying on the bug" since 2005.  By my estimation, that makes nearly > every

Intermittent IOError exception raised and emailed to admins during file upload.

There are many questions about this on django-users. The usual answer is to ignore the errors, which are probably generated as a result of the client prematurely terminating a connection, usually during an upload. Nobody seems to be able to reliably reproduce the error, and it seems to happen

Re: Intermittent IOError exception raised and emailed to admins during file upload.

lution at this time for this. > > Graham > > > > > > > > On Friday, February 4, 2011 1:55:25 PM UTC+11, Tai Lee wrote: > > > There are many questions about this on django-users. The usual answer > > is to ignore the errors, which are probably generated as a

Re: Intermittent IOError exception raised and emailed to admins during file upload.

It seems to happen with very small file uploads as well. I've seen it reported with 30KB uploads, while at the same time 60MB uploads work. If I can't find a problem with the server causing disconnects, and it is actually on the client side, I'll just have to continue to ignore the exception

Re: Intermittent IOError exception raised and emailed to admins during file upload.

on other higher traffic sites across different browsers and using different server side technologies, to see if this really is typical. Cheers. Tai. On Feb 5, 2:23 am, Jacob Kaplan-Moss <ja...@jacobian.org> wrote: > On Fri, Feb 4, 2011 at 2:45 AM, Tai Lee <real.hu...@mrmachin

Proposal: Add current_app to request and pass it to template loaders.

I have a generic app which includes base templates (for HTML documents, emails, etc.) and also template tags that render a template (for form fields, pagination forms/links, filter forms/links, etc.) Sometimes I have a project that has several other apps installed which both use the base

Re: Wrong error message when user having is_staff=False tries to login to admin

I also don't think it should be considered a security vulnerability to reveal that an authenticated user does not have permission to access the admin (or any other) app. If the credentials are valid and they authenticate against the defined authentication backends, then we should assume that we

Re: Default project layout / directory structure

If we're talking about the lowest common denominator and keeping things simple, this is what I think we'd have: myapp1/ myapp2/ myproject/ -django.wsgi.sample -manage.py -management/ --commands/ ---myproject_mycommand.py.sample -media/ --myproject/ ---readme.txt -models.py -settings.py -static/

Re: Proposal: Add current_app to request and pass it to template loaders.

Now that 1.3 is out, does any core dev have an opinion, feedback or suggestions on this? I've solved my immediate need with two template loaders (subclasses of the app_directories loader) that use thread locals. One prefixes the requested template name with the app name and the other prefixes it

Re: Proposal: Add current_app to request and pass it to template loaders.

On Mar 28, 4:08 pm, Justin Holmes wrote: > By "current app," do you mean the app which contains the view to which > the current URL is mapped? I mean the "namespace" (instance name) for the requested URL or the "current_app" attribute of a context object which is

Re: math tag

On May 3, 9:43 am, Russell Keith-Magee wrote: > This stems back to the design motivation of Django's template language > -- you shouldn't be doing math in the template. Instead, you should be > doing your math in the view, and providing the template with a >

Re: Field lookup types and backwards incompatibility

I thought Django already did option 1. If it doesn't, why not? What are the possible edge cases? Using a date field named "date" as a foreign key to another model that also contains a "date" field? On May 10, 1:47 am, Ulrich Petri wrote: > Currently there are at least 4 open

Vote on {% include %} behaviour.

G'day, There are several open tickets (some getting quite old now) that all stem from the inconsistent behaviour of the {% include %} tag. When a quoted string is used for the path, it is treated as a special case and the include is executed at compile time. Otherwise, it is executed as the

Re: Vote on {% include %} behaviour.

On Jun 3, 9:32 pm, Jonathan Slenders wrote: > I really never want to have the {% block %} names of B/C in previous > example to be available for overriding in templates which inherit from > A. This would even cause unexpected collisions between block names. > The

Re: required=True for BooleanFields

This has been discussed many times in the past. For better or worse, we're stuck with the current behaviour for backwards compatibility. I personally think it's better this way. Without this behaviour, it would be a PITA to implement forms that have a "required" boolean field (must be ticked)

Re: required=True for BooleanFields

On Jun 17, 3:41 pm, David Cramer wrote: > I'm not suggesting changing the behavior (again due to the > compatibility concerns), but I completely agree with the original > poster(s). > > Also, in my experience it's a much less common case that you're > wanting an "I agree"

Consistent exception handling in templates.

I'd like to raise the topic of exception handling in templates, to see what people think of the current state and discuss possible improvements. I personally find it confusing to use and create template tags at times, due to exception handling. Sometimes exceptions are supposed to be silenced,

Re: Consistent exception handling in templates.

On Jul 8, 11:31 pm, Jacob Kaplan-Moss wrote: > > [...] but some of Django's own template tags (e.g. `widthratio`) don't > > adhere to > > this policy. > > These are bugs, and should be fixed. Thanks for this clarification. I will try to review the built-in tags and submit

Re: Consistent exception handling in templates.

On Jul 9, 12:24 pm, Karen Tracey wrote: > I'm strongly against that idea. Swallowing errors makes it incredibly > difficult to debug errors. I would prefer for the `TEMPLATE_DEBUG` setting to > turn off much of the error-silencing currently done in template processing. >

Re: Patch for using custom managers in a reverse relation. (#3871)

Is this really much better than using your own custom manager as the default automatic manager (used for reverse relations) with `use_for_related_fields = True`? Your custom manager could do nothing to filter results by default and so behave the same as the default automatic manager, but provide

Re: deprecation vs removal

On Oct 4, 11:17 am, Russell Keith-Magee wrote: > I'm completely agreed that the 'soft' deprecation is useful. I'm just > complaining about the ambiguity in the language: "We're deprecating > this feature by marking it PendingDeprecation...". What about just changing

Re: DecimalField model validation

Why is ROUND_HALF_EVEN superior? Perhaps for statistics, where rounding all halves up would skew results, but I guess not for most other cases. If the default rounding behaviour produces different results than a regular calculator, common spreadsheet and accounting software or even human

Request for eyes familiar with ORM internals and defer/only (attn: Malcolm)

I've run into a bug that is exposed when using defer() or only() with select_related(). A couple others have come across it, and there is an existing ticket. Exceptions appear to be silenced somewhere under normal circumstances when evaluating `queryset` objects, which made it difficult to track

Re: RFC: Query Methods

I have had difficulty in finding an easy way to add common methods to querysets and managers for multiple models in Django. I solved the problem in my projects by defining a custom `Manager` class which defines `use_for_related_fields = True` and also overrides `__getattr__()` to look for

Don't assume that missing fields from POST data are equal to an empty string value.

There is a potential for data loss with optional form fields that are (for whatever reason) omitted from an HTML template. For example, if we take an existing model form and template that works, add an optional character field to the model but fail to add a corresponding field to the HTML

incorrect sql generated for sort in admin changelist

http://code.djangoproject.com/ticket/2884 this ticket was opened 6 months ago with a patch, fixing a bug where a ProgrammingError is raised when sorting by a foreign key field which has an ordering clause that contains further foreign key fields. i ran into this bug when specifying a foreign

Re: Allowing multiple {% block %}s in one template

I'm -0 on this too, even though I have run into a situation where I wanted a block to appear twice in a base template, and the content of the block was defined in the view template (can't remember the details). The additional complication and strange rules are not worth the benefit (and I'm not

Re: PhoneNumberField

i'd like to see a single generic phone number field, and different methods attached to it that format it to the required formats. usa, international, including or excluding country code, using spaces or dashes, with or without leading zeroes, etc.

Re: signals

I use Any sender a fair bit (in a generic version control app), and I'd not like to see that disappear without considerable performance penalties if keeping it / considerable performance gains if removing it. --~--~-~--~~~---~--~~ You received this message

Re: International standard for date and time

+1 - it's a simple default settings change. django is used by an international community, so the defaults should be a format that is understood by everybody without any possibility of ambiguity. those that prefer a different format (american, or abbreviated or full length month names etc) can

Re: BooleanField and NullBooleanField (#2855 again)

I would have thought it's obvious. Any fields are are not null=True must have a default specified in the model or a value explicitly provided before calling save(). However, I just did a quick double- take and it looks like CharField actually has an implicit default of "" already. If CharField

Re: Documentation should never show non-working examples. - was: "@cache_page" bug...

imo, the official documentation should not document bugs, and should also not provide non-working examples. therefore either the bug should be fixed immediately, or the example should be removed immediately (to be re-instated when the bug is fixed). it is true that many bugs remain in trunk for a

Re: Small concern in newforms-admin

indeed, many people prefer to login with their email address, or use their email address as their username. that way they're not likely to forget it, and can use the same one which is guaranteed not to be in use by anyone else across all their sites. rather than having to remember multiple

Re: please help! need to know python version

as long as django doesn't *require* a version of python that is not on your approved list and therefore cannot run, you shouldn't have any problems. django is built to work on python 2.3, just because it is also compatible with 2.4 and 2.5 shouldn't mean anything. the fact that the code still

Re: Session based Messages

I've been using my own messages in sessions for a while now and every message i send is either "good", "bad", or neutral (neither good nor bad). these three states are very generic and cover every type of message i need to send. at present i display good messages in green, bad in red, and neutral

Re: Default application layout, project/app distinction and encouraging best practices

For each new site I work on I have a root folder which contains a copy of Django, other 3rd party libs I need, and a Django project for my site. I do this so I can upgrade or customise Django for each site individually without breaking other sites. I'll probably switch back to a common Django

  1   2   >