At HTML level, a form is a set of fields that gets submitted when
a the form submit button is pressed.
However, this is not the case with model forms and inline formsets
(e.g. an admin page with inlines) -- inline formsets are
disparate from the model form.
This creates at least two problems:
1)
Wishful thinking follows.
It would be awesome if one could mix ordinary QuerySet methods
with raw() (or, rather, raw_extra(), see below for that).
Assuming the following models:
class Foo(models.Model):
name = models.CharField(max_length=255)
class FooDates(models.Model):
foo = models.
On Oct 2, 5:42 pm, "Sean O'Connor" wrote:
> To be honest this seems like something which would be a lot of work with
> relatively little gain. For this to work raw() would need to change from a
> relatively simple bit of code which doesn't need to touch all of the complex
> query code in the ORM
On Oct 2, 7:35 pm, mrts wrote:
> But let me stop right here.
Contradicting myself, I've pursued this further and
implemented raw_override() for order_by in [1] as a proof of
concept. See [2] for what's different and tests [3] for
usage.
I'd say that for order_by, the implem
Many core developers and the GSOC folks use GitHub for
Django development, so I hope discussing the best
practices is appropriate for django-dev.
Let me outline the desired workflow, please amend and
correct as you see fit as there are probably errors or
omissions. I expect various useful pattern
There's http://code.djangoproject.com/wiki/CollaborateOnGithub
that I wrote some time ago, but it doesn't give guidelines for
branchy development.
I will update that page with these instructions, but it would be
excellent if others who have collaborated more intensively via
GitHub could amend the
On Oct 5, 7:08 pm, mrts wrote:
> There'shttp://code.djangoproject.com/wiki/CollaborateOnGithub
> I will update that page with these instructions,
Done. Any comments and amendments should probably go to the wiki page
now.
Best,
MS
--~--~-~--~~~---~-
Let me suggest that there are many who have at
times felt frustrated how contributions or
suggestions are managed in Django. Some of them
seem to have walked away or just don't participate
in discussions any longer. The same applies to
several other large open source projects, the
Linux kernel and
(Inspired by Yuri Baburov's criticism and RKM's response.)
--~--~-~--~~~---~--~~
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 unsubscr
Jacob, I'm afraid you totally misunderstood me.
My message was intended to encourage people to
scratch their own itches more now that it's so
much easier -- and, of course, give back --
instead of grumbling on the mailing list.
I fail to see how can "so it's time to put the
grudges behind and hap
On Oct 20, 7:19 pm, Jacob Kaplan-Moss wrote:
> What's frustrating, though, is hearing that you have a
> problem with our workflow without any concrete suggestions
> to improve it or offers of assistance. There's a general
> theme underlying most of this "angst" (as you call it):
> the tone implie
On Oct 22, 3:36 am, Russell Keith-Magee
wrote:
> On the other hand, saying "I am going to" is extraordinarily helpful.
> Saying "I already have" is even better. You don't need the core's
> blessing to do anything.
Yes, I wholeheartedly agree and that was the point of my initial
message.
> Allow
> Another benefit of a merge-queue branch is testing and verifying that
> multiple patches play well together before actually hitting trunk.
> For multiple big branches this is even more important.
Currently blocking on
http://support.github.com/discussions/feature-requests/560-two-forks-of-a-sin
On Oct 29, 4:50 pm, Russell Keith-Magee
wrote:
> Django's dependence on DJANGO_SETTINGS_MODULE is an oft-lamented
> problem. Suggestions on how to address this constraint are most
> welcome.
With an explicit main (i.e. a single explicit entry point to code).
Would also fix the "where can I initi
On Oct 28, 9:43 am, John Debs wrote:
> I've written a creaky hack to work around the issue in my own projects
> but after seeing this thread I'm going to take a shot at implementing
> FormSetField (or something like it) myself. If anyone has any code -
> or more arguments for or against that have
Great news! Have you discussed the workflow yet?
I.e. will a DVCS be involved, and if yes, will there be
a central repo for coordinating the effort?
A special repo on Github would otherwise be perfect,
but as mentioned before, we have a problem with re-forking:
http://support.github.com/discussio
On Nov 11, 1:57 pm, Russell Keith-Magee
wrote:
> Also - I know you're very enthused about Git and GitHub, but Django
> uses SVN as the canonical store for trunk and branches, and this isn't
> likely to change in the near future.
Thank you, but no, I'm not enthused about git and GitHub per
se :)
On Dec 8, 5:32 am, Russell Keith-Magee wrote:
> On Tue, Dec 8, 2009 at 11:11 AM, Tobias McNulty
> wrote:
> > On Mon, Dec 7, 2009 at 6:31 PM, Russell Keith-Magee
> > wrote:
> >> I was thinking more of having one person at the sprint to take the
> >> role of integrator - that is, the patches stil
> On Tue, Dec 8, 2009 at 12:35 PM, Jeremy Dunck wrote:
> > Sorry to hear that. The document you linked is a start, but I'm a bit
> > concerned by this goal:
> > "to keep the main integration branch as stable as the official trunk
> > so that it can be used in actual deployments"
>
> > My concern
Malcolm had some good comments when all of this was discussed
previously:
http://groups.google.com/group/django-developers/browse_thread/thread/436307e426844ae0/f2fa0647b97569ad
He also seemed to have further ideas and code, perhaps he can be
pinged for sharing them.
Best,
MS
--
You received t
On Jan 20, 5:59 am, David Cramer wrote:
> The first three have been huges ones with us. We're just now running
> into the settings issue, but would love to see what people can come up
> with for solutions (we dont have a good one).
The override_settings() idea that Eric Florenzano describes at
ht
On Feb 10, 5:24 pm, Tom Evans wrote:
> On Wed, Feb 10, 2010 at 3:09 PM, Jari Pennanen
> wrote:
> > Hi!
>
> > I was wondering what is the status of branch branches/soc2009/http-
> > wsgi-improvements
> > (http://github.com/django/django/tree/soc2009/http-wsgi-improvements
> > )? I'm personally
On Mar 1, 5:27 pm, Jacob Kaplan-Moss wrote:
> Also, a step 2.5, if you'd like, would be to write a tiny app on pypi
> that enabled the use of pylibmc via an external cache backend. We
> could point to it in the deprecation notes when we explain why
> cmemcache is being deprecated.
See http://gist
James has replaced the content of
http://code.djangoproject.com/wiki/DjangoSpecifications/Core/Threading
with the following disclaimer:
"This page and several others were created by a
wiki user who was not and is not a member of the
Django core team. Previous contents of this and
other similar p
On Apr 7, 6:21 pm, Russell Keith-Magee wrote:
> James spoke with me about this decision at the time, and I completely
> agree with and endorse his actions.
So be it then.
> While it is true that wikis contain all sorts of information, often
> unofficial, the naming of the wiki pages in question
Please give you thougths on the following.
* contrib.localflavor should be deprecated and transferred to a
separate project or contributed to Babel.
It is incomplete by nature as covering all regions/postal codes in
the world takes a lot of effort.
That effort is out of Django's scope.
Could someone of the core devs give his opinion on this?
--~--~-~--~~~---~--~~
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 unsubscrib
I'd like to bring up trac milestones again.
Currently Django has over 1000 active tickets. Some of them are
relevant to oldforms-admin, some are from pre-qsrf merge, some are
features for 1.1. But quite a few are small bugs that should be fixed
before 1.0.
Putting up milestones in trac would spa
Please see
http://code.djangoproject.com/ticket/3591
http://code.djangoproject.com/wiki/DjangoSpecifications/NfAdmin/FlexibleAppHandling
http://code.djangoproject.com/wiki/InstalledAppsRevision
Will
http://code.djangoproject.com/wiki/DjangoSpecifications/NfAdmin/FlexibleAppHandling
do what you
On Jun 20, 12:47 am, Ben Firshman <[EMAIL PROTECTED]> wrote:
> I'm still in exams unfortunately, so this will be brief, but I'd like
> to hear some thoughts.
>
> Imagine a small site without a great deal of traffic or data, and they
> wish to add search support for a model. Lucene or Xapian ar
I'd like to get some feedback for the following major tickets
regarding sessions, all of which are in scope for 1.0.
1) Session key collisions: http://code.djangoproject.com/ticket/1180
Due to the birthday paradox, sqrt(n) is roughly the number you need to
have a 50% collision chance when pickin
On Jul 7, 5:00 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote:
> On Mon, Jul 7, 2008 at 8:48 AM, mrts <[EMAIL PROTECTED]> wrote:
> > I'd like to get some feedback for the following major tickets
> > regarding sessions, all of which are in scope for
> > Due to the birthday paradox, sqrt(n) is roughly the number you need to
> > have a 50% collision chance when picking items at random from an
> > inexhaustible set of n items. (0, sys.maxint - 1) is currently the
> > random range. On 32-bit platforms the collision bound is thus quite
> > low as
On Jul 7, 6:32 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
>
> That comment has no bearing.
>
> (1) We pick a random session key.
> (2) We save it to the database, where it should be unique, otherwise an
> error is raised.
> (3) We use that session key to pass back to the user.
>
> At this
Thus, looks there are two problems -- collisions happen too often on
32-bit machines (fixed by my patch) and db session backend doesn't
handle them properly (no fix so far).
As for the latter -- Malcolm, you were about to add a clear
distinction between INSERT and UPDATE to .save() in
http://grou
On Jul 8, 5:27 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> Increasing
> some value from 32 bits to 64 bits is only changing some probabilities;
> it's not actually solving the problem, just moving the goalposts to make
> it harder to score an own goal. The rest of the conversation should
>
I reviewed threading in Django and found a few problems, one of which
is serialization.
See
http://code.djangoproject.com/wiki/DjangoSpecifications/Core/Threading#Problems
.
Fix was contributed to the most eminent one in #6950, but I never got
to fixing serialization.
The fix is easy though, jus
tch? Where is "#FIXME:" ? ;)
>
> On 8 Лип, 16:07, mrts <[EMAIL PROTECTED]> wrote:
>
> > I reviewed threading in Django and found a few problems, one of which
> > is serialization.
> > Seehttp://code.djangoproject.com/wiki/DjangoSpecifications/Core/Thread
> Yes, the tests run on Windows now as well. Only problem is two tests with
> file paths in their output, the forward slashes are backslashes on Windows
> so the output doesn't match what the tests are looking for:
>
> http://dpaste.com/61364/
>
> Not sure if/how you ordinarily get around that in
I'm using http://babel.edgewall.org/ exactly for that purpose. Works
extremely well. There are even some Django-specific extensions at
http://babel.edgewall.org/wiki/BabelDjango (I don't use them though).
On Aug 18, 4:48 pm, Joost Cassee <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> A Farsi-localized
It is quite common to be hit by the insufficiently verbose reporting
that #8221 and #7524 fix -- e.g. see the duplicates that have popped
up.
As I already said, #8221 is only needed because the patch I provided
in #8177 and that got commited fixed only the most burning issue I was
directly hit wi
http://code.djangoproject.com/ticket/7524 is tagged as post-1.0.
http://code.djangoproject.com/ticket/8221 was closed as duplicate of
#7524, which it is not.
On Aug 23, 9:40 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Sat, 2008-08-23 at 10:46 -0700, mrts wrote:
>
>
On Aug 24, 4:40 am, "James Bennett" <[EMAIL PROTECTED]> wrote:
> On Sat, Aug 23, 2008 at 2:43 PM, mrts <[EMAIL PROTECTED]> wrote:
> >http://code.djangoproject.com/ticket/8221 was closed as duplicate of
> > #7524, which it is not.
>
> In triaging, I&#x
I am mrts (Mart Sõmermaa).
The page was created and updated by me and I'm quite certain the
anonymous updates are also mainly by me. So I am entirely to blame for
the confusing naming and for any incorrect information. But I do hope
that the information is mostly correct and relevant, it is
Hopefully the devs are taking a well-deserved break now as 1.0 is
out :)
Once back online, a bit of release planning + corresponding new
milestones in Trac would come in handy for ticket triagers to
categorize tickets.
I'd propose something in the lines of the following (and I'd really
prefer no
This is for Django 2.0.
Rationale:
a) useful (and less-useful) Django apps are proliferating on Google
Code, djangoplugables.com and Django resources wiki page,
b) apps need refactoring (#3591,
http://code.djangoproject.com/wiki/VersionOneFeatures#INSTALLED_APPSrefactoring
)
c) reusable apps
On Sep 10, 6:57 pm, "James Bennett" <[EMAIL PROTECTED]> wrote:
> Have I made my point clear enough yet?
Your point is clear but is likely to bring less order to the current
chaos. And it doesn't handle project-local installation (arguably this
can be done with virtualenv, but that will just clutt
On Sep 10, 7:12 pm, "Eric Holscher" <[EMAIL PROTECTED]> wrote:
> your django apps. There is no reason to reinvent the wheel here, especially
> after what Mark talked about at Djangocon (Django being considered seperate
> from the Python community).
Although I don't know anything about the talk, t
On Sep 10, 8:00 pm, Steve Holden <[EMAIL PROTECTED]> wrote:
> I don't see why Django can't be just as much a part of the Python
> community as, say, Zope, who frequently distribute code through PyPi. I
> don't see the advantage of fragmenting the infrastructure. That's what
> it's there for - supp
10, 9:00 pm, "Brett Hoerner" <[EMAIL PROTECTED]> wrote:
> On Wed, Sep 10, 2008 at 11:20 AM, mrts <[EMAIL PROTECTED]> wrote:
> > And it doesn't handle project-local installation (arguably this
> > can be done with virtualenv, but that will just clutter user-sp
On Sep 16, 2:10 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Tue, 2008-09-16 at 00:16 -0700, mrts wrote:
> > Let me try to wrap this up:
>
> > * there seems to be a general consensus that amending setuptools to
> > create Django-specific extensions is
I just copy-pasted the app objects requirement as listed and discussed
in http://code.djangoproject.com/wiki/InstalledAppsRevision . I
personally have no use case for it.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
On Sep 17, 11:13 am, mrts <[EMAIL PROTECTED]> wrote:
> I just copy-pasted the app objects requirement as listed and discussed
> inhttp://code.djangoproject.com/wiki/InstalledAppsRevision. I
> personally have no use case for it.
Doh, that should have been *multiple* ap
On Sep 18, 2:56 am, zvoase <[EMAIL PROTECTED]> wrote:
> I think the app object thing is a really good idea, but I have to say
> one thing; why not see if some middle ground can be met between the
> Django cheeseshop idea (going on in another thread in this group) and
> this.
That's the point. B
On Jul 4, 2:26 am, Tai Lee <[EMAIL PROTECTED]> wrote:
> > The only thing that might be worth doing in this are is adding a way to
> > say "middleware should never be called on this response" and then
> > somebody can write their own HttpResponse subclass and be in complete
> > control of their des
On Jul 1, 1:02 pm, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> I've implemented iterable HttpResponse
> in the first place out of purely practical reason: web server times out
> if a particularly long file was passed into an HttpResponse. And also it
> was really slow and was consuming all the memo
Hi Honza, thank you for your work on model validation!
What's the status? Getting model validation in (if the powers that be
agree) would help to fix a couple of annoying bugs listed below that
are present in 1.0.
http://code.djangoproject.com/ticket/9039
http://code.djangoproject.com/ticket/888
mrts wrote:
> Looking at the path Honza has taken [1], it looks that it both
And the missing reference is
[1] http://code.djangoproject.com/ticket/6845
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
&quo
Looking at the path Honza has taken [1], it looks that it both
complicates things and causes overhead -- for every constraint on
an model object, an extra db call for checking it is made,
instead of relying on the constraint checks enforced by the db
backend and corresponding exceptions during `sa
On Oct 6, 2:03 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Sun, 2008-10-05 at 14:11 -0700, mrts wrote:
> > Looking at the path Honza has taken [1], it looks that it both
> > complicates things and causes overhead -- for every constraint on
> > an model o
On Oct 7, 12:08 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Mon, 2008-10-06 at 15:27 -0700, mrts wrote:
> resolution on updates. The multiple simultaneous writes to the exact
> same piece of data is only one corner of the full domain space. We plan
> for the worst,
In context of the Django community apps and app object discussions we
had some time ago, there's a sprint upcoming tomorrow:
http://mail.python.org/pipermail/python-dev/2008-October/082971.html
http://www.openplans.org/projects/plone-conference-2008-dc/distribute
This is a good occasion to speak
It seems that current DB lock management doesn't play nice with the
new Python 2.6 multiprocessing package and SQLite. See [1]. The same
error also popped up in Google search under mod_python [2].
I wasn't able to reproduce this with MySQL.
[1] http://code.djangoproject.com/ticket/9409
[2]
http
On Oct 27, 5:16 pm, Brian Beck <[EMAIL PROTECTED]> wrote:
>
> As others have pointed out, this isn't an issue with Django. The
> easiest solution is to make this error less common with a higher
> timeout. In settings.py:
>
> DATABASE_OPTIONS = {'timeout': 30}
Thanks Brian, increasing the timeou
On Oct 27, 6:57 pm, mrts <[EMAIL PROTECTED]> wrote:
> On Oct 27, 5:16 pm, Brian Beck <[EMAIL PROTECTED]> wrote:
> > As others have pointed out, this isn't an issue with Django. The
> > easiest solution is to make this error less common with a hig
There has been much reluctancy in letting triagers tag and prioritize
1.0.1 milestone tickets. Now that 1.0.1 is really close, can we
perhaps discuss what are the things that really should be fixed before
it is released?
The only major issue I have encountered is
http://code.djangoproject.com/ti
Shouldn't we have a string freeze before the 1.0.1 release (e.g. both
#8882 and #9493 bring in new error strings)?
Otherwise translators have to either continuously update the
translations as new strings land or accept that 1.0.1 is released
without complete translations.
--~--~-~--~~
On Oct 31, 5:19 pm, "Joey Wilhelm" <[EMAIL PROTECTED]> wrote:
> I would like to suggest the following:
> http://code.djangoproject.com/ticket/9245
> http://code.djangoproject.com/ticket/6710
>
> They both have fully functional patches... although granted the second has
> no tests.
IMHO http://cod
On Nov 4, 2:33 am, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> Yes, there is a reason, and it has been given several times in recent
> history. The v1.0.1 milestone has not bee created in Trac because it
> will not in any way help us deliver the v1.0.1 release. There is no
> difference betw
On Nov 5, 1:35 am, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> On Tue, Nov 4, 2008 at 11:04 PM, mrts <[EMAIL PROTECTED]> wrote:
>
> > Most other projects are managed by a priority queue and clear target
> > set for releases ("this has to go in
On Nov 5, 2:31 pm, mrts <[EMAIL PROTECTED]> wrote:
> little by a) milestones: assuring that there is a known date when a
> given ticket will be looked at
Let me clarify a little: "looked at" doesn't necessarily mean
"integrated", it may be deferred to the nex
On Nov 17, 6:54 pm, Ludvig Ericson <[EMAIL PROTECTED]> wrote:
> On Nov 16, 2008, at 07:26, Chris wrote:
>
> > 3. Fear of multi-threading bugs shouldn't be a reason to avoid multi-
> > threading, especially when it could be very useful. We don't even know
> > if there are multi-threading bugs. And
Currently, "the first manager declared is the default manager".
However, given the following hierarchy:
---
class PublishedObjectManager(models.Manager):
def get_query_set(self):
return super(PublishedObjectManager, self).get_query_set()\
.filter(is_published=True)
c
http://code.djangoproject.com/ticket/9676 created to track this.
--~--~-~--~~~---~--~~
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 un
On Nov 26, 3:20 am, Julien Phalip <[EMAIL PROTECTED]> wrote:
> On Nov 26, 11:43 am, "Russell Keith-Magee" <[EMAIL PROTECTED]>
> wrote:
>
>
> > On Wed, Nov 26, 2008 at 2:08 AM, Jacob Kaplan-Moss
>
> > <[EMAIL PROTECTED]> wrote:
>
> > > Hi folks --
>
> > > I'd like to officially drop Python 2.3 supp
On Aug 11, 9:11 pm, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I'd write more but I'll first wait for responses, file some tickets,
> and think about what else Django could do to improve its cooperation
> with App Engine... because Django is App Engine's favorite framework!
Shouldn't easier in
See also http://code.djangoproject.com/ticket/9676
On Dec 15, 12:51 pm, "Alex Rades" wrote:
> Hi,
> my understanding about custom managers is that if you want to define a
> custom manager, you also HAVE to remember to define the "objects"
> manager first, otherwise some parts of django (eg. admi
As the list seems to be resuming from holiday hibernation, I risk
causing another "don't you dare to push us" flame-bombing :) by
proposing that the following get looked at before 1.1:
* `__import__(mod, {}, {}, [''])` causes double import of modules [1]
After discussions on python-dev, an idiom
On Jan 7, 3:43 am, Malcolm Tredinnick
wrote:
> On Tue, 2009-01-06 at 15:38 -0800, Killarny wrote:
> > There are many instances where, in a complicated implementation of
> > views, one might want to have a combination of required args and
> > optional kwargs, and the inability to mix them introduc
upon
him/herself OR someone opposes this). I've created a fork of the
unofficial git mirror for that purpose at
http://github.com/mrts/django/tree/master
. Everybody is most welcome to contribute.
By semi-champion I mean that I'll contribute as much as I can beside
daily job tasks by di
On Jan 7, 9:59 pm, "Alex Gaynor" wrote:
> 1.1 is not 8 days away, the 1.1 major feature freeze, this means items that
> are new features on the 1.1 features list.
/me puts on a brown paper bag. Right, feature freeze and bug fixing
are different things.
Can we perhaps agree on a set time when pe
A proper "agile" workflow for distributed collaboration on a largeish
chunk of functionality should be as follows:
Feature developer:
* implement tests for the features to be added
* commit locally
* implement the features
* commit locally
* run the test suite iteratively, fixing whatever the tes
On Jan 12, 3:45 pm, "Jacob Kaplan-Moss"
wrote:
> On Mon, Jan 12, 2009 at 6:53 AM, mrts wrote:
> > What if we try to be nice to ourselves and get #8138 and something in
> > the lines ofhttp://oebfare.com/blog/2008/mar/25/faster-django-test-suite/
> > into trun
Great thanks and praises to everybody involved!
Getting down from 1346 to 204 seconds is such a relief...
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email t
Feeling that an overview of the "GitHub process" would help people to
get more easily involved, I created
http://code.djangoproject.com/wiki/CollaborateOnGithub
.
Opinions, criticisms and edits most welcome.
--~--~-~--~~~---~--~~
You received this message because
There are several problems in model validation as of now. As pouring
them out here would create a too long, ill-formatted post, I created a
separate page for it at
http://wiki.github.com/mrts/honza-django/form-and-model-validation
This is just "design gruntwork", a basic text body ana
odel fields' to_python
to a separate django.utils.typeconverters library
(see
http://github.com/mrts/honza-django/commit/a8239b063591acc367add0a01785181a91a37971
for the first steps in that direction) and using both
django.core.validators and django.utils.typeconverters throughout
model and form fields.
I
out converters from things that work with standard types. But
> definitely try to keep them close together in the source, rather than
> putting them in django.utils, which can sometimes be a dumping ground
> for stuff that better belongs elsewhere.
As seen in the commit,
http://github.com/m
On Jan 19, 11:23 pm, mrts wrote:
> The directory-based approach is best, I'll go with it -- but it's yet
> uncertain
> when as I have to handle pressing matters at work during daytime.
I've implemented some fundamental changes that need review. The commit
is at
http
On Jan 23, 3:40 am, Malcolm Tredinnick
wrote:
> On Thu, 2009-01-22 at 17:27 -0800, mrts wrote:
>
> []
>
> > A
> > side note: the `instance` attribute is not used in validator functions
> > and I can't see a clear use case for it, so it looks like it c
As the uniform all values approach has created a bit of confusion, let
me present a larger example:
Validators in core.validators should not be concerned with either
model or form internals if possible. This is currently straightforward
to achieve by passing all values always as a dict via
form.c
After discussing with Honza, we agreed that the dichotomy between
forms and models that was present before will remain, i.e. instance
will always be a model instance if given and all_values will always be
form.cleaned_data.
Honza's rationale was that it's common to have properties in models
and t
On Jan 23, 4:38 pm, Marty Alchin wrote:
> I haven't been following everything, but I do have a couple comments
> to make here.
Thanks, interesting points. The get_value approach looks simpler
though, so unless you or anybody else disagrees I'll implement this.
--~--~-~--~~---
After several discussions with Honza, we are still on somewhat
different positions what the validator function signature should
be and how core validators should access the fields of a form or
a model instance.
In core validators, no special case handling of forms and models
is needed even in mul
Whenever the app objects discussion is resuscitated, the following by
yours truly may be of relevance:
http://github.com/mrts/plugit/tree/master
As of now, settings handling is present. The SettingsUpdater class in
plugit/settingshandler.py provides a high-level API for updating
configuration
The last unsolved model-validation design issue is the error message
protocol (my work on fields is waiting on it). Let me present the
approach that looks sane to me.
The old Field.default_error_messages dict and corresponding
logic is no longer required (and removed in my branch) as default
erro
On Feb 18, 2:28 pm, mrts wrote:
> def validate(self, value, all_values={}, form_instance=None):
That should have been
def validate(self, value, all_values={}):
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Gro
On Feb 18, 8:03 pm, Honza Král wrote:
> Hi,
> see inline text.
>
> On Wed, Feb 18, 2009 at 1:28 PM, mrts wrote:
>
> > The last unsolved model-validation design issue is the error message
> > protocol (my work on fields is waiting on it). Let me present the
> &g
On Feb 19, 12:49 am, Malcolm Tredinnick
wrote:
> On Wed, 2009-02-18 at 04:28 -0800, mrts wrote:
> > The old Field.default_error_messages dict and corresponding
> > logic is no longer required (and removed in my branch) as default
> > error messages live in core/validators n
Jacob,
thanks for the great work on Trac cleanup! This makes the devs
intentions and goals so much more transparent. I especially like that
we have a somewhat official ticket-set-based roadmap now (http://
code.djangoproject.com/roadmap ) instead of the manual one (http://
code.djangoproject.com/
1 - 100 of 147 matches
Mail list logo
