On Dec 17, 2007 1:04 PM, James Bennett <[EMAIL PROTECTED]> wrote:
>
> While playing around a bit with newforms-admin, I noticed that it's
> ever-so-close to being able to handle one cool use case which came up
> during the design discussion at PyCon: running django.contrib.admin
> without
I would like to propose splitting django.newforms.models. The reasoning
behind this stems from the work going on in newforms-admin.
django.newforms.models now consists of ModelForm, the model choice
fields and the model related formset code. I am working on a patch that
adds declarative style
On Dec 17, 6:52 pm, "Gary Wilson Jr." <[EMAIL PROTECTED]> wrote:
> SmileyChris wrote:
> > I've been working on a new version of the session messages ticket and
> > was looking at making the "messages" context variable lazy - it seems
> > silly how it currently wipes messages, even if you didn't
Joseph Kocherhans wrote:
> I don't want to speak for James, but that's how I see it.
Then this is great!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email
On 2007-12-16 21:04:10 -0700, "James Bennett"
<[EMAIL PROTECTED]> said:
>
> While playing around a bit with newforms-admin, I noticed that it's
> ever-so-close to being able to handle one cool use case which came up
> during the design discussion at PyCon: running django.contrib.admin
>
On 12/16/07, James Bennett <[EMAIL PROTECTED]> wrote:
>
> While playing around a bit with newforms-admin, I noticed that it's
> ever-so-close to being able to handle one cool use case which came up
> during the design discussion at PyCon: running django.contrib.admin
> without
On 12/17/07, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
>
> James Bennett wrote:
> > This means the default implementation can happily use
> > django.contrib.auth and the existing is_staff flag and permission
> > system, but that using something else is as easy as subclassing and
> > overriding the
James Bennett wrote:
> This means the default implementation can happily use
> django.contrib.auth and the existing is_staff flag and permission
> system, but that using something else is as easy as subclassing and
> overriding the right methods. And with a little refactoring to remove
> the
On Dec 17, 2007 5:36 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Yes, right. But here is patch from 8 months ago:
> http://code.djangoproject.com/attachment/ticket/3275/fix_depth_bug.diff
> and why it isn't in branch head?
Perhaps you didn't read the information on that ticket, which
On Mon, 2007-12-17 at 03:36 -0800, [EMAIL PROTECTED] wrote:
> Yes, right. But here is patch from 8 months ago:
> http://code.djangoproject.com/attachment/ticket/3275/fix_depth_bug.diff
> and why it isn't in branch head?
All those bugs are being fixed on the queryset-refactor branch. I hadn't
Yes, right. But here is patch from 8 months ago:
http://code.djangoproject.com/attachment/ticket/3275/fix_depth_bug.diff
and why it isn't in branch head?
On 17 Gru, 12:28, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-12-17 at 03:25 -0800, [EMAIL PROTECTED] wrote:
> > I found bug
On Mon, 2007-12-17 at 03:25 -0800, [EMAIL PROTECTED] wrote:
> I found bug in Django ORM. In function select_realted is a parameter
> 'depth' which works wrong. If I set depth=1, Django getting related
> tables with depth=2.
Always worth having a quick search in Trac for things like this. This
I found bug in Django ORM. In function select_realted is a parameter
'depth' which works wrong. If I set depth=1, Django getting related
tables with depth=2.
The bug is in file db/models/query.py in function fill_table_cache,
where is:
if max_depth and cur_depth > max_depth:
return
Doh! I just had a read through the dispatcher code and there's a lot
more going on there than I previously thought (possibly due to the
frequency of signal requests, like you mentioned).
On Dec 17, 3:52 am, "James Bennett" <[EMAIL PROTECTED]> wrote:
> On Dec 17, 2007 3:39 AM, [EMAIL PROTECTED]
On Dec 17, 2007 3:39 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Tell me if I'm crazy here, but what if LogEntry objects were created
> upon emission of some signal? That way, other apps could hook in and
> log their own actions as well, along with removing the admin's
> dependency on
Tell me if I'm crazy here, but what if LogEntry objects were created
upon emission of some signal? That way, other apps could hook in and
log their own actions as well, along with removing the admin's
dependency on auth. It could go into django.contrib.logging or
something.
What do you guys
On 17 Dec 2007, at 08:08, James Bennett wrote:
> This means the default implementation can happily use
> django.contrib.auth and the existing is_staff flag and permission
> system, but that using something else is as easy as subclassing and
> overriding the right methods. And with a little
Greetings to all http://rtymarya.tripod.com/naruto-music-melody.html
naruto music melody
http://rtymarya.tripod.com/naruto-battle-music.html naruto battle
music
http://rtymarya.tripod.com/naruto-shippuden-music-download.html
naruto shippuden music download
On Dec 17, 2007 1:34 AM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> I'm either confused or scared. Presumably the admin application still
> relies on authentication, right? Without making me rustle through all
> the code, can you explain how it is enforcing access restrictions
> without the
19 matches
Mail list logo
