>Great; this is exactly what I had in mind. As far as I'm concerned,
>once these changes are done I'm ready to roll this in, but let's wait
>and see what Adrian's thoughts are before we make any final decisions.
Since Adrian was one of the others in the IRC discussion, I at least
can commit the
On 3-11-2005, at 12:24, hugo wrote:
Since Adrian was one of the others in the IRC discussion, I at least
can commit the changes to the i18n branch, so you can have a look at
it. :-)
I found some bugs in templatetags/i18n.py, patch is posted in http://
code.djangoproject.com/ticket/719
---
All sounds good.
>
> {% blocktrans count list|count as counter with var|filter as newvar %}
^
"with", surely?
> This is only one {{ newvar }} object
> {% plural %}
> These are {{ counter }} {{ newvar }} objects
> {% endblocktrans %}
On 3-11-2005, at 12:24, hugo wrote:
Since Adrian was one of the others in the IRC discussion, I at least
can commit the changes to the i18n branch, so you can have a look at
it. :-)
Updated, little search&replace, all worked fine (except bug I
mentioned earlier), in admin and in all of my p
>> {% blocktrans count list|count as counter with var|filter as newvar %}
>^
> "with", surely?
Where? The two "subtags" are 'count' and 'with' - the 'count' subtag is
followed by an expression and a 'as variable' thingy and will just
store it in the context and use it as the n
hugo wrote:
>>>{% blocktrans count list|count as counter with var|filter as newvar %}
>>
>> ^
>>"with", surely?
>
>
> Where? The two "subtags" are 'count' and 'with' - the 'count' subtag is
> followed by an expression and a 'as variable' thingy and will just
> store it in the c
>There one problem left: filters use the _() syntax for their >parameter
>string (for example yesno is a candidate for a translated >parameter) to
>mark their parameter string for translation.
Another place where we will need to have the _("...") syntax for
strings to be translated is in template
Hi Adrian and others. I am finding I can work with Django with minor
changes in my project organization as Adrian had indicated.
I eliminated the apps folder to make my structure more understandable
since an app can be made directly in the root of the project folder.
Should I expect any sid
On 11/3/05, David Pratt <[EMAIL PROTECTED]> wrote:
> I eliminated the apps folder to make my structure more understandable
> since an app can be made directly in the root of the project folder.
> Should I expect any side effects from this? So far it is doing what I
> expect.
Nope, there shouldn'
Many thanks Adrian. I am really please for what this will mean to
simplify my SQL development. Thank you for a really nice api that is
very dynamic.
Regards,
David
On Thursday, November 3, 2005, at 01:52 PM, Adrian Holovaty wrote:
On 11/3/05, David Pratt <[EMAIL PROTECTED]> wrote:
I eli
1. Is it possible to execute the sqlreset or sqlclear statement
through django-admin (opposite of django-admin install) I haven't found
a django-admin drop or an django-admin reset at this point and don't
see anything in the management.py to indicate this is possible. Should
I write this cod
On 11/3/05, David Pratt <[EMAIL PROTECTED]> wrote:
> 1. Is it possible to execute the sqlreset or sqlclear statement
> through django-admin (opposite of django-admin install) I haven't found
> a django-admin drop or an django-admin reset at this point and don't
> see anything in the management.py
On Thursday, November 3, 2005, at 04:42 PM, Adrian Holovaty wrote:
On 11/3/05, David Pratt <[EMAIL PROTECTED]> wrote:
1. Is it possible to execute the sqlreset or sqlclear statement
through django-admin (opposite of django-admin install) I haven't
found
a django-admin drop or an django-ad
On 11/3/05, David Pratt <[EMAIL PROTECTED]> wrote:
> Anyway, let me know what you think so I can get started.
>
> django-admin sqlinit mymodel * new method
> django-admin init mymodel current - no name change
>
> django-admin sqlcreate mymodel (instead of django-admi
Hi.
On Thursday, November 3, 2005, at 06:37 PM, Adrian Holovaty wrote:
On 11/3/05, David Pratt <[EMAIL PROTECTED]> wrote:
Anyway, let me know what you think so I can get started.
django-admin sqlinit mymodel * new method
django-admin init mymodel current - no name c
Hi Hugo, everyone,
Sorry for the reply to such an old e-mail - I dug it out after coming
across problems while developing my own middleware.
> They can have allmost any order you like, but you have to make sure
> that the cache middleware is after all middlwares that might change
> content depen
Hi,
I realised that in google's interface, this post is buried several
pages down, so I'm reposting it as a new thread.
Luke
---Begin forwarded message:-
Date: Fri, 4 Nov 2005 01:07:45 +
From: Luke Plant <[EMAIL PROTECTED]>
To: django-developers@googlegroups.com
Subject:
Hi,
I've created a generic CSRF solution for Django, implemented as a
middleware. It does two things:
1) modifies outgoing requests by adding a hidden form field to all
'POST' forms, with name 'csrfmiddlewaretoken' and a value which is a
hash of the session ID plus a secret (this is not done if t
Hi Luke.
This is a really great idea.
I've just got a small nit with it.
by doing this you would disable/stop post's coming from via
javascript/ajax method.
it wouldn't be able to access the tokens required, or at the very
least it would require a form tag to be someone on the HTML page which
is
Howdy --
I've merged the i18n branch into the trunk; major thanks are due to
hugo! I'm running it live on all the LJW sites and it works fine,
but there could be some lurking issues, so caveat programmer. Adrian
will have a blog post on the matter some time in the next day or two
(he's
20 matches
Mail list logo
