Why does Django make it hard to debug tags?

[SmileyChris]

http://code.djangoproject.com/ticket/11461

DebugNodeList catches all exceptions, sticks them in a
TemplateSyntaxError, and stuffs the original exception in the new
exception. I'm not sure why this is done, but it breaks debugging and
exception handling.

What is the advantage of swallowing the exceptions?
--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Session/cookie based messages (#4604)

[SmileyChris]

On Oct 16, 5:56 am, Tobias McNulty  wrote:
> On Wed, Oct 14, 2009 at 10:27 AM, Jacob Kaplan-Moss  
> wrote:
> > I'm trying to avoid having two incompatible messaging systems in
> > Django. I agree that linking messages to sessions makes more sense
> > than linking them to users [1], but we can't just remove the user
> > messages API outright. I'd like a good transition strategy, so it
> > seems the best way would be to keep the user messages API, but switch
> > it to use session messages under the hood.
>
> I know a solution like this was attempted and then abandoned earlier
> in the ticket history.

To summarize how it worked:
* user messages were left as they are (database call and all)
* session messages were added
* a new context processor handled lazily combining both message
sources into a {{ messages }} context variable

>
> Chris, do you have any wisdom to share about this?  I expect it may be
> complicated because I can't think of a clean way to get the current
> request (and hence the session messages variable) inside the User
> model.

I can't see how it can work either (without some evil threadlocal-
ing).

If we are to slowly deprecate this functionality, I think that we
should do effectively the same thing.
Leave user messages as-is and use something like this as the default
message storage:

class LegacyFallbackStorage(FallbackStorage):
storage_classes = (UserMessageStorage, CookieStorage,
SessionStorage)

If someone knows they don't need user messages at all, they can set
NOTIFICATIONS_STORAGE = FallbackStorage
--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Session/cookie based messages (#4604)

[SmileyChris]

On Oct 16, 12:03 pm, SmileyChris  wrote:
>
> class LegacyFallbackStorage(FallbackStorage):
>     storage_classes = (UserMessageStorage, CookieStorage,
> SessionStorage)

Here's a working implementation even: 
http://code.google.com/p/django-notify/source/detail?r=35

No need to panic, django-notify users - I haven't made it the default
storage.
--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Session/cookie based messages (#4604)

[SmileyChris]

On Oct 16, 2:04 pm, Tobias McNulty  wrote:
> Just to make sure I understand this correctly, let me try to summarize
> what this would mean:
>
>  * the proposed app controls {{ messages }} and is responsible for
> retrieving anything set in the Message model

Thanks to Luke's work with lazy messages, we can keep now let
contrib.auth processor continue to set {{ messages }} - we'll just
override it (and state in docs that it must be placed after
contrib.auth processor)

>
>  * old apps that call user.message_set.create will still get their
> messages to the screen, assuming the project uses {{ messages }} in
> the template
>
>  * old apps that call get_and_delete_messages or iterate through the
> Message.objects.all() manually will NOT see any messages that were
> stored in the session or a cookie, but they will continue to see
> messages created the old way
>
>  * judging from your code, the new app will NOT store any messages in
> the old Message model, it will only read them
>
>  * the standard template code:
> [snip]
> will continue to work untouched after the update.  For those that
> choose to leverage it, a {{message.level}} (or otherwise named
> attribute) will also be available.

Yes x4
>
>  * since we are tying ourselves to the {{ messages }} variable, this
> probably means that the app should be called 'messages'.  There has
> been some hesitation about this.  Are we in the clear now that we have
> a potential upgrade path from the old API?  Or is there still concern
> about naming?

I'm happy with keeping the name "messages" now that it has been
indicated that the User messages should be deprecated.
It makes the upgrade path easier.
--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: shortcut proposal

[SmileyChris]

On Oct 17, 1:51 am, Jacob Kaplan-Moss  wrote:
> I'd like this shortcut to be (similar to?) Simon's TemplateResponse
> (http://code.google.com/p/django-openid/source/browse/trunk/django_ope...).

+1 btw
--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: shortcut proposal

[SmileyChris]

Interestingly, I made a snippet [1] two years ago something like this.
Granted, it was a bit more convoluted: you build a decorator and use
that everywhere (I was a bit anal about DRY, so you can render a
prefix template path for that decorator)

Personally, I just use direct_to_template for projects now, because it
is built in (and extra abstraction layers make it that bit harder to
follow code).
I like Simon's wrapper but have never got around to using it. It's on
my list to use for my next project though.

[1] http://www.djangosnippets.org/snippets/133/

On Oct 17, 9:51 am, Justin Lilly  wrote:
> Just to add something a little different, there is a 5th option, that
> may fall into place w/ #4. The @render_to decorator. works like:
>
> @render_to('myapp/mypage.html')
> def home(request, foo):
>     return {'foo':foo}
>
> http://www.djangosnippets.org/snippets/821/
>
> This isn't a 1:1 replacement, but I've started using it in all of my
> projects.
>
>  -justin
>
>  signature.asc
> < 1KViewDownload
--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: default Model.all()?

[SmileyChris]

On Oct 23, 6:16 am, Philippe Raoult 
wrote:
> While we're talking about that, is there a reason the default manager
> isn't iterable (default mapping to .all()) ?

I've always thought this would be the logical thing to do, too.
--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Enhanced debug output colors: django code is green, user code is red.

[SmileyChris]

Just chiming in that I'm also +1 to visual distinction, -1 to current
colors.

On Nov 3, 4:27 pm, Tobias McNulty  wrote:
> I'm not a big fan of the red/green either.  They imply that Django code is
> "bad" and user code is "good".  What about something more subtle, like
> different shades of gray for the background and/or text, to draw your
> attention to the user code while making it easier to gloss over the Django
> code (but still readable if necessary)?
>
> Tobias
>
>
>
>
>
> On Mon, Nov 2, 2009 at 6:57 PM, Gabriel Hurley  wrote:
>
> > I'm not sure about the exact colors, but the visual distinction is a
> > big plus in my book.
>
> > One possible place to document it would be in the information
> > regarding the TEMPLATE_DEBUG setting here:
> >http://docs.djangoproject.com/en/dev/ref/settings/#template-debug
>
> >  - Gabriel
>
> > On Nov 2, 2:03 pm, Dougal Matthews  wrote:
> > > 2009/11/2 Yuri Baburov 
>
> > > > Hi All,
>
> > > > Since you are discussing and applying different features,
>
> > > > I think it's time to ask what do you think of the subj.
>
> > > > It's athttp://code.djangoproject.com/ticket/11834
>
> > > > It adds some helpful color beauty to django 500 output.
>
> > > > Sample pictures are here:
> > > >http://code.djangoproject.com/attachment/ticket/11834/11834.pngand
> > > >http://code.djangoproject.com/attachment/ticket/11834/11834_2.png
>
> > > > I'm not a designer, so feedback is highly appreciated
>
> > > I really like this, I always scan the traceback looking for items with
> > with
> > > .virtualenv in the path so I can ignore them - its bugged me for a while.
> > > This is clearly a better solution.
>
> > > I'm no designer either but I perhapsit could do with a bit of attention
> > from
> > > one, I'm not that keen on the red (pink?) and green mix.
>
> > > Also, documentation will be needed so users know what the colours mean
> > but
> > > I'm not sure where in the docs. I can't see anything on the current error
> > > page.
>
> > > Dougal
>
> --
> Tobias McNulty
> Caktus Consulting Group, LLC
> P.O. Box 1454
> Carrboro, NC 27510
> (919) 951-0052http://www.caktusgroup.com
--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: smart if tag

[SmileyChris]

On Nov 29, 6:40 am, Luke Plant  wrote:
> Hi all,
>
> I started work replacing Django's if with the "smart-if" template tag
> by Chris Beaven (http://www.djangosnippets.org/snippets/1350/)

Neat! I'm assuming you'll be posting this to your bitbucket soon? :)

> 1) Handling non-existent variables
> 2) TEMPLATE_STRING_IF_INVALID breaks everything

Yep, this is a bit of a problem which I've been thinking about
recently (encountered it for a project).

My (non-implemented) solution to both of these is to use a NotFound
object. I just coded one up: http://gist.github.com/244861
This could actually be a much better return value than a plain
TEMPLATE_STRING_IF_INVALID string in general.

> 3) Behaviour of 'x and b or y'

Like I commented in the snippet, I don't think it's worth obfuscating
code to limit this behaviour.

> 4) Behaviour of 'not'

Bleh, whatever. If we need it for backwards compatibility, it's not
hard to implement.

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: smart if tag

[SmileyChris]

On Dec 1, 6:08 am, Luke Plant  wrote:
> > I was with you right up until the equality comparisons (Null ==
> >  Null -> False etc). As noted by Alex, it conflicts with the answer
> >  given by {% ifequal %}; it also differs with Python's behavior.
>
> Yeah, I hadn't thought of that. I don't think it's a case of differing
> with Python's behaviour, as we are making a deliberate choice to
> substitute a missing variable with None (or Null or whatever).  You
> could argue that Python throws a NameError in this case.

Personally, I think that "(not found)" should *not* equal "None", even
if that differs from ifequal.

But whatever, I'm not too worried either way.

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: smart if tag

[SmileyChris]

On Dec 1, 6:08 am, Luke Plant  wrote:

> Given that the 'Null' stuff has now been removed, we could
> move back to your way to reduce the code a bit, but I'm not sure it is
> worth it.

I'd say reduce the code again.

And I think you missed adding some files in your repo?

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Single lines between top level classes & functions

[SmileyChris]

Prompted by Luke's whitespace removal patch for django-contrib-
messages, I thought I'd bring this up.

The Django contributing guide says "Unless otherwise specified, follow
PEP 8."

Should new code use two lines between top level classes & functions,
like PEP 8 suggests, or should the contributing guide be updated?

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Session/cookie based messages (#4604)

[SmileyChris]

I applied and pushed all but your final whitespace revision.

When Tobias reads this thread again, I'm sure he'll give you commit.
The fail_silently sounds good, and yes these failures were a rather
big oversight.

On Dec 2, 10:35 am, Luke Plant  wrote:
> I've been going through the code carefully now, and I've got a bunch
> of patches, mainly very minor (attached as a mercurial bundle, use "hg
> in fixes.bundle" to view, or if you give me commit rights to your
> repository I'll commit directly), and one significant issue:
>
> If I read the patch correctly, when a non-authenticated user uses a
> generic view (create/update/delete), they will get a failure if the
> messages framework is not installed. This is a big backwards
> incompatibility.

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Should docs.djangoproject.com link to 1.1 frozen docs by default, not SVN dev docs?

[SmileyChris]

This should be a high priority fix.

Anyone new to Django and using the installation of 1.1.1 (which the
download page recommends over trunk) will currently be unable to
follow the tutorial.
I was having a face to face meeting today with someone who had exactly
this problem.

On Nov 6, 1:53 am, Russell Keith-Magee  wrote:
> On Thu, Nov 5, 2009 at 8:48 AM, Taylor Marshall
>
>  wrote:
>
> > I definitely agree with this change.   I've even had a hard time
> > finding 1.1 docs at all, it seems like the site dumps you to dev docs
> > by default, and if you look for "old" docs, you end up with 1.0 rather
> > than 1.1.
>
> The 1.1 docs are there - at the somewhat predictable URL:
>
> http://docs.djangoproject.com/en/1.1/
>
> However, they aren't linked anywhere obvious that I can find, and they
> aren't explicitly available on the Google search widget.
>
> I agree with Simon, though. Now that we have a semi-regular release
> schedule, there isn't as great a need to stay on trunk, so we should
> be encouraging people to download the stable release unless they have
> a need to ride the bleeding edge. To that end, the default docs should
> be stable, not development.
>
> My only caveat on this is that we need to ensure 1.1 means "the
> current code in the 1.1.X branch", not "the contents of the 1.1
> release". We are constantly updating and clarifying docs, and it's
> important that these changes are reflected online.
>
> Yours,
> Russ Magee %-)

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: smart if tag

[SmileyChris]

Because that link intrigued me, I challenged myself to write my own
generic lexer & parser based on what I had read:
http://gist.github.com/250128



On Dec 6, 2:07 pm, Luke Plant  wrote:
> On Saturday 05 December 2009 20:09:21 Luke Plant wrote:
>
> > I'm not likely to able to look at this before Tuesday.  If anyone
> > wants to look at it, I think the right approach is something like
> >  the following:
> >http://effbot.org/zone/simple-top-down-parsing.htm
> > (without the globals, obviously, they can be converted to instance
> > variables/methods).
>
> Cancel that - I unexpectedly had free time this evening, and I
> implemented this.  It's a nice replacement I think (credit to Vaughan
> Pratt and Fredrik Lundh for the basic approach and Python
> implementation respectively).  The new implementation is pretty much
> the same length as the old one, and hopefully easier to read, with a
> much smaller core parser.  Precedence is specified directly, rather
> than implicitly, so it's much easier to check that it's the same as
> Python's.
>
> Latest patch attached to this e-mail.
>
> Regards,
>
> Luke
>
> --
> "Idiocy: Never underestimate the power of stupid people in large
> groups." (despair.com)
>
> Luke Plant ||http://lukeplant.me.uk/
>
>  smartif_8.diff
> 27KViewDownload

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: What do people think about the get_absolute_url proposal?

[SmileyChris]

On Dec 17, 8:57 am, Alex Gaynor  wrote:
> On Wed, Dec 16, 2009 at 2:53 PM, Mike Malone  wrote:
> > How's that different than the current situation, where we return an
> > absolute URL reference that can be converted into an absolute URL
> > using request.build_absolute_uri?
>
> It allows an object to return a URL that already has it's domain
> defined (as might happen for a SaaS site with custom subdomains).
>

build_absolute_uri allows that already.

>>> r = HttpRequest()
>>> r.META['SERVER_NAME'] = 'test.com'
>>> r.META['SERVER_PORT'] = '80'
>>> r.build_absolute_uri('fish')
'http://test.com/fish'
>>> r.build_absolute_uri('//fish.com/fish')
'http://fish.com/fish'
>>> r.build_absolute_uri('https://fish.com/fish')
'https://fish.com/fish'

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Call for feedback: django.utils.signed and signed cookies

[SmileyChris]

On Dec 22, 1:52 pm, Johannes Dollinger
 wrote:
> There's a small bug in b64_decode(), the padding should be
>         r = len(s) % 4
>         pad = '=' * (r and 4 - r or 0)

Or even simpler:
pad = '=' * (-len(s) % 4)

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Possible contrib.humanize addition

[SmileyChris]

On Jan 5, 9:24 pm, harrym  wrote:
> I'm working a templatetag that determines whether to use 'a' or 'an'
> in front of English words. My particular use case for this is in a
> tumblelog app I'm developing - many different types of entry may be
> added (link, html, quote, etc), and I'm linking to the 'Add a[n]
>  entry' pages by iterating over the different types. Would this
> be considered a useful addition to contrib.humanize?
>
> The two main reasons against it I see are that firstly, it only works
> for English words, so would be of little use to developers using
> foreign languages, and secondly, it perhaps wouldn't be as widely used
> as the other filters in there.
>
Here's a snippet I wrote a while back you may want to check out too:
www.djangosnippets.org/snippets/1519/
-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Message level API awkwardness

[SmileyChris]

On Jan 6, 11:09 pm, Jeremy Dunck  wrote:
> I realize I'm very late giving feedback on the API, sorry and feel
> free to ignore if I'm too late.
>
> That said, from the docs, the API to set the effective messaging level
> is awkward:
>
> ==
> # Change the messages level to ensure the debug message is added.
> messages.get_messages(request).level = messages.DEBUG
> ==
>
> To *set* the messaging level, I call .get_messages?
>
> I think I understand the reason this was done-- get_messages is
> backend- and request-specific, but it is definitely surprising.
>
> Perhaps something like this would do better?
>
> messages.effective_level(request) => messages.INFO
> messages.set_effective_level(request, messages.DEBUG)
> ?
>
Yes, that sounds good. I also like Tobias' names better
-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Message level API awkwardness

[SmileyChris]

On Jan 11, 2:12 pm, Russell Keith-Magee 
wrote:
> I concur. get_level()/set_level() sounds like a reasonable change to
> me. Can I have that in the form of a ticket and patch? :-)

http://code.djangoproject.com/ticket/12575
-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Possible bug in messages framework?

[SmileyChris]

Looking around, this looks like a problem for other frameworks too
(see http://trac.turbogears.org/ticket/1164)
If we're to accept that turbogears example, it sounds like we're not
properly encoding the cookie in core, rather than patching messages.

On Jan 23, 2:23 am, Tobias McNulty  wrote:
> Hi Jeff,
>
> Could you try again without a comma in the message and see if the
> CookieStorage starts working again?  Either way, that definitely sounds like
> a bug to me.
>
> Thanks,
> Tobias
>
> On Fri, Jan 22, 2010 at 12:13 AM, j...@jeffcroft.com 
> wrote:
>
>
>
>
>
> > Sean-
>
> > Can't say for sure it's related, but I can verify that I was using
> > Safari (Mobile) and that my message had commas in them...so it
> > definitely could be.
>
> > Switching to session storage solved the problem for me, and that
> > backend works fine for my needs. So, it's no longer  pressing issue
> > for me, but there definitely seems to be something wrong in the cookie
> > storage backend.
>
> > Jeff
>
> > On Jan 21, 9:07 pm, Sean Brant  wrote:
> > > I wonder if this is related?
> >http://groups.google.com/group/django-developers/browse_thread/thread...
>
> > > On Jan 21, 2010, at 10:55 PM, j...@jeffcroft.com wrote:
>
> > > > After a little more playing around, I've discovered that this is not
> > > > an issue if I use the session storage -- so it seems to be related to
> > > > cookie storage.
>
> > > > --
> > > > You received this message because you are subscribed to the Google
> > Groups "Django developers" group.
> > > > To post to this group, send email to
> > django-develop...@googlegroups.com.
> > > > To unsubscribe from this group, send email to
> > django-developers+unsubscr...@googlegroups.com > i...@googlegroups.com>
> > .
> > > > For more options, visit this group athttp://
> > groups.google.com/group/django-developers?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django developers" group.
> > To post to this group, send email to django-develop...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-developers+unsubscr...@googlegroups.com > i...@googlegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/django-developers?hl=en.
>
> --
> Tobias McNulty
> Caktus Consulting Group, LLC
> P.O. Box 1454
> Carrboro, NC 27510
> (919) 951-0052http://www.caktusgroup.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

How about adding a noop {% csrf_token %} tag to the Django 1.1 branch

[SmileyChris]

I was thinking that it would help third-party apps to be able to work
across both 1.1 and 1.2 installations without workarounds if the 1.1
branch had a csrf_token tag, just to stop templates choking with a
"Invalid block tag: 'csrf_token'" message.

Does this fit within the policy for supporting old versions? Seemed
like a good idea to me anyway.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: EmailField max_length of 75 characters should be 256 acccording to RFC 5321

[SmileyChris]

> Addressing the limitations of the builtin auth.User is something I
> hope to look at in the 1.3 timeframe.

In that case, would it be reasonable to have an open ticket for the
specific request of being able to customize the length of the email
field in the contrib.auth User object?

I'm guessing that #12900 was opened with auth.user in mind
particularly, but the ticket subject tried to cover the broader case.
Renaming the subject and reopening seems appropriate (or opening a new
ticket, whatever floats boats).

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: How about adding a noop {% csrf_token %} tag to the Django 1.1 branch

[SmileyChris]

Bah! Yes, just like that.

However, it would be nice to release a 1.1.2 containing this for those
who use released versions as opposed to svn branches before 1.2 hits.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

IfEqualNode is missing a get_nodes_by_type method

[SmileyChris]

My ticket in #6510 [1] deals with this, along with a nice abstraction
of common recursive nodelist gathering patterns.

Although the ticket description, comments (and even tests in my patch)
mention {% block %}, this has *nothing* to do with conditional
inheritance.

If the patch is deemed too much of a feature to fit in the 1.2
schedule, I'd still advocate for just adding a get_nodes_by_type
method to the IfEqualNode. It's not a difficult or overly
controversial change, and the bug has existed far too long because of
confusion over the actual issue.

[1] http://code.djangoproject.com/ticket/6510

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: 404 debug pages should show the name of the tried urlpattern - #9310

[SmileyChris]

Just two small points I'd like to highlight:

On Feb 26, 3:50 am, Russell Keith-Magee 
wrote:
> I'm not casting blame here. Those doing triage work are doing a great
> job. I'm just pointing out that we have a problem.  Despite the best
> efforts of our volunteer triage team, they haven't been able to keep
> up with the backlog. We either need more volunteers to do triage, or
> we need to accept as a community that progress isn't going to be as
> fast as we may like.

More volunteers! Come one people! *SmileyChris blows his triage
trumpet*

> There is also an extent to which Django 1.2 has been the culprit.
> Django 1.2 has been particularly unkind to the ticket queue. The
> feature list for 1.2 is *huge*, and this has meant that smaller issues
> have taken a back seat. For comparison, we made lots of bugfixes
> during the 1.1 development cycle - enough to warrant 1.0.1 and 1.0.2
> point releases. However, during the 1.2 development cycle, there
> really hasn't been enough activity in 1.1.X to warrant us cutting a
> bugfix release.

I concur with Russ' points here, and I like his followon points that
1.3 should have scaled down goals to try and slim down the ticket
backlog.

But I do think it's critical to see a new 1.1 release before 1.2 is
out - if for no other reason than having {% csrf_token %} in a 1.1
official release.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: IfEqualNode is missing a get_nodes_by_type method

[SmileyChris]

On Feb 27, 3:06 am, Russell Keith-Magee 
wrote:
> I'm a little confused by this ticket.
>
> The original report was about something that is clearly a bug -- the
> inconsistency between block handling for {% if %} and {% ifequal %}.
> I'm 100% in agreement that this inconsistency should be fixed.
>
> The thing is - it has been. The tests in the patch on #6510 all pass
> on current trunk. The refactoring that was required for template
> caching has evidently cleaned up this issue - at least enough to
> correct the original test case.

Yes, the recent changes with BlockContext have hidden the error from
the testcases (and even my old test cases in the initial patch).
The inconsistency is still there -- and also a problem for {%
ifchanged %} I just noticed.

I have uploaded a new patch with a much simpler test case testing for
the underlying problem across all tags which have nodelist attributes
named something other than the standard "nodelist".

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Template Compilation

[SmileyChris]

Would whitespace handling be identical to the current template system?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Pass Thru Image Proxy Patch Interest?

[SmileyChris]

Yes, I was thinking the other day that it would be a cool solution for
serve() to be able to use storage backends

On Apr 16, 7:09 am, Kevin Howerton  wrote:
> Why not just use the backend feature that already exists?
>
> I have an S3 backend that does this...
>
> It checks if it's on S3, if not it serves it locally.  If it's on S3
> it throws the url into memcache, and bob is your uncle.
>
> On Wed, Apr 14, 2010 at 9:27 AM, Russell Keith-Magee
>
>  wrote:
> > On Wed, Apr 14, 2010 at 8:58 PM, Ed Menendez  wrote:
> >> Agree on avoiding additional setting.
>
> >> Re: cache
> >> Basically if the file is not found locally then it goes out to the URL
> >> to get it. So a local file couldn't be overwritten as that's the first
> >> thing it checks. Cache is currently an option to the view too. Which
> >> should be documented so it can be turned off if disk space is limited
> >> locally.
>
> > Ok. We can work through details once we're in the new feature
> > discussion phase for 1.3.
>
> >> Re: 1.2
> >> No problem. Should I not even open a ticket with the patch until after
> >> or is it OK to do now?
>
> > Feel free to open a ticket now, just don't put it on the 1.2 milestone.
>
> > Yours,
> > Russ Magee %-)
>
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "Django developers" group.
> > To post to this group, send email to django-develop...@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://groups.google.com/group/django-developers?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Process discussion: reboot

[SmileyChris]

On Apr 21, 9:46 am, Jeremy Dunck  wrote:
> [...]  Even so, the perception of ignored tickets is part of the
> problem-- whether tickets are actually ignored or not, the perception
> still would discourage contribution.
>
> I'd like to highlight tickets that have sat in each queue for a period
> of time -- a summary of min, max, mean time in queue (over time), and
> a detail view to sort tickets by age in queue, etc.

I agree that the perception definitely discourages contribution.

Reports which could identify "stale" tickets would be neat.

In a similar vein, it'd also be great if under the ticket summary,
some "hooks" based on the current ticket state could be added. E.g.:
"This ticket requires documentation - can you assist by adding some?",
or "Please try out the latest patch and report back as to whether it's
working for you".

While these next actions are obviously implied, explicitly suggesting
them encourages contribution.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Process discussion: reboot

[SmileyChris]

... And it seems like i'm reiterating the discussion about
http://code.djangoproject.com/wiki/TicketChangeHelp

I'm advocating for the friendly text in the ticket page itself, as I'm
not sure that was specifically mentioned in the related part of this
thread (but probably implied)

On Apr 21, 10:13 am, SmileyChris  wrote:

> In a similar vein, it'd also be great if under the ticket summary,
> some "hooks" based on the current ticket state could be added.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

1.1.2 admin form regression

[SmileyChris]

Can't investigate too much more until tomorrow, but it's a pretty big
regression so I thought I'd bring it up here for discussion as well as
starting a ticket.

http://code.djangoproject.com/ticket/13556

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: 1.1.2 admin form regression

[SmileyChris]

On May 18, 5:41 pm, Karen Tracey  wrote:
> On Tue, May 18, 2010 at 12:45 AM, SmileyChris  wrote:
> > Can't investigate too much more until tomorrow, but it's a pretty big
> > regression so I thought I'd bring it up here for discussion as well as
> > starting a ticket.
>
> >http://code.djangoproject.com/ticket/13556
>
> I cannot recreate given the information in the ticket.  Admin validation of
> exclude is new and my first guess would be it's picking up a genuine error
> that has gone unnoticed before, but since the ticket does not include either
> the mode nor the model admin definitionit's hard to say for sure.

And fair enough... I'll whip up a test case tomorrow when I'm at work
(the field is editible, so it's not that).

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: natural keys and dumpdata

[SmileyChris]

On Jul 10, 1:47 am, Stijn Hoop  wrote:
> Hi,
>
> I am trying to use the 'natural keys' feature of django to make a sort
> of "future proof" fixture loading possible.
> [...]
> With the patch linked below[1] I have successfully used dumpdata and
> loaddata for a .json export of my tables. Of course I would like to
> see something like this accepted, but this is of course a sort of
> "feature request".

It seems that my ticket in http://code.djangoproject.com/ticket/13252
covers this. It's ready for review if anyone wants to give it a
spin...

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: LOGIN_URL, LOGOUT_URL, LOGIN_REDIRECT_URL and SCRIPT_NAME.

[SmileyChris]

On Jul 11, 12:14 am, Russell Keith-Magee 
wrote:
> > So you can't put reverse now in settings.py unless there is some
> > late-binding construct, like
>
> > LOGIN_URL = RevLink('accounts:login', account_type='user')
>
> You shouldn't have to put reverse() calls into settings.py -- you
> should only have to provide the name. That's the point of having named
> URLs. Resolution should be happing at runtime, not at time of
> definition.

Well, with a lazy_reverse[1] function, this resolution could still
happen at at runtime.

[1] http://code.djangoproject.com/ticket/5925

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: django 1.2 ModelForm save during post_clean has caused me quite a headache ...

[SmileyChris]

On Jul 13, 9:10 pm, Margie  wrote:
> Yes, I know from tickets I have posted that modifying exclude
> dynamically is "not allowed".

Why wouldn't you just modify self.fields?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: Revised form rendering

[SmileyChris]

On Jul 15, 1:14 am, Russell Keith-Magee 
wrote:
> We need to be able to define templates for:
>
>  a) The layout for a single widget (e.g., a DateWidget)
>  b) The layout for a single row of a form
>  c) The layout for an entire form (top errors, fields, hidden fields)
> in as_* style.

We also need d) Media hooks for a single widget - whether this can be
done in only the template layer is a tricky problem...

I'm still struggling with how you'd be able to render all the media at
the top of your template for the form. I guess you'd have to define
any field widget overrides in that block, before rendering the form
media.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: memcached-based-cache - timeout=0 does not work as intended by memcached

[SmileyChris]

On Jul 27, 9:22 pm, Carl Meyer  wrote:
> The common thread, of course, is making it possible to write reusable
> caching code without special-casing particular backends.

I agree with Carl.
We have an abstracted api - having a property with different meanings
for different backends makes things a lot less pluggable.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Reverse URL lookup implementation

[SmileyChris]

I look forwards to the addition of 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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Proposal: default escaping

[SmileyChris]

Here's how I see it:
- 99% of the time, templates are HTML
- most template variables should be escaped
- developers are human and will miss variables that need escaping

My proposal is that all templates variables are escaped by default.


Think about it for a bit before you throw the idea away. Then reply
with your thoughts.


Of course we need an easy method to NOT auto-escape variables. Perhaps
something like  raw_variable ?

There is also the issue of MASSIVE backwards incompatibility. The two
options I see ane:
1. A new variable type is created for auto-escaping instead
2. Provide a setting which turns this new functionality on but is off
by default


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

HttpResponseSendFile

[SmileyChris]

(oops, posted this before in the django users group)

I noticed http://code.djangoproject.com/ticket/2131 was marked as a
wontfix today with the comment, "Django isn't meant to serve static
files".

I don't want to go reopening the ticket, but couldn't this still be
useful functionality?
What if I wanted to limit access to a static file to certain users or
groups in Django? How would I do this otherwise?


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: HttpResponseSendFile

[SmileyChris]

I realise there are better ways to send most files. I ask about this
because I'm looking at implementing that "special case" soon
(authenticating files via logged in user in Django), and I was just
wondering about ways to do it.


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Proposal: default escaping

[SmileyChris]

gabor wrote:
> my guess is (b)

I think (b) is pretty much a given. Looking back in the developers
group history, I see this is a recurring problem that seems to keep
getting put in the "too hard" basket.

See:
http://groups.google.com/group/django-users/browse_thread/thread/21da889ecb9c63dd/145e3e9c0e39b310
which references:
http://groups.google.com/group/django-users/browse_thread/thread/13cf8218d3a18aad/f4648b081c90885a
http://groups.google.com/group/django-developers/browse_thread/thread/e448bbdd40426915/2ee9766d0d148706


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: HttpResponseSendFile

[SmileyChris]

Ivan Sagalaev wrote:
> The regular HttpResponse already can serve files in some fashion:
>
> f = open(filename)
> return HttpResponse(f, mimetype='application/octet-stream')
>
> Here the file-like object will work as an iterator sending one line  at
> a time.

Thanks Ivan, this alleviates my concern of not having a
HttpReponseSendFile :)


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Proposal: default escaping

[SmileyChris]

Brilliant, Christopher. This is exactly the solution I'd be pleased
with!

We still have the problem of invalidating every single template written
so far in Django, however...


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Proposal: default escaping

[SmileyChris]

[EMAIL PROTECTED] wrote:

> that's why i suggest looking at this as a data validation issue.  (not
> simply as escaping)  we do lots of validation in the model already.

But it is an escaping issue.
There's nothing wrong with allowing html to be entered in (for example)
a comment field. It should be escaped in most templates, but sometimes
not, for example if there was a plain-text email of comments that gets
sent.


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Proposal: default escaping (and branch request)

[SmileyChris]

James Bennett wrote:
> Security by annoyance is security that people learn to hate and turn
> off as soon as they can, so in the end it doesn't really make them any
> more secure than they were before.

Having used TAL a lot (like KID, automatically escapes), I did not
actually find this annoying.
Maybe it's just a different mindset, but I'd rather have an occasional
"oh yea, I meant to pass that raw" experience rather than have the
chance of missing variables that should be escaped.

The thing is, it's very hard to "miss" a variable that you meant to
pass raw when testing. It's very easy to miss one that you should have
escaped. Maybe I'm just not god-like enough...

I'm feeling a bit disparaged that some key people don't seem to see
this as an issue.


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Proposal: default escaping (and branch request)

[SmileyChris]

Hi Jacob,

On Jun 21, 2006, at 5:16 PM, SmileyChris wrote:
> > Having used TAL a lot (like KID, automatically escapes), I did not
> > actually find this annoying.

Jacob Kaplan-Moss wrote:
> I really wish there was a way of saying this that didn't make me
> sound like a jerk... but:
>
>   If you like TAL better, use it.

Don't worry, no offense taken. I don't like TAL better, I was merely
pointing out that I did not find this an annoying behaviour.
I also understand that Django's template language can't please
everybody and that I am free to use alternate templating systems.

My point was simply that even though I would place myself in the
"experienced web developer" category, I personally prefered
auto-escaping systems.

Out of interest, have you (both Jacob and anyone else involved in this
discussion) seriously tried both and had a problem with auto-escaping?

> Yes, Django should be accessible to newbies, but newbie-friendliness
> needs to be balanced against the needs of experienced web developers
> (who likely already know all about XSS).

Out of interest, have you (both Jacob and anyone else involved in this
discussion) seriously tried an auto-escaping templating system and had
a problem with it opposing your needs?


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Proposal: default escaping (and branch request)

[SmileyChris]

> Yes, Django should be accessible to newbies, but newbie-friendliness
> needs to be balanced against the needs of experienced web developers
> (who likely already know all about XSS).

To exume an old horse and continue beating it, experienced web
developers may know all about XSS, but they will *still make mistakes*.
http://code.djangoproject.com/ticket/2290 is yet another example of
unescaped strings slipping past "experienced web developers".

Ok, ignore that vent. Now I'll try and be more constructive.

The following proposal assumes that we want template level
auto-escaping functionality and will provide it using the
escaped/non-escaped string idea from
http://code.djangoproject.com/wiki/AutoEscaping.

My proposal is that we don't use a {% autoescape on/off %} block tag or
a new |raw filter in the template source at all, but rather always use
the view to set it the auto-escaping status.
The developer wanting to use autoescaping can simply mark any variables
which should be raw using markescaped() in the view.

Rather than hard coding the escape method into VariableNode.render(),
the additional methods would be changed:
- django.template, Template.render(..., escaper=None)
- django.template.loader, render_to_string(..., escaper=None)
and the VariableNode.render() would pass the string through the escaper
(if one is given).

It is reasonably straight forward to identify the filters which do
their own escaping. Like the wiki article says, they can simply be
flagged with markescaped() in the filters.

Since it's done explicitly in the view, hopefully this helps to appease
Adrian's fears of escape munging being too hidden / magical.

So nothing up to this stage even breaks backwards compatibility.

A further step (an implementation of the on-by-default idea) would be
to set the default to render_to_string(..., escaper=True) but raise an
exception unless escaper resolves to False or is a subclass of Escaper.
This would break backwards compatibility, but becomes even more
explicit, which I hear is a good thing ;)


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Proposal: default escaping (and branch request)

[SmileyChris]

Hi Malcom,

Thanks for the comments.

Does the template source *need* to provide information on what is
escaped or not?

The view is handling a lot of the output format anyway, I personally
don't see a problem with looking there to see how a template is being
escaped.

Then again, I guess escaping is "presentation logic" and maybe it
should be coupled to the template source... any other thoughts, people?


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Templates and user.is_anonymous

[SmileyChris]

When using templates and the user interface, the logic seems backwards
to check for an anonymous user as opposed to a logged in user.

By using user.is_anonymous in a template, you assume that if it's false
then the user is logged in, where in actual fact "user" may just not be
getting passed to context. It seems a pretty dangerous assumption to
make.


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: would is_loggedin be better than is_anonymous?

[SmileyChris]

I like it too.

To attone for my duplicate thread, I have created a ticket and patch
for this.
http://code.djangoproject.com/ticket/2332

I'm not sure how you "declare is_anonymous as depreciated", Malcom so
I'll leave that to you ;)


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: would is_loggedin be better than is_anonymous?

[SmileyChris]

Yea, I'm not really that sold on .is_loggedin() either... some
alternatives:

.is_real_user()
.is_known()


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: would is_loggedin be better than is_anonymous?

[SmileyChris]

I think we still need the AnonymousUser and from the number of
references to is_anonymous in python modules I think we still need a
negation of it.

So how can we work towards a consensus on the best name for a function
which is the negative of is_anonymous?

On a side note, in templates I don't think you can actually do {% if
user.has_perm('myperm') %} anyway.


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: would is_loggedin be better than is_anonymous?

[SmileyChris]

Gary Wilson wrote:
> I think I now vote for is_authenticated since the is_loggedin versions
> could more easily be taken the wrong way (by trying to lookup all users
> who are logged in).  I would be less inclined to try and lookup all
> users who are authenticated.  Make any sense?

Makes sense to me. And I agree that is_loggedin is definately the wrong
name.
Unless someone else suggests something better, my vote is for
is_authenticated too.

I was also keen on Malcom's idea of just using user.id but on further
thought it seems a bit implicit. Explicit is good, right?


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: would is_loggedin be better than is_anonymous?

[SmileyChris]

Hrm...
Will there ever be a difference between "user.is_anonymous" and "not
user.is_authenticated"?
If not (and I can't think of a reason), do we really need to keep
is_anonymous?


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: would is_loggedin be better than is_anonymous?

[SmileyChris]

As long as you're using RequestContext however, the user would always
either be an anonymous user or an authenticated user.
But I guess you don't have to use RequestContext, therefore I'm
answering my own question...

So Adrian (or other submitters), do you need any more work done to
Gary's patch or can you work it from there? I guess if someone who's
good with their English wants to provide a patch for the documentation
then that would be a help.


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Auto-escaping patch

[SmileyChris]

Great job on the patch, Malcom!
I posted this in the ticket, then felt guilty because you told me not
to. So I'll post here for discusion.

A couple of points:
If a markup filter fails due to an import error, I don't think it
should be marked as safe.
>From a skim read of the patch, I'm missing the purpose of having an
.is_safe property on filters - can't you just check the outputted
string to see if it's SafeData?


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Auto-escaping patch

[SmileyChris]

Malcolm Tredinnick wrote:
> On Mon, 2006-07-17 at 03:30 -0700, SmileyChris wrote:
> > A couple of points:
> > If a markup filter fails due to an import error, I don't think it
> > should be marked as safe.
>
> Why not? The returned result is the empty string in that case and
> there's certainly no danger of that being presented in the raw.

By the way, I just went and checked this for markup.
An unfinalized string is returned (not an empty string). So I still
think it shouldn't be marked as safe on an import error.


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Auto-escaping patch (terminology)

[SmileyChris]

> 'escape' and 'safe' have a different meaning for fireworkers, too ;-)
Or bank robbers :-P

Back on topic, I like finalization too (even though I cringe having to
write the american Z version).


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

A working PasswordField patch

[SmileyChris]

I got sick of waiting so attempted it myself.
http://code.djangoproject.com/ticket/61

It all works for me, the only thing it needs is some tests and work on
the "rel" stuff (which is used if it's used with edit_inline I think?).
But it is a complete working patch, feel free to test it out / submit
feedback.


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Where escaping belongs

[SmileyChris]

I have been thinking about where escaping belongs recently and maybe my
logic is all wrong but I'll write down some of my thoughts.

This is a related thread to the ones about auto-escaping but I have a
specific discussion I wish to persue. And it's not really limited to
"auto" escaping so bear with me.

>From an earlier thread:
> > Alternative, do it in the view code:
>
> Eh. Not crazy about that; escaping belongs in the template layer, and
> having it able to be set from anywhere else gets us into nastiness as
> people try to figure out, in the template, whether the view turned
> escaping on or not.

I agree that escaping should probably just happen in one place.

1. Technically, the view decides how a template is going to be
displayed, not the template itself. Could the view, therefore, be the
best place for escaping to happen?

2. The only things that really ever need escaping are variables passed
to the template (most likely from a view). Why should the template
author have to define whether these  variables passed from another
layer should be escaped?

3. The idea of a "template" is DRY. If I wanted to use a template block
in several views for an email, an html page and a javascript block, I
should be able to use just the one template. Wouldn't then this make
more sense for the view to determine any necessary escaping for
variables?


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Where escaping belongs

[SmileyChris]

James Bennett wrote:
> The view decides which template to use, and what variables will be
> made available to the template, but that's not really the same thing;
> the question here is "which layer of Django decides what the actual
> output bits will be that go over the wire?" And the answer is mostly
> the template, because that's where the output is structured and
> coddled and worked into whatever form is desired.

Thanks for the replies to my questions, James. That clears a lot up in
my head - obviously I was looking at the order of things a bit skewed.

> What happens when someone uses a simple template tag to add variables
> to the context that weren't supplied by the view? If nothing else,
> that seems to be the death knell for escaping controls in the view,
> because then we'd have to go down a DRY-violating road of "remember to
> turn on escaping in your view *and* remember to turn on escaping in
> your template tags".

I see your point with this breaking DRY.

So if DRY *is* a major priority then say I am writing an project that I
know will be outputting to HTML 99% of the time. Having to turn on
escaping on every template (or worse, every tag!) seems quite a
"repetitious" task.
I guess then it becomes an argument between DRY vs Explicitness. So is
explicit > DRY?

> No. Again, the template is what decides how the output will actually
> look

My only disagreement with this is that you may be using a template
block in several contexts with an {% include %}

Ahmad, thanks for your input too. I see that it's probably best to
leave this in the hands of the template itself.

Regarding doing a "security audit", assuming you had some method of
defining the default escaping (if any) it would seem easier and safer
to audit if you were looking for cases where you didn't need to escape
(the more rare case). But this is getting back to the main auto-escape
discussion.

Coming back to my DRY vs explit thoughts. Maybe it's still too
implicit, but I would be happy if you could just specify your {% escape
html %} block (in whatever format it ends up in) in your base template
as opposed to doing it in every single template.


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Akismet needs a dunce hat

[SmileyChris]

Trying to mark http://code.djangoproject.com/ticket/2478 as spam but I
get rejected. Go Akismet.


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Akismet needs a dunce hat

[SmileyChris]

It's been closed now, but any reason why I can't comment in Trac now?


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Pagination

[SmileyChris]

Hi Mike,

In case you are interested, I wrote a ticket that (in addition to
adding some other paginator functionality) provides a PaginatorPage
object which is a wrapper for a specific page.
http://code.djangoproject.com/ticket/2093

I just updated it to provide some useful properties: next_page_number
and previous_page_number - thanks for the idea.


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Session support

[SmileyChris]

I think you meant "I used property() so you can use
request.session.expires = 213123. "

I wouldn't worry about the smart times -- just having seconds is good
enough.


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Safe settings context processor

[SmileyChris]

Way back in ticket http://code.djangoproject.com/ticket/1278, Adrian
declared that a settings context processor was not going to happen. The
reason being that it could give template authors direct access to the
db password / secret key.

Recently I coded up
http://code.djangoproject.com/wiki/SafeSettingsContextProcessor, which
uses the same get_safe_settings which the debug error page shows.

Is this still too dangerous? As long as it's off by default, isn't it
safe enough?

On a side note, most people just want access to media_url, so I
actually would be happy with just
http://code.djangoproject.com/ticket/2532. Every web site wanting to
use static CSS will need to access this variable somehow, won't they?
Otherwise it has to be hard coded and that's not very Djangoish...


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Safe settings context processor

[SmileyChris]

Ok, I agree that if we start putting individual settings it will lead
to a bit too much pollution.

But Ivan, you need to access the STYLE_URL setting. Having access to
settings via SafeSettings could be useful still, right?


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Default escaping -- again!

[SmileyChris]

James Bennett wrote:
> On 7/28/06, Roland van Laar <[EMAIL PROTECTED]> wrote:
> > Would it be better to couple it with the mimetype? A text/plain should
> > by default not be excaped.
>
> What would be *best* is for there to be no magical implied
> escaping/unescaping of anything, only explicit escaping/unescaping
> based on a template tag.

Like this:
http://code.djangoproject.com/wiki/AutoEscape%20alternative ?


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Filters no longer parsed for unresolved variables

[SmileyChris]

Changeset [3268] made the following change for the resolve method in
django/template/__init__.py:
-obj = settings.TEMPLATE_STRING_IF_INVALID
+if ignore_failures:
+return None
+else:
+return settings.TEMPLATE_STRING_IF_INVALID

Because the TEMPLATE_STRING_IF_INVALID is returned now rather than
being set in obj (which is then passed to any filters), the filters are
not parsed on an unresolved variable which changes the behaviour of the
default and default_if_none filters.

I believe the last line of that patch should have been:
+obj = settings.TEMPLATE_STRING_IF_INVALID

but I just wanted to check that the functionality change isn't intended
first.


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Filters no longer parsed for unresolved variables

[SmileyChris]

Guess I should just make a ticket anyway:
http://code.djangoproject.com/ticket/2637


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Filters no longer parsed for unresolved variables

[SmileyChris]

Hi Russ,

Thanks, that explains the problem with my patch perfectly :)
Your solution looks great: it still solves the original problem while
bringing back the correct functionality if TEMPLATE_STRING_IF_INVALID
is not set.

I can't see that you've missed anything (but then again, I didn't
manage to get it right on my attempt so don't trust me) ;)

This should be documented under the settings page to explain that if
you set TEMPLATE_STRING_IF_INVALID to be non-empty, filters will be not
be processed on variable tags where the variable is not found in the
template context.


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

App portability

[SmileyChris]

When moving an app to a different project, I had to go through and fix
all the references to my project name in code. Is there a better way to
import my code? Currently I import like:

from projectname.appname.models import Model

It seems like this inhibits portability of apps somewhat. Perhaps there
could be some sort of "from django.conf import settings" for apps?


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Are non-critical patches getting enough attention?

[SmileyChris]

I greatly appreciate the hard work of the current committers, but I am
starting to wonder if there are too few of them to handle the number of
tickets being entered into Trac.

Closed tickets with resolution of fixed: 1382 (invalid, wontfix,
duplicate or worksforme: 699)
Open tickets: 501
Open tickets with Adrian as the owner: 419

I don't want to come across as a whiner, I just feel that this is a
question that should be asked routinely as a project grows.


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Are non-critical patches getting enough attention?

[SmileyChris]

Malcolm Tredinnick wrote:
> Raw statistics like this can be misleading and I think they are in this
> case. Yes, it's slightly disappointing to see the number creep up from
> month to month, but it's not a tragedy. Django still works, it's still
> usable in serious applications.
I agree it's still usable and working (and that my statistics can be
taken quite out of context), my focus was on the littler patches which
often aren't breaking anything. I think that part of the problem is
that Trac does little to determine the eligibility of some of these
patches (without requiring "telepathy" from committers).

> Since about half the tickets filed that have been closed are not
> actually requiring fixes, it's not crazy to think that the average
> carries across in part to the the currently open tickets as well.
Slight correction, 1/3 of closed tickets are marked invalid, wontfix,
duplicate or worksforme. And like you say, I'm not sure you can carry
that average across still opened tickets.

> Thirdly, the "Adrian as owner" measure is really bogus. The bulk of
> components have Adrian as the owner. I've mentioned in the past that I
> wouldn't mind if we had a generic user as the default owner to avoid
> that misperception, but it's hardly a real problem once you're aware of
> it.
I admit this was a bit cheeky to put in. What I was trying to get at by
this number is that these are roughly the number of unassigned tickets
- quite a large number.

> I should pull out some of the GNOME and Fedora bug
> triaging guidelines and tailor them to Django's work practices so that
> more people can start helping out there. A "bug squad" of triagers never
> hurts.
That sounds like a great idea.

Thanks for the reply, Malcom. I'm interested in what other people have
to say on the issue, especially any ideas of any way to streamline the
Django "defect/enhancement -> commit" process.


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Comment on auto-escaping proposals

[SmileyChris]

This suggestion was dismissed pretty fast last time it brought up. I
don't think this is the direction that the Django developers want to go
down.

Have you checked out my AutoEscaping alternative?
(http://code.djangoproject.com/wiki/AutoEscape%20alternative#SuggestedSolution)
It's simple and effective ;)


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Patches, Tests and All the Rest (was: Ticket #648 -- {# comment goes here #} style comments)

[SmileyChris]

Michael Radziej wrote:
>  I'd appreciate if we could find a
> way to state what kind of patches are interesting for the
> committers and what not *before* the patch is created fully. This
> is of course more important for large patches.

I think this is the core of my underlying concerns of how the tickets
are handled currently. To use GTD terminology, there does not seem to
be distinct lines between what is in the Inbox, Someday/Maybe, Waiting
and Next Actions containers.


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Ticket #648 -- {# comment goes here #} style comments

[SmileyChris]

Back on topic, check out my alternative that I thought may appease the
Django gods if they are so outraged by adding another tag type.
http://code.djangoproject.com/ticket/2721


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Serious problems with the way Django handles file uploads

[SmileyChris]

I can't get 2070 to work either. I found
http://code.djangoproject.com/ticket/2613 which fixed up my uploading
problems (at least on the dev server) - have you tried that one?


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: I can't mark a ticket as having a patch.

[SmileyChris]

Seems I've been bitten (again) too by the akismet snake. Grr...


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Let windows users run the test suite

[SmileyChris]

I just uploaded a patch to allow windows users to run the test suite:
http://code.djangoproject.com/ticket/2099

I would mark as [patch] but Akismet won't let me (I've emailed Tom for
another whitelist).


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Can I respond to table cell mouse clicks without using JavaScript?

[SmileyChris]

Using CSS you could make your  tag a block tag with 100% width. This
way, the whole cell will be filled with the tag, so you can click
anywhere in it.


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: models.PasswordField

[SmileyChris]

Unfortunately it has only changed for creating new users, not editing
the password of existing ones.


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

BooleanFields should default to False

[SmileyChris]

I posted the ticket http://code.djangoproject.com/ticket/2855, but just
wanted to make sure it makes sense to the developers.

My test models:

from django.db import models
class TestCharModel(models.Model):
testchar = models.CharField()
class TestBoolModel(models.Model):
testbool = models.BooleanField()

Let's test creating the char model with no parameters:

>>> from testapp.models import TestModel
>>> t = TestModel()
>>> t.save()
>>>

Ok, so that should work for the bool model too, right? Wrong:

>>> from testapp.models import TestModel
>>> t = TestModel()
>>> t.save()
Traceback (most recent call last): 
ProgrammingError: ERROR:  invalid input syntax for type boolean: ""
INSERT INTO "testapp_testmodel" ("testfield") VALUES ('')

So, it seems obvious enough that a BooleanField should default to False
rather than return an empty string. What does an empty string mean in
terms of a BooleanField anyway? I'd assume False :)


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: BooleanFields should default to False

[SmileyChris]

Don Arbow wrote:
> No, a BooleanField should not default to False, the default should be
> application specific. If you want a default value, specify it in your
> model definition.
I don't have to specify a default value of an empty string for my
CharField. Why should I have to specify a default of False for my
BoolField?

> If you read the comments about models under null
> , it reads:
>
> "Note that empty string values will always get stored as empty
> strings, not as NULL -- so use null=True for non-string fields such
> as integers, booleans and dates."
This is a bit out of context. If I wanted NULL, I'd use a
NullBooleanField.

> That way, if you don't provide a value for a boolean, it is stored as
> null, not as an empty string (nor converted to False).
Again, I don't want it stored as null. I *do* want it stored as False,
and an empty string makes no sense.


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Branch Merges?

[SmileyChris]

On Nov 8, 6:39 am, Michael Radziej <[EMAIL PROTECTED]> wrote:
> Let's have a branch of the month, announced on devel and users. The
> branch is then frozen, merged with trunk, and will be merged at a fixed
> date into trunk if no critical and unfixable bugs are found. This would
> encourage at least me to check this branch out and test it well before
> the merge ;-)
> 
> Michael

+1


--~--~-~--~~~---~--~~
 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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Fix for timezone bug in development server (using a Windows environment)

[SmileyChris]

I have created a patch for this pesky bug.
http://code.djangoproject.com/ticket/2315

It's pretty much a one-liner fix, so could a committer please review
and submit?


--~--~-~--~~~---~--~~
 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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Newforms: verbose_name

[SmileyChris]

It would be nice to have a verbose_name option for fields in newforms
for when you want an alternate to the magical pretty_name. I've been
trying to think about where best to put a it.

The end goal is that BoundFields have verbose_name property which can
return the verbose name or fall back to the pretty_name function.

Currently, Fields are decoupled from their name, so would it be wrong
to attach it like this?
... agent_phone = DateField(verbose_name="Agent's phone number")


--~--~-~--~~~---~--~~
 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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Newforms: seperating database and form logic

[SmileyChris]

It seems like a great opportunity as newforms develops to clean up the
database fields mess. Most of the arguments you pass a database field
are not related to the database.

Is this part of the goal of newforms, or am I thinking too big?

With newforms, we can just have one optional argument (form_field)
which references a (new)form Field which contains all the validation
and form-relevant arguments.

The problem is going to obviously be a huge backwards compatibility
issue. Perhaps the new database fields could live somewhere else (like
to django.db.fields), and the old fields are used as a wrapper for the
new ones?

>From the current django.db.models.fields.Field __init__ arguments,
these are the actual database-relevant fields (as far as I can tell)
- name
- primary_key
- maxlength
- unique
- null
- db_index
- rel
- default
- db_column

The ones that would be taken out (functionality moved to newforms
Field):
- verbose_name
- blank
- core
- editable
- prepopulate_from
- unique_for_date
- unique_for_month
- unique_for_year
- validator_list
- choices
- radio_admin
- help_text

This leads on to relationships between fields: how do we then handle
edit_inline?
Something similar to the idea proposed in
http://code.djangoproject.com/ticket/2248 could work.

So that's enough to chew on. Thoughts?


--~--~-~--~~~---~--~~
 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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: How to run all django tests?

[SmileyChris]

Hi Rob,

Below are instructions for Windows (replace the items in square
brackets). If you're using *nix, I'm sure you can figure out the
equivalent ;)

set DJANGO_SETTINGS_MODULE=[projectname].settings
set PYTHONPATH=[django_projects_folder]
python runtests.py

On Nov 17, 1:33 pm, "Rob Hudson" <[EMAIL PROTECTED]> wrote:
> I was just playing with trying to run the tests this morning as well.
> Doing "python runtests.py" in the django/tests directory gives me an
> error about the DJANGO_SETTINGS_MODULE.  I couldn't figure out what
> needed to be in my environment setting to get the tests to work.
>
> Searching Google didn't turn up anything either.
> 
> How do you run the tests?


--~--~-~--~~~---~--~~
 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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: proposal: get_or_none QuerySet method

[SmileyChris]

On Dec 19, 11:08 am, "Waylan Limberg" <[EMAIL PROTECTED]> wrote:
> something like this:
>
> user = User.objects.get(pk=user_id, default=None)

Except this would break (or at least limit the functionality of)
objects which use "default" as a field name.


--~--~-~--~~~---~--~~
 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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Changing user passwords in admin

[SmileyChris]

Although the new user form was a good start, it wasn't really a
complete solution to ticket 61 (auth.User admin form shouldn't require
people to edit hashes)

I wrote up a form which allows staff members (with correct permissions)
to change user passwords: http://code.djangoproject.com/ticket/3166

Please check it out, and provide feedback.

I wasn't sure where exactly to put the link to the form so it's in the
help_text on the password field (seemed the easiest way).


--~--~-~--~~~---~--~~
 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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: newforms: feedback

[SmileyChris]

On Dec 27, 1:43 pm, limodou <[EMAIL PROTECTED]> wrote:

I'd like a dict to hold the default values, so we can get then from a
instance or somewhere easily, but not set each field a default value.
for example, the new forms __init__.py can has a defaultvalues
parameter is a dict. When it will be rendered, it'll check the data,
if the data is None, so it'll use defaultdata.


I like this idea a lot. Perhaps 'default_data'.


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

newforms: strange bug with errors

[SmileyChris]

I have a template tag to output a field with my format. It seems to
have stopped working since the BaseForm/Form seperation

def form_line(field):
   output = []
   output.append(field.label_tag())
   for error in field.errors:
   output.append('%s' %
escape(error))
   output.append(str(field))
   return ' '.join(output)

Following is the traceback which I'm getting. Some initial test seems
that self.form is getting weirded up - In the last call of the
traceback, self.form resolves to  which doesn't seem right.

Traceback (most recent call last):
File "D:\Web\Python24\lib\site-packages\django\template\__init__.py" in
render_node
 712. result = node.render(context)
File "D:\Web\Python24\lib\site-packages\django\template\__init__.py" in
render
 845. return func(*resolved_vars)
File "D:\Web\Django\projects\upstage\personal\templatetags\forms.py" in
form_line
 9. for error in field.errors:
File "D:\Web\Python24\lib\site-packages\django\newforms\forms.py" in
_errors
 213. return self.form.errors.get(self.name, ErrorList())

 AttributeError at /manage/
 'function' object has no attribute 'get'


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

newforms: strange bug with errors (solved)

[SmileyChris]

Hrm... pretty obvious now. I was using my own base form class
overriding the Form class instead of BaseForm.

On Dec 27, 10:51 pm, "SmileyChris" <[EMAIL PROTECTED]> wrote:

I have a template tag to output a field with my format. It seems to
have stopped working since the BaseForm/Form seperation

def form_line(field):
output = []
output.append(field.label_tag())
for error in field.errors:
output.append('%s' %
escape(error))
output.append(str(field))
return ' '.join(output)

Following is the traceback which I'm getting. Some initial test seems
that self.form is getting weirded up - In the last call of the
traceback, self.form resolves to  which doesn't seem right.

Traceback (most recent call last):
File "D:\Web\Python24\lib\site-packages\django\template\__init__.py" in
render_node
  712. result = node.render(context)
File "D:\Web\Python24\lib\site-packages\django\template\__init__.py" in
render
  845. return func(*resolved_vars)
File "D:\Web\Django\projects\upstage\personal\templatetags\forms.py" in
form_line
  9. for error in field.errors:
File "D:\Web\Python24\lib\site-packages\django\newforms\forms.py" in
_errors
  213. return self.form.errors.get(self.name, ErrorList())

  AttributeError at /manage/
  'function' object has no attribute 'get'



--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

newforms: apply_changes

[SmileyChris]

It seems like the newly added apply_changes method (to
form_for_instance) could be useful in other cases too if it was a bit
more "open-minded".

I don't see why apply_changes should bother about creating a field list
again when that has already been done in form_for_instance. Can't it
just use the fields in the Form?

How about if form_for_instance just set something like
`default_instance` for the form and apply_changes was made available to
all Forms. New method for BaseForm:

def apply_changes(self, instance=None, save=True):
   if not instance:
   instance = getattr(self, 'default_instance', None)
   if not instance:
   raise ValueError('An instance is required')
   for field in self.fields.keys():
   setattr(instance, f.attname, clean_data[f.name])
   if save:
   instance.save()
   return instance


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: newforms: apply_changes

[SmileyChris]

On Dec 29, 6:57 pm, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:

This wouldn't work, because self.fields is a dictionary of newforms
Field objects, *not* database Field objects. The "f.attname" wouldn't
be available.


It was just concept code to see if there was any merit in the idea. If
you think there is a benefit still then I can write up a proper patch.

It still would work - you could get the _meta from the model of the
passed instance and compare f.name to find the matching database field.


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: newforms: apply_changes

[SmileyChris]

Patch created: http://code.djangoproject.com/ticket/3232

On Dec 30 2006, 8:45 am, "SmileyChris" <[EMAIL PROTECTED]> wrote:

On Dec 29, 6:57 pm, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:

> This wouldn't work, because self.fields is a dictionary of newforms
> Field objects, *not* database Field objects. The "f.attname" wouldn't
> be available.It was just concept code to see if there was any merit in the 
idea. If
you think there is a benefit still then I can write up a proper patch.

It still would work - you could get the _meta from the model of the
passed instance and compare f.name to find the matching database field.



--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Autoescaping for 1.0

[SmileyChris]

Rather than clog up the main "1.0" discussion, let's move this to a
side discussion.

We need to come to a consensus on Django autoescaping - I'll put in my
2c for my alternative
(http://code.djangoproject.com/wiki/AutoEscape%20alternative) of
course, but whichever direction we go, it'd be good to actually start
going there.

Questions off the top of my head:

How "auto" is autoescaping going to be? If I recall, previous consensus
seemed to be off by default, easy to switch on.

Are we only worried about HTML autoescaping? (as opposed to JS or any
other escaping people may want)


--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---