Re: Draft branch: Swappable User models in contrib.auth

Hi, On Wednesday, June 6, 2012 4:32:02 PM UTC+2, Anssi Kääriäinen wrote: > > Still, yet another API idea: [snip] > > Then, Model.__new__ will replace the SwappableUser class with the > swapped in class. The 'swappable' in model.Meta tells which concrete > model implementation to use. > I'd r

Re: Draft branch: Swappable User models in contrib.auth

On Jun 7, 11:57 am, Florian Apolloner wrote: > Hi, > > On Wednesday, June 6, 2012 4:32:02 PM UTC+2, Anssi Kääriäinen wrote: > > > Still, yet another API idea: [snip] > > Then, Model.__new__ will replace the SwappableUser class with the > > > swapped in class. The 'swappable' in model.Meta tells wh

Re: Will django escaping ever consider context of javascript and CSS?

On 03/05/12 17:49, Voulnet wrote: > The document you linked says it doesn't make it safe to use, but rather > helps in fixing syntax errors. > > " escapejs > > Escapes characters for use in JavaScript strings. This does not make the > string safe for use in HTML, but does protect you from syntax

Re: startproject template context

On 01/05/12 22:58, Ramiro Morales wrote: > On Tue, May 1, 2012 at 11:04 AM, Sam Simmons wrote: >> For app/project templates I found the docs a little misleading when they say >> 'Any option passed to the startapp command' will be added to the context. > > You' ve understood the documentation corr

Re: Django git guidelines

On 6 juin 2012, at 21:09, Anssi Kääriäinen wrote: > I am sure there is still a lot to polish. I might have tried to change > too big portion of the docs in one go. Still, I would like to commit > what I have tomorrow, so that the sprinters at djangocon have the > possibility to use the guidelines a

Proposed Field API additions

Hi everyone, As part of my planning for adding schema alteration/migrations into Django proper, I need to make a few changes to Fields to allow for better serialisation of model definitions (pretty much a requirement for any change-detecting migrations system). In particular, I propose: - Requi

Re: Proposed Field API additions

On 7 June 2012 18:17, Andrew Godwin wrote: > This means either having to register custom fields (like admin classes, > for example), or requiring fields to live in a fields.py or fields > package (like models and models.py). This is to provide for a > less-fragile way of referring to them than the

Re: Proposed Field API additions

On Thu, Jun 7, 2012 at 12:17 PM, Andrew Godwin wrote: > Hi everyone, > > As part of my planning for adding schema alteration/migrations into > Django proper, I need to make a few changes to Fields to allow for > better serialisation of model definitions (pretty much a requirement for > any change

Re: Proposed Field API additions

2012/6/7 Andrew Ingram : > On 7 June 2012 18:17, Andrew Godwin wrote: >> This means either having to register custom fields (like admin classes, >> for example), or requiring fields to live in a fields.py or fields >> package (like models and models.py). This is to provide for a >> less-fragile wa

Re: Proposed Field API additions

On 07/06/12 20:14, Alex Gaynor wrote: > > > On Thu, Jun 7, 2012 at 12:17 PM, Andrew Godwin > wrote: > > > In particular, I propose: > > - Requiring that all fields expose a method which says how to > reconstruct them. > > Essentially, it returns the pos

Re: Proposed Field API additions

On Jun 7, 8:17 pm, Andrew Godwin wrote: > Hi everyone, > > As part of my planning for adding schema alteration/migrations into > Django proper, I need to make a few changes to Fields to allow for > better serialisation of model definitions (pretty much a requirement for > any change-detecting migr

Re: Proposed Field API additions

On Thu, Jun 7, 2012 at 3:56 PM, Anssi Kääriäinen wrote: > On Jun 7, 8:17 pm, Andrew Godwin wrote: >> Hi everyone, >> >> As part of my planning for adding schema alteration/migrations into >> Django proper, I need to make a few changes to Fields to allow for >> better serialisation of model defini

Re: Proposed Field API additions

On Jun 7, 11:16 pm, Alex Ogier wrote: > This isn't particularly robust. The SQL string generated by a > particular backend isn't considered part of any API, and might change > formatting or semantics on minor updates. Some SQL is quite > complicated and dubiously related to the particular field, s

Re: Proposed Field API additions

On Jun 7, 11:44 pm, Anssi Kääriäinen wrote: > I don't see the difference between doing the registration > automatically by Field.__new__() and automatically registering > anything living in fields.py or fields module. OK, now I get it - you will see in which app the field lives by in which app th

Re: Proposed Field API additions

On 07/06/12 21:56, Anssi Kääriäinen wrote: > Is the reason for this to be able to track changes to field by > checking if its init arguments have changed? Why is it not possible to > track changes by checking the SQL output the field will generate > instead? This is guaranteed to be a string, and s

Re: Draft branch: Swappable User models in contrib.auth

On Thu, Jun 7, 2012 at 7:48 PM, Anssi Kääriäinen wrote: > On Jun 7, 11:57 am, Florian Apolloner wrote: >> Hi, >> >> On Wednesday, June 6, 2012 4:32:02 PM UTC+2, Anssi Kääriäinen wrote: >> >> > Still, yet another API idea: [snip] >> >> Then, Model.__new__ will replace the SwappableUser class with

Re: Draft branch: Swappable User models in contrib.auth

On 8 kesä, 02:43, Russell Keith-Magee wrote: > Good idea. I haven't tried to see what it actually does; I'm guessing > you're going to get Table Does Not Exist errors. A nicer error > wouldn't hurt. Yes, that is what happens. > >  - For documentation: It should be suggested that the example MyUs