I am quite interested in this, as most of my coding work has been
developing APIs that get consumed by non-web-browser software.
Lately, I've taken the approach that a Form is the appropriate tool to use
for (de)serialisation: it's already used extensively by the template
rendering (which is in
On Mon, Apr 2, 2012 at 11:04 PM, Donald Stufft wrote:
> Identity doesn't have anything to do with automatically dispatching
> users. All it is is a unique identifier. That's all this proposal honestly
> enforces that your users have. Some single piece of identifiable data that
> can be used to di
On Monday, April 2, 2012 at 10:56 PM, Alex Ogier wrote:
> I realize that arguing with a BDFL might get me nowhere, but I don't think
> that multi-profile + select_related + proxy attributes on the user model is
> the proper approach for users going forward. The proposal makes some basic
> sense
On 03/04/2012, at 8:35 AM, Jacob Kaplan-Moss wrote:
> Hi folks --
>
> I've written up a proposal for how *I* would like to address refactoring
> auth.user: https://gist.github.com/2245327.
>
> In essence, this does two things:
>
> * Vastly "prunes" the required fields on auth.user. The only t
On 04/02/2012 06:35 PM, Jacob Kaplan-Moss wrote:
> I've written up a proposal for how *I* would like to address refactoring
> auth.user: https://gist.github.com/2245327.
+1 from me.
One minorish nit: I think that "in the face of ambiguity, refuse the
temptation to guess" should apply equally to r
I realize that arguing with a BDFL might get me nowhere, but I don't think
that multi-profile + select_related + proxy attributes on the user model is
the proper approach for users going forward. The proposal makes some basic
sense as an incremental improvement on the current status quo of a built-
If we use __unicode__ (which i'm fine with) then it needs to follow the same
resolution path as user.data[] does.
On Monday, April 2, 2012 at 9:25 PM, Anssi Kääriäinen wrote:
> On Apr 3, 4:20 am, Donald Stufft http://gmail.com)>
> wrote:
> > If i recall on IRC the decider was to just create
On Apr 3, 4:20 am, Donald Stufft wrote:
> If i recall on IRC the decider was to just create a display field (e.g.
> user.data["display"]) that the default profiles can provide (and can be
> overridden by other profiles of course).
My problem with this is that for example where I work the displa
If i recall on IRC the decider was to just create a display field (e.g.
user.data["display"]) that the default profiles can provide (and can be
overridden by other profiles of course).
On Monday, April 2, 2012 at 9:17 PM, Anssi Kääriäinen wrote:
> On Apr 3, 3:35 am, Jacob Kaplan-Moss (http:
On Apr 3, 3:35 am, Jacob Kaplan-Moss wrote:
> Hi folks --
>
> I've written up a proposal for how *I* would like to address refactoring
> auth.user:https://gist.github.com/2245327.
>
> In essence, this does two things:
>
> * Vastly "prunes" the required fields on auth.user. The only things left ar
On 03/04/2012, at 5:06 AM, j4nu5 wrote:
> Hi Russell,
>
> Thanks for the prompt reply.
>
> * You aren't ever going to eat your own dogfood. You're spending the GSoC
> building an API that is intended for use with schema migration, but you're
> explicitly not looking at any part of the migrat
Hi folks --
I've written up a proposal for how *I* would like to address refactoring
auth.user: https://gist.github.com/2245327.
In essence, this does two things:
* Vastly "prunes" the required fields on auth.user. The only things left are an
"identifier" (which could be username, email, url,
Thanks,
I did look at it, it was the import of the Manager for the other shortcuts that
was causing the issue. I'll try and file a bug for this.
Paul
On Apr 2, 2012, at 12:42 PM, Carl Meyer wrote:
> On 04/02/2012 09:35 AM, Optimus Paul wrote:
>> I've been running Django for quite a while with
On 04/02/2012 09:35 AM, Optimus Paul wrote:
> I've been running Django for quite a while without a "database", we
> use MongoDB, and it has worked well for us. We upgraded to 1.4 and
> found that suddenly a default database is required. Is there a reason
> for this? Or is this a bug?
Preston ha
On Monday, April 2, 2012 8:35:28 AM UTC-7, Optimus Paul wrote:
>
> I've been running Django for quite a while without a "database", we
> use MongoDB, and it has worked well for us. We upgraded to 1.4 and
> found that suddenly a default database is required. Is there a reason
> for this? Or
It's my second approach to customizable serialization. I did some
research, find some REST serializers. I focus more on deserialization -
it should be easy to provide data is round-trippable. I discard some
unnecessary fields and try to improve functionality.
GSOC 2012 Customizable s
I've been running Django for quite a while without a "database", we
use MongoDB, and it has worked well for us. We upgraded to 1.4 and
found that suddenly a default database is required. Is there a reason
for this? Or is this a bug?
We get the error when importing django.shortcuts.render_to_re
Please ask questions about using Django in django-users. The topic of
this list is the development of Django itself.
Karen
--
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.
Hi all,
I am using Django admin interface for data entry and
permissions. I have a requirement like after adding a new row in the
table i need to call a function which does something else with the
inserted data. Does the admin interface has any option where i can
pass something like the ca
19 matches
Mail list logo
