Luke Plant wrote:
> Hi all,
>
> I've had a number of people suggest that the Cross Site Request Forgery
> protection middleware I wrote a while back should go in Django's
> contrib section, and if I recall correctly Adrian was enthusiastic
> about this happening at some point, but it hasn't ac
+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]
On 4/15/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> Any huge objections?
+1 from me.
-0 on the 'default' lookup option proposed. The only benefit I can see
to having the extension optional is during the 0.91->MR transition
phase, where you have template calls that haven't been updated.
R
+1 on the original proposal
-0 on making it an optional setting
--
Petar Marić
*e-mail: [EMAIL PROTECTED]
*mobile: +381 (64) 6122467
*icq: 224720322
*skype: petar_maric
*web: http://www.petarmaric.com/
--~--~-~--~~~---~--~~
You received this message because you a
Op vr, 14-04-2006 te 14:37 -0500, schreef Adrian Holovaty:
> What do you think of the idea (proposed by Luke Plant here:
> http://code.djangoproject.com/ticket/500 ) to remove the
> TEMPLATE_FILE_EXTENSION setting, so that you'd have to specify ".html"
> in each get_template() call?
+1
--
Jan
Hi all,
I've had a number of people suggest that the Cross Site Request Forgery
protection middleware I wrote a while back should go in Django's
contrib section, and if I recall correctly Adrian was enthusiastic
about this happening at some point, but it hasn't actually happened.
I'm prompted
Eugene Lazutkin <[EMAIL PROTECTED]> writes:
> Nebojsa Djordjevic wrote:
>>>
>>> Any huge objections?
>>
>> No, +1 from me.
>>
>> Maybe this can be made optional somehow.
>
> Me too. :-) I like it but I want it to be optional with "*.html" as
> default.
On the original proposal: +1, It makes thi
Nebojsa Djordjevic wrote:
>>
>> Any huge objections?
>
> No, +1 from me.
>
> Maybe this can be made optional somehow.
Me too. :-) I like it but I want it to be optional with "*.html" as default.
Thanks,
Eugene
--~--~-~--~~~---~--~~
You received this message b
Nebojsa Djordjevic wrote:
>>
>> Any huge objections?
>
> No, +1 from me.
>
> Maybe this can be made optional somehow.
Me too. :-) I like it but I want it to be optional with "*.html" as default.
Thanks,
Eugene
--~--~-~--~~~---~--~~
You received this message b
Adrian Holovaty wrote:
> What do you think of the idea (proposed by Luke Plant here:
> http://code.djangoproject.com/ticket/500 ) to remove the
> TEMPLATE_FILE_EXTENSION setting, so that you'd have to specify ".html"
> in each get_template() call?
>
> I like it, because it solves the problem of w
On 4/12/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
> the sessions middleware does not support some cookie settings I'd prefer
> for security, especially since the authentication middleware depends on it:
>
> - secure flag (i.e., if a cookie has been received via SSL, only send it
> over SSL)
>
What do you think of the idea (proposed by Luke Plant here:
http://code.djangoproject.com/ticket/500 ) to remove the
TEMPLATE_FILE_EXTENSION setting, so that you'd have to specify ".html"
in each get_template() call?
I like it, because it solves the problem of wanting to use other
extensions, and
Viktor wrote:
> James Bennett wrote:
>> Even when I copy/paste that URL (which I had to do, because my
>> web-based email client didn't recognize that the Cyrillic portion of
>> it was part of the URL) into Firefox, the URL encoding turns
>> "��_��" into
>> "%D0%93%D0%BB%D0%B0%D0%B2%D0%BD%
On 4/14/06, Jeroen Ruigrok van der Werven <[EMAIL PROTECTED]> wrote:
> I would sooner blame your setup or software for not properly
> supporting such links.
The thing is, this *is* "proper support". The URL is still accessed
correctly, and the page is displayed correctly. But the URL string
itsel
On 4/14/06, James Bennett <[EMAIL PROTECTED]> wrote:
> Which is a problem, because really the whole idea behind a URL slug is
> to provide some useful information about the page which lives at that
> URL. But a long string of URL-encoded characters doesn't convey any
> more useful information than
On 4/13/06, Viktor <[EMAIL PROTECTED]> wrote:
> We tested utf-8 urls against ie, opera and konqueror and they work
> great. Firefox by default shows the urls urlencoded, but you can change:
> network.standard-url.escape-utf8 to false
> and it will show the url in original encoding.
Using t
On 4/14/06, oggie rob <[EMAIL PROTECTED]> wrote:
>
> I would rather see some ability to add variables when
> render_to_response is hit. In other words, rather than using the
> proposed mechanisms above to create a unique template, I think it would
> be more usable if you were to say:
>
> def my_ad
On Apr 13, 2006, at 10:34 PM, James Bennett wrote:
> Which is a problem, because really the whole idea behind a URL slug is
> to provide some useful information about the page which lives at that
> URL.
And if your users aren't speakers of languages that are normally
represented in ASCII text,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Russell Keith-Magee wrote:
> I haven't looked too hard yet, but as a patch, it looks good. A
> _fantastic_ patch would also have unit test, but there aren't any unit
> tests for the existing DB datatypes, so I'll let you off the hook :-)
> A Documenta
Ivan Sagalaev wrote:
> And in
> case of Firefox am I supposed to stick a big red banner on start page
> saying "To see this page properly in your browser go to
> about:config..."? :-)
>
as i understand, that's not required. firefox will correctly go to the
required url. it just will display i
James Bennett wrote:
> Even when I copy/paste that URL (which I had to do, because my
> web-based email client didn't recognize that the Cyrillic portion of
> it was part of the URL) into Firefox, the URL encoding turns
> "��_��" into
> "%D0%93%D0%BB%D0%B0%D0%B2%D0%BD%D0%B0_%D1%81%D1%82%D1
in fact, since I've rolled back to a 3 days old version I no longer
need to do this modification.
If it happens again wih a fresher svn update I will let you know.
Now I'm convinced that we need Dojo, I will help as much as I can.
--~--~-~--~~~---~--~~
You recei
in fact, since I've rolled back to a 3 days old version I no longer
need to do this modification.
If it happens again wih a fresher svn update I will let you know.
Now I'm convinced that we need Dojo, I will help as much as I can.
--~--~-~--~~~---~--~~
You recei
James Bennett wrote:
>Even when I copy/paste that URL (which I had to do, because my
>web-based email client didn't recognize that the Cyrillic portion of
>it was part of the URL) into Firefox, the URL encoding turns
>"çÌÁ×ÎÁ_ÓÔÒÁÎÁ" into
>"%D0%93%D0%BB%D0%B0%D0%B2%D0%BD%D0%B0_%D1%81%D1%82%D1%80%
On 4/14/06, oggie rob <[EMAIL PROTECTED]> wrote:
> There was talk of processors that could possibly/probably do a cleaner
> job than this - not sure where these stand.
http://www.djangoproject.com/documentation/settings/#template-context-processors
--
"May the forces of evil become confused on t
25 matches
Mail list logo
