On 3/4/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> OK, it's weirder than you think, though.
Oh.. I don't know... I think it's pretty weird :-)
> I get the same failure whether
> I run all the tests or only Luke's tests using postgreSQL (and
> everything passes with SQLite).
Thanks for
http://code.djangoproject.com/ticket/1464
I finished tutorial01.txt update, but didn't get to the others. Very
sorry. If not completed when I get back in town (3/15) I'll pick up
where I left off.
Cheers,
Jeremy
--~--~-~--~~~---~--~~
You received this mes
On Sat, 2006-03-04 at 11:25 +0800, Russell Keith-Magee wrote:
> On 3/4/06, Luke Plant <[EMAIL PROTECTED]> wrote:
> > Russell (I think this is your area),
> >
> > I found another bug in delete(). I eventually managed to get it down to
> > the attached example, in the same format as the existing mo
On 3/4/06, Luke Plant <[EMAIL PROTECTED]> wrote:
> Russell (I think this is your area),
>
> I found another bug in delete(). I eventually managed to get it down to
> the attached example, in the same format as the existing model tests.
Thanks for narrowing this one down - I'll have a look at it.
On 03/04/06 01:34, Russell Keith-Magee wrote:
> On 3/4/06, Steven Armstrong <[EMAIL PROTECTED]> wrote:
>>
>> Hi django devs
>>
>> In a app I'm currently building I rely on the 'sqlinitialdata' feature.
>> I've recently switched to the magical-removal branch where this is not
>> yet implemented.
>
On 3/3/06, Linicks <[EMAIL PROTECTED]> wrote:
>
> I think that it's important to have a default authentication system
> similar to the current one.
Agreed. I didn't mean to suggest that MultiAuthMiddleware would
require any more configuration or work differently out of the box than
Django does cu
On Saturday 04 March 2006 02:16, Malcolm Tredinnick wrote:
> On Sat, 2006-03-04 at 02:04 +, Luke Plant wrote:
> > Russell (I think this is your area),
> >
> > I found another bug in delete(). I eventually managed to get it
> > down to the attached example, in the same format as the existing
>
On Sat, 2006-03-04 at 02:04 +, Luke Plant wrote:
> Russell (I think this is your area),
>
> I found another bug in delete(). I eventually managed to get it down to
> the attached example, in the same format as the existing model tests.
That attachment came through all scrambled for me and
Russell (I think this is your area),
I found another bug in delete(). I eventually managed to get it down to
the attached example, in the same format as the existing model tests.
One thing that puzzles me is that in my live example (with the full
model, data etc), compare_models() definitely g
"""RequestUserMiddleware is a horribly ugly name, and in the
latest diff
attatched to http://code.djangoproject.com/ticket/1428 I've renamed it
to MultiAuthMiddleware. I'm wondering if people think it would be
worthwhile to add something else called AuthMiddleware that would do
more or less what d
On 3/4/06, Steven Armstrong <[EMAIL PROTECTED]> wrote:
>
> Hi django devs
>
> In a app I'm currently building I rely on the 'sqlinitialdata' feature.
> I've recently switched to the magical-removal branch where this is not
> yet implemented.
sqlinitialdata _was_ implemented, but it's been removed
RequestUserMiddleware is a horribly ugly name, and in the latest diff
attatched to http://code.djangoproject.com/ticket/1428 I've renamed it
to MultiAuthMiddleware. I'm wondering if people think it would be
worthwhile to add something else called AuthMiddleware that would do
more or less what djan
On Sunday 26 February 2006 03:15, Russell Keith-Magee wrote:
> Interesting... by way of diagnosis, it might be helpful to dump the
> contents of seen_objs that is collected just before the call to
> delete_objects() at line 216 of django/core/db/query.py. That
> structure determines the order in
Am 03.03.2006 um 18:53 schrieb Jacob Kaplan-Moss:
> Hey folks --
>
> I've thought about this a bit more; lots of good points have been
> raised. What I'd like to do would be to add a new tag that takes
> care of auto-escaping variables used within it. Something like::
>
> {% autoescape %}
Hi django devs
In a app I'm currently building I rely on the 'sqlinitialdata' feature.
I've recently switched to the magical-removal branch where this is not
yet implemented.
I've opened a ticket #1438 [1] and sent a patch that implements it.
It currently just fetches .sql files from the app/s
Sounds good, but I just don't like the name. How about "escape", or
"escapeblock"?
And how about...
{% autoescape except "br,p,table" %}
?
On 3/3/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
> Hey folks --
>
> I've thought about this a bit more; lots of good points have been
> rais
Max Battcher wrote:
> > the standard solution is to use a wrapper for strings that you
> > *don't* want escaped. see e.g. the section on "HTML templates"
> > on this page:
>
> The other problem is that not everyone wants the same escape. For
> instance, there are those of us that {% load markup
Project is a business term, advise application
On 3/4/06, Sean Perry <[EMAIL PROTECTED]> wrote:
>
> Jeremy Dunck wrote:
> > On 3/2/06, Sean Perry <[EMAIL PROTECTED]> wrote:
> >
> >>I am definitely -2 on this. Malcolm does a good job of starting the ball
> >>rolling as to why.
> >
> >
> > The ran
Hey folks --
I've thought about this a bit more; lots of good points have been
raised. What I'd like to do would be to add a new tag that takes
care of auto-escaping variables used within it. Something like::
{% autoescape %}
Any {{ variables }} used within this {{ block }}
Max Battcher wrote:
> On 3/3/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> Jacob Kaplan-Moss wrote:
>>
>>> Why not do it for all variables? At times you want to pass chunks of
>>> HTML into a template that get displayed raw. I don't think the
>>> behavior you suggest should be default, but
On 3/3/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Jacob Kaplan-Moss wrote:
>
> > Why not do it for all variables? At times you want to pass chunks of
> > HTML into a template that get displayed raw. I don't think the
> > behavior you suggest should be default, but do you have any ideas
Jeremy Dunck wrote:
> On 3/2/06, Sean Perry <[EMAIL PROTECTED]> wrote:
>
>>I am definitely -2 on this. Malcolm does a good job of starting the ball
>>rolling as to why.
>
>
> The range is -1..+1 ;-)
>
with room for hyperbole (-:
--~--~-~--~~~---~--~~
You rec
Jacob Kaplan-Moss wrote:
> Why not do it for all variables? At times you want to pass chunks of
> HTML into a template that get displayed raw. I don't think the
> behavior you suggest should be default, but do you have any ideas on
> how to make it optional?
the standard solution is to use a wr
Adrian and hugo, thanks for the specifics. Seems like good material for
a wiki page on "alternative" Django setups. If projects are just a
convenience, and some of the biggest Django-powered sites aren't even
using them, that is definitely worth covering explicitly.
I can imagine this might seem
Jacob Kaplan-Moss wrote:
> The problem in the admin was fixed in [1982]: http://
> code.djangoproject.com/changeset/1982;
thanks (and sorry--I'll start using the svn then)
> in your own templates you'll
> want to use the "escape" filter (http://www.djangoproject.com/
> documentation/templates/#
On 3/3/06, Jeroen Ruigrok van der Werven <[EMAIL PROTECTED]> wrote:
> On 3/3/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> > Anyhow, I'm not crazy about the term "project" either, so we can
> > definitely change it if there's a better term. How about
> > "extravaganza" or "experience"?
>
> -1
>
Gábor Farkas wrote:
> Jacob Kaplan-Moss wrote:
>> On Mar 2, 2006, at 3:16 PM, Michael Radziej wrote:
>>> Now, did I miss something and is this already fixed? Should this be
>>> treated differently? How do other people handle this?
>>
>> The problem in the admin was fixed in [1982]: http://
>> cod
Jacob Kaplan-Moss wrote:
> On Mar 2, 2006, at 3:16 PM, Michael Radziej wrote:
>> Now, did I miss something and is this already fixed? Should this be
>> treated differently? How do other people handle this?
>
> The problem in the admin was fixed in [1982]: http://
> code.djangoproject.com/changes
On Mar 2, 2006, at 3:16 PM, Michael Radziej wrote:
> Now, did I miss something and is this already fixed? Should this be
> treated differently? How do other people handle this?
The problem in the admin was fixed in [1982]: http://
code.djangoproject.com/changeset/1982; in your own templates you'
On Fri, 2006-03-03 at 12:04 +, xamdam wrote:
> that sure did, it thanks! what is the best list to monitor these
> changes?
This list. In this case, syncdb was discussed briefly on the list (in
passing, in the middle of another thread):
http://groups.google.com/group/django-
developers/browse_
On 3/3/06, xamdam <[EMAIL PROTECTED]> wrote:
>
> that sure did, it thanks! what is the best list to monitor these
> changes?
Your best bet would be to monitor changesets using the Timeline:
http://code.djangoproject.com/timeline
You can also get the timeline as an RSS feed if that is more your
>Just for the record, World Online (and I, for my stuff at
>washingtonpost.com and personal use) don't even use "projects". I have
>a "holovaty" package that contains a bunch of apps and *no* settings
>-- and I have a separate package of settings for various servers, such
>as my laptop, the testin
that sure did, it thanks! what is the best list to monitor these
changes?
max
--~--~-~--~~~---~--~~
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@google
On 3/3/06, kmh <[EMAIL PROTECTED] > wrote:
>
> My concern is that you end up with this:
>
> book.authors = [author1, author2]
> book.authors == [author1, author2] # not true
Well, if we want to get picky like that, then book.authors should
evaluate as a set as well, unless an order_by has been
34 matches
Mail list logo
