Neither will go away, `ValidationError(dict)` is used internally to carry
errors from the model layer to the form layer, and `add_error()` is used
internally to interpret the `ValidationError` raised throughout the system;
basically any `raise ValidationError` is followed by a call to `add_error
Hi Simon,
I've updated the ticket with a new PR, would you mind giving it a try?
Thanks
--
Loic
On Oct 13, 2014, at 1:27 PM, Simon Steinberger wrote:
> Excellent - thank you!
>
> On Friday, October 10, 2014 4:00:33 PM UTC+2, Karen Tracey wrote:
> There is a ticket open on this issue:
>
> h
Hi Daniel,
I'm a little confused because if I understand correctly you introduced the
concept of "data" field that you describe as "any field that has an entry on
the database", but how is that different from the earlier concept of "concrete"
fields.
For now FO, FK and O2O all fall under the "
+1
Thanks for the hard work you've put into this.
--
Loic
On Jul 23, 2014, at 8:29 PM, 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
>
On Jul 17, 2014, at 5:16 AM, Jeremy Dunck wrote:
> 1) returned whether the row was created or updated, e.g. if .save_base
> returned the `updated` value which it uses to send the .post_save signal.
> 2) raise something finer-grained than DatabaseError when force_update is
> used (so that I
+1, as_vendor() is IMO rather clean and expressive as a end user API.
3rd party backends are indeed a concern but we discussed this briefly on
IRC today and I believe we have an acceptable solution for them, Josh is
planning to write up about it.
--
Loic
On Monday, June 30, 2014 7:08:38 PM U
On Thursday, April 17, 2014 5:47:10 AM UTC+7, Josh Smeaton wrote:
>
> And for the last month or so a patch has existed and feedback has been
> requested. Performance was one of the concerns mentioned, so download
> Curtis' patch, and test that it works for your use case. He has asked for
> feedb
Curtis' branch is now a PR:
https://github.com/django/deps/pull/3
Feedback is welcome.
--
Loic
On Wednesday, April 16, 2014 11:17:58 AM UTC+7, Curtis Maloney wrote:
>
> Now taking input and feedback:
>
> https://github.com/funkybob/deps/blob/master/drafts/multiline_tags.rst
>
--
You received
On Wednesday, April 16, 2014 10:36:00 AM UTC+7, Adrian Holovaty wrote:
>
> Hey, may I suggest writing this up using our new DEP process? I don't mean
> to make people jump through hoops, but it would be useful for people like
> me who haven't been following the issue and don't want to wade throug
I'm +1 on this.
I do "forms in the templates" with a `{% field %}` templatetag that
controls labels, placeholders, help_texts, etc.; The lack of multilines
statements makes it rather painful.
It's interesting to note that Jinja2 supports this and we may be switching
to it as the default templa
If you look at the following example:
https://docs.djangoproject.com/en/1.4/topics/auth/#storing-additional-information-about-users
With `AUTH_PROFILE_MODULE = ’accounts.UserProfile’`: 'accounts' is a standard
application that you add to your INSTALLED_APPS setting, and just like any
other appl
On Jan 16, 2014, at 8:02 AM, Russell Keith-Magee
wrote:
> Is there some reason that you can't use get_form() for this? It would seem to
> be exactly what you are looking for - a way to control the instantiation of
> forms, used by both add_view and change_view.
ModelAdmin.get_form() is a bit
On Nov 17, 2013, at 2:02 AM, Anssi Kääriäinen wrote:
> - Reverse ForeignKey .remove() will not use .save() - it will use .update()
> - so no model save signals, and overridden model.save() is missed, too.
+1 on the pre/post_update signals as they can be useful for a variety of
purposes.
Al
On Aug 22, 2013, at 4:29 AM, Wim Feijen wrote:
> How about:
>
> form.add_errors(dictionary)
That's actually supported, although you need to nullify `field` explicitly:
`form.add_errors(None, dictionary)`.
It's mostly used internally; I'm not sure it's really useful to document, since
most li
> An alternate would be to implement a method that does this.
>
> def field_error(self, name, error):
> self._errors = self._errors or ErrorDict()
> self._errors.setdefault(name, ErrorList())
> self._errors[name].append(error)
I also have a pending PR for that: https://code.djangoproj
There is a ticket with a PR to address the issue of targeting specific fields
when raising errors; I'm awaiting feedback on what should be the documented API.
https://code.djangoproject.com/ticket/20867.
This patch enables two patterns:
- Raising ValidationError({'field': 'error'}) from `Form.c
On Aug 1, 2013, at 4:05 PM, Tom Evans wrote:
> qs = ...
> print len(qs)
> print qs[0]
> print qs[-1]
> print qs[0]
>
> How many queries for this?
Just one and "qs[-1]" will return the last element of the cached result.
I'm not trying to be pedantic, I'm just pointing out that a queryset become
In your example "print qs[0]" evaluates a *clone* of "qs", not "qs" itself.
Therefore "qs[0]; qs[-1]; qs[0]" triggers 3 queries, just like "qs[0]; qs[0];
qs[0]" would.
Now, if you really evaluate your "qs", for example by doing "list(qs)", then
further slicing/indexing on "qs" would operate on
+1
--
Loic
On Jul 25, 2013, at 7:29 PM, Aymeric Augustin
wrote:
> Hello,
>
> I'd like to deprecate admindocs. Here are my reasons:
>
> 1) It's called the "documentation generator", but it only operates on
> docstrings. This promotes the idea that docstrings are appropriate
> documentation
I thought of a third option that I think strikes the right balance between
convenience and flexibility.
Please see the following comment:
https://github.com/django/django/pull/1328#issuecomment-21400832
--
Loic
--
You received this message because you are subscribed to the Google Groups
"Dj
On Jul 23, 2013, at 3:17 AM, Aymeric Augustin
wrote:
> Either way the factory should receive the QuerySet in argument as well as any
> other parameters required to create the custom Manager appropriately.
I missed the "other parameters required" part.
Please note that this is only needed for
I'm not a big fan of TIMTOWTDI so I don't think we should have both
`Manager.from_queryset()` and `QuerySet.as_manager()`.
The following commit moved all the logic that was on `QuerySet` to the
`Manager` class and implemented the `from_queryset()` API:
https://github.com/loic/django/commit/
works well with inheritance.
--
Loic
On Jul 22, 2013, at 9:44 PM, Shai Berger wrote:
> On Monday 22 July 2013 13:25:38 Anssi Kääriäinen wrote:
>> On Monday, July 22, 2013 1:16:04 PM UTC+3, Loic Bistuer wrote:
>>> On Jul 22, 2013, at 4:38 PM, Chris Wilson
>>> >
>&
On Jul 22, 2013, at 4:38 PM, Chris Wilson wrote:
> I think that's very true. How about this?
>
>> class MyQuerySet(models.QuerySet):
>> def published(self):
>> return self.filter(published_date__lte=now())
>>
>> class MyModel(models.Model):
>> published_
äinen wrote:
> On Sunday, July 21, 2013 9:53:36 PM UTC+3, Loic Bistuer wrote:
> Explicit is better than implicit and `all()` is more a `Manager` concept than
> a `QuerySet` one.
>
> IMO `QuerySet.all()` should only be used when API parity with `Manager` is
> needed.
>
&g
have a public `clone()` method.
--
Loic
On Jul 22, 2013, at 1:25 AM, Rafał Stożek wrote:
> Can't we just use .all() in views instead of creating a new QuerySet method
> which does exactly the same thing?
>
>
> On Sun, Jul 21, 2013 at 12:34 PM, Loic Bistuer
> wrote
My attempt with a public `QuerySet.clone()` method and docs for
`*ObjectMixin.queryset`:
https://github.com/django/django/pull/1384
Made a PR to facilitate review and discussion, feel free to close if you think
it's the wrong approach.
--
Loic
--
You received this message because you are su
It's less efficient because of the extra table but that's pretty much the only
option when you need a FK on a model that you can't edit. GFK are not exactly
efficient either, yet most will agree that it's sometime the best option to a
given problem.
I agree that the distinction between FK and O
I totally agree that we can't have a field on one model that modifies the
underlying table of another model, especially with migrations in mind.
That said, I see value in a OneToManyField backed by a M2M with a unique
constraint on one side. This is particularly useful when you don't want to
mo
Sometime the answers can be a bit harsh and multiple people reply immediately,
which probably gives the impression of being scolded.
Maybe we could have a template with careful wording that we use every time.
We could also forward the message to django-users like a moderator would do on
a forum
> urlpatterns = patterns('',
> (r'/([^/]+)/$', Switcher.as_view(delegates=[...])),
> (r'/([^/]+)/([^/]+)/$', Switcher.as_view(delegates=[...])),
> (r'/([^/]+)/([^/]+)/([^/]+)/$', Switcher.as_view(delegates=[...]))
> )
I don't see this as an improvement because you s
+1 for me.
Having a catchall view under a single URL pattern is a tightly coupled system,
more so than allowing independent views to "test the water".
Django core relies on middleware hacks because the URL dispatcher is missing
this very feature. Having this in core would allow a cleaner implem
I run a custom DjangoTestSuiteRunner specifically to filter these out.
+1
--
Loic
On Mar 20, 2013, at 4:26 PM, Aymeric Augustin
wrote:
> - they won't be run by './manage.py test'
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To uns
This is more or less the idea behind
https://code.djangoproject.com/ticket/2 except that the custom
error_messages would be defined in ModelForm rather than Model. In my opinion,
Model is a terrible place to define user-facing strings such as help_text or
error_messages, at best useful to s
+1
This logic would be better in `ModelForm`.
--
Loic
On Mar 8, 2013, at 2:42 AM, Bruno Renié wrote:
> My proposal is to move that field customization API from the
> ModelAdmin class back to ModelForm:
--
You received this message because you are subscribed to the Google Groups
"Django dev
35 matches
Mail list logo
