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) an
On Thu, Jan 12, 2012 at 1:02 AM, Tai Lee wrote:
> Donald,
>
> Thanks for sharing your feedback with everyone.
>
> I do believe that there should be some kind of validation error or at
> least a loud warning to the console or logs when a form is bound to
> incomplete data. The only time when this
Donald
Backward compatibility can be maintained with just a log warning to give
developer time to clean up code or throwing an exception when
`settings.DEBUG=True` and only log warning when `False`; I am not sure how
this ought to be implemented but again I am big +1 for this proposal.
On Thu, Ja
On Jan 12, 2:24 pm, Zachary Voase wrote:
> I strongly feel that switching around managers like that would be an
> example of overengineering.
I tend to over-engineer things. It is easy to add the manager
switching later on if needed. And it is easy to switch managers by
just changing qs.manager i
On 01/12/2012 07:24 AM, Zachary Voase wrote:
I strongly feel that switching around managers like that would be an
example of overengineering.
The user story which drove this RFC was based on an issue which has
been encountered by lots of developers, but typically solved in a
single way. Django's
I strongly feel that switching around managers like that would be an
example of overengineering.
The user story which drove this RFC was based on an issue which has
been encountered by lots of developers, but typically solved in a
single way. Django's conservative style of development is very
acco
Donald,
Thanks for sharing your feedback with everyone.
I do believe that there should be some kind of validation error or at
least a loud warning to the console or logs when a form is bound to
incomplete data. The only time when this should occur is for
"unsuccessful controls" such as unchecked
All right. Thank for your reply. The thing I love about django is that
is compactness. You simply do need no other libraries when you build
web app. As opposite from java where you must use hundred of
frameworks to build up a web app. My idea was to integrate a stuff
needed for RPC into django to a
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 pr
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 Broadcas
10 matches
Mail list logo
