Re: Goodbye, Malcolm

[Antoni Aloy]

R.I.P. Malcolm, Thanks for all you've done for the community.


2013/3/21 Meir Kriheli <mkrih...@gmail.com>

> RIP Malcolm :-(
>
>
> On Tue, Mar 19, 2013 at 11:57 PM, Val Neekman <v...@neekman.com> wrote:
>
>> Met him for the first time in DjangoCon 2012. What a down to earth guy.
>>
>> He'll be missed.
>>
>> Val
>> Sent from my mobile device.
>>
>> On 2013-03-19, at 3:25 PM, Leon Matthews <pyt...@lost.co.nz> wrote:
>>
>> > On 20 March 2013 06:01, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
>> >> We have difficult news: Malcolm Tredinnick has passed away.
>> >
>> > What a shock.  Malcolm was a great guy, and a huge asset to our
>> > community.  I had the pleasure of hearing him talk in Wellington.
>> >
>> > He will be missed...
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups "Django developers" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an email to django-developers+unsubscr...@googlegroups.com.
>> > To post to this group, send email to django-developers@googlegroups.com
>> .
>> > Visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>> > For more options, visit https://groups.google.com/groups/opt_out.
>> >
>> >
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>
> --
> Meir Kriheli
> http://meirkriheli.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>



-- 
Antoni Aloy López
Blog: http://trespams.com
Site: http://apsl.net

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

Re: RFC: issue 13617

[Antoni Aloy]

+1 On solving this issue, it's a real problem dealing with js

El 24/10/2010 19:29, "Benjamin Wohlwend"  escribió:

Hi,

I reported #13617[1] a couple of months ago, and today Justin Bronn
committed a fix for it. Unfortunately, the fix doesn't solve my issue
(which I failed to describe correctly in the issue report, so the
blame is on me) nor does it address a larger problem that I described
in the ticket with the current l10n handling of numbers:

Django's handling of localization of numbers in templates may result
in undesired output with some locales. When rendering structured
content like JavaScript, it generates output that may be syntactically
or semantically incorrect, e.g.:

   var num = {{ 2.5 }};

is rendered as "var num = 2,5;" (note the decimal separator) using the
locale "de-de".

. AFAIK, there are only two work arounds:

 * completely deactivate l10n
 * convert every floating point number to a string in the view layer,
using a suitable locale

My proposal is to introduce a block tag that temporarily deactivates
l10n for the enclosed fragment. See the patch I attached to the
ticket.

Two other tickets (#14181, #14164) are manifestations of this issue.
Unfortunately, I found them only after writing the patch. I like the
tags proposed in #14181 better than my `{% noloc %}{{ variable }}{%
endnoloc %}`. I'll update my patch if that is the general consensus.

Justin said he'd like some more core dev eyes on the patch, since it
touches a couple of vital code paths in the template system. So here I
am :)

Kind regards,
Benjamin

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

--
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.

-- 
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: #12012 Logging: request for comments

[Antoni Aloy]

Hello,

Actually what I'm used to do in my application is to have a logging
configuration in the settings.py livel and

import logging
logging.getLogger(__name__)

at the module level, so each module gets its own logger. In the
settings level and via a local_settings file one can seat each logging
level. Adding a startup.py at the application level could save me some
lines of code so I'm +1 on it :). For me it's also a a good idea as
removes some decisions about "where I have to put that code that needs
to be loaded once".

In a logging system I think is important to differentiate between
logging in development where we neeed a console log and logging in
production where we need a file log as a minimum, and I don't see how
can be easily managed unless the Django logging module has additional
configuration to add the default logging output.

The Django logging module should also show how "the standard way" to
create loggers for the Django applications, and I don't see an easy
way to do it. Perhaps it's just a matter of documenting it, I don't
know.

So I'd like to add  2 main doubts to the thread

1. How the logging process could be standardized for all Django apps?
2. How can we change the logging setting from
development/preproducction to a production configuration just changing
some sort of local_setting?

We could do some profile tests to see if

http://docs.python.org/library/logging.html?highlight=logging#logging.Logger.isEnabledFor

it's worth to be added in the code.

One last doubt, perhaps offtopic I have read logging module is slow,
good enough for 90% of applications but for the rest. Actually is
enough for me, but I can't see  to deal with log on big systems

Regards,

-- 
Antoni Aloy López
Blog: http://trespams.com
Site: http://apsl.net

-- 
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: Regression problem on admin date format

[Antoni Aloy]

Hi,

I have confirmed the bug with other non speaking people and I have
sent an e-mail to django-i18n group to point out the problem.

I have also contacted Marc and he has confirmed that the problem exists.

Sorry for the insistence but in my opinion this is a blocker bug.

Best regards,

-- 
Antoni Aloy López
Blog: http://trespams.com
Site: http://apsl.net

-- 
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: Regression problem on admin date format

[Antoni Aloy]

2010/7/10 Russell Keith-Magee <russ...@keith-magee.com>:
> On Sat, Jul 10, 2010 at 1:15 AM, Antoni Aloy <antoni.a...@gmail.com> wrote:

> Are you sure that this is a regression, rather than a bugfix with
> unfortunate side effects? In particular, I draw your attention to the
> second note under:
>
> http://docs.djangoproject.com/en/1.2/topics/i18n/localization/#id3
>

Well I don't know how to call it, but I just see the effects. I'm not
talking about a custom form, it's about the admin form, and I'm just
using USE_L18N=True, so I understand that admin should work  in the
same way 1.2 was.

Actually you have the right display format when intering a date with
the calendar or the "today" link, but the wrong (default one) the
first time the date is displayed.

And if you modify a non date field the form will complain about the
wrong date format.

Best regards,

-- 
Antoni Aloy López
Blog: http://trespams.com
Site: http://apsl.net

-- 
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.

Regression problem on admin date format

[Antoni Aloy]

Hello,

Have anybody (Marc Garcia ?) check
http://code.djangoproject.com/ticket/13621 ticket. It explains a bug
concerning date and time formats. The admin does not conform the i18n
locale settings on displaying time and date formats and reverts to the
default format.

It seems a true regression test as
http://djangoadvent.com/1.2/i18n-l10n-improvements/ explains the right
display. I have reverted to Django 1.2.0 and the display works
perfectly.

As you can imagine is a quite annoying bug for non-english date format
users, perhaps enough to make a 1.2.2 release.

-- 
Antoni Aloy López
Blog: http://trespams.com
Site: http://apsl.net

-- 
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: Decision required: PostgreSQL minimum versions

[Antoni Aloy]

+1 on Drop 7.4 PostgreSQL support. Postgressql 8.x series has lots of
performance and utility features and it would be a pity to remain in
7.4.

-- 
Antoni Aloy López
Blog: http://trespams.com
Site: http://apsl.net

-- 
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 The Enterprise wants from Django

[Antoni Aloy]

Hi!

My previous experience was from Java J2EE world and as Jacob said we
adopted Django because it really shines solving some complexity
problems associated to J2EE world as MVC patter, templates, etc., but
I agree that a common way to configure external applications would be
nice.

I'll also have been searching a good RIA to connect with Django. One
of the frameworks I like best is Qooxdoo http://qooxdoo.org/, perhaps
the best javascript opensource RIA frameworks I have seen. In order to
connect with Qooxdoo just Json-RCP or xml-rcp is needed. Perhaps we'll
need an special support for this in Django to mark a view as rcp as
some external projects do as RCP4Django or other. I'd like to see
Qooxdoo as the default Django RIA (not the default javascript
framework) as Qooxdoo people uses also Python and the framework fits
quite well in what I think is an enterprise RIA framework.

I know that this could be against the Django policy of not to bless a
javascript framework, but in my opinion if we want to shine at RIA you
have to choose.

We have created also some HTTP-XML based web services in Django in a
fraction of time we needed to create them in Java. For that we are
using Django without ORM, but we have found a great help to allow
documenting the web service and create the test pages.

Anyway, I'm glad to see Fortune companies are interested in Django :)

-- 
Antoni Aloy López
Blog: http://trespams.com
Site: http://apsl.net
-- 
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 comment: #12624 Class based test runners

[Antoni Aloy]

+1 for me

El 16/01/2010 15:26, "Russell Keith-Magee" 
escribió:

Hi all,

This is a quick call for comment on ticket #12624.

This ticket proposes to make Django's test runner a class-based,
rather than function based operation.

This makes it much easier to modify the individual parts of the
behavior of the Django test runner. For example if you want to:

 - not destroy the databases at the end of the test run
 - Use a TestRunner other than the TextTestRunner
 - Not have DEBUG disabled during tests
 - Do something else exotic before/during/after test execution

you can subclass the basic test runner and override the method that
implements the specific behavior that you want to change.

Specifically, I want to make this change because I've had a couple of
conversations in the recent past that have gone something like:

 Them: How do you make Django do X before/during/after a test run?
 Me: You write a custom test runner
 Them: How do I do that?
 Me: You copy this 50 line method and modify the 1 line that offends you.
 Them: 1985 called - they want their code back.

I don't expect this change to be especially controversial, but as a
matter of good form I thought I raise it before committing. Comments
welcome; barring feedback, I'll expect to commit this early next week.

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.
-- 

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: Feature Request: Reinteract

[Antoni Aloy]

2009/11/28 James Bennett <ubernost...@gmail.com>:
> On Fri, Nov 27, 2009 at 6:07 AM, noel <telln...@gmail.com> wrote:
>> I really love this application Reinteract. Its an enhancement to
>> Python Interactive Shell. And it would be lovely if I can use
>> Reinteract with manage.py shell.
>

You can also try django command extensions and run manage.py shell_plus


-- 
Antoni Aloy López
Blog: http://trespams.com
Site: http://apsl.net

--

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: Oracle NLS sorting

[Antoni Aloy]

2009/6/5 slafs <slaf...@gmail.com>:
>
> Hi there!
>
> It's my first message here so forgive any mistakes. I don't know even
> if I should write about this here.
> Anyway...
> I was having a problem with proper (polish) ordering of my queries
> within a queryset from an Oracle backend.
>
Recently we had some weird problems related to the way Oracle works.
It needs an evironment variable set propertly in order to work as
expected. One could think that a PL or the encoding should just depend
on the server, but it really depends on the client configuration.

I think in your case is quite the same, take a look at
http://www.oracle.com/technology/tech/globalization/htdocs/nls_lang%20faq.htm
and the set the enviornment variable NLS_LANG on your application. In
the setting perhaps.

Hope it helps!

-- 
Antoni Aloy López
Blog: http://trespams.com
Site: http://apsl.net

--~--~-~--~~~---~--~~
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: Reminder: Django 1.1 beta this week means feature freeze

[Antoni Aloy]

2009/3/18 Jacob Kaplan-Moss <ja...@jacobian.org>:
>
> Hi folks --
>
> Quick reminder that Django 1.1 beta is due to drop Friday. This means
> feature freeze -- any feature additions not completed by the beta
> timeline won't make it into 1.1. Realistically that means that any
> feature addition not already "close" to done should probably be
> tabled.
>

What about patches like http://code.djangoproject.com/ticket/5691,
this bugs affects only people working with i18n sites and which has
global catching activate, but it's quite annoying for us, so we'd like
to see it this version if possible.

Best regards,

-- 
Antoni Aloy López
Blog: http://trespams.com
Site: http://apsl.net

--~--~-~--~~~---~--~~
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: Dropping Python 2.3 compatibility for Django 1.1

[Antoni Aloy]

+1 for me too
2.4 is still quite conservative :)
The actual Django stable version is good enought to let people
developing in until the decide/can move to a new version


-- 
Antoni Aloy López
Blog: http://trespams.com
Site: http://apsl.net

--~--~-~--~~~---~--~~
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: Testing django code

[Antoni Aloy]

2008/11/21 Malcolm Tredinnick <[EMAIL PROTECTED]>:
>

>
> I'd encourage you to follow my hint from the other day on django-users:
> look at tests/regressiontests/middleware/tests.py and add a similar sort
> of class to tests/regressiontests/cache/tests.py (the latter is where
> the caching tests are). There's some good examples in there of testing
> existing middleware and you can do similar things to test the locale
> +session+caching middleware combination. You'll need to set some headers
> (and/or set up a session) to set the current locale, but it should fall
> out fairly easily with the right helper functions.

OK.
I'm going double check it again.

This is my first incursion in Django core tests, so any advice you
could give me would be greatly appreciated.

-- 
Antoni Aloy López
Blog: http://trespams.com
Site: http://apsl.net

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Testing django code

[Antoni Aloy]

Hi!

I'm working on ticket #5691 http://code.djangoproject.com/ticket/5691,
I have patched the original Django code and now I'm trying to write
the tests.

For testing purposes I have created a minimum applications and using
Client to start checking, but I have found some problems:

 *  get_cache_key requires a request. I can get the request from the
response class as response.request, but then on the private
_generate_cache_key it tries to get request.path, but this is not in
the request data.

* I'm not sure about if creating an application is the right way of
creating such tests and event is is the right way, who to add it to
Django code.

Best regards,

-- 
Antoni Aloy López
Blog: http://trespams.com
Site: http://apsl.net

--~--~-~--~~~---~--~~
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: Optional {% default %} clause for the {% for %} template tag

[Antoni Aloy]

2008/10/30 Mike Panchenko <[EMAIL PROTECTED]>:
> +1 for {% empty %}
>
> I also think this would be very useful
>
> On Thu, Oct 30, 2008 at 6:55 AM, dc <[EMAIL PROTECTED]> wrote:
>>
>> How about
>>
>> {% for item in items %}
>> {% otherwise %}
>> {% endfor %}
>>

+1 to the otherwise tag :)


-- 
Antoni Aloy López
Blog: http://trespams.com
Site: http://apsl.net

--~--~-~--~~~---~--~~
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: First day of week

[Antoni Aloy]

2008/6/26 Jannis Leidel <[EMAIL PROTECTED]>:

> This is a double-edged sword, on the one hand it would be wonderful to
> have complete locale support but on the other hand this makes issue
> #1061 larger than it really is. My patches there fix the interface
> bugs, but should be replaced by a more sane system sometime.
>
> Why not making "full locale support" a post-1.0 feature and fix the
> calendar bug for now, considering the tight schedule?
>
To be honest I have to say that Jannins approach wokrs for at 99%, so
perhaps a two phase approach could be a solution. After all, Python
makes refactoring a breeze, doesn't it?

-- 
Antoni Aloy López
Blog: http://trespams.com
Site: http://apsl.net

--~--~-~--~~~---~--~~
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: First day of week

[Antoni Aloy]

2008/6/26 Marc Garcia <[EMAIL PROTECTED]>:
>
> Hi all!
>
> I'll start working on a new (hopefully better) patch for ticket #1061
> [1] that will allow customization of first day of week on django's
> admin calendar.
+1 on that Mark.
If I can help just let me know.

-- 
Antoni Aloy López
Blog: http://trespams.com
Site: http://apsl.net

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

i18n and per-view-cache

[Antoni Aloy]

Hello,

I re-post a question made to the django-users, I tried there first,
but I think is more development related.

I'm trying to use a the per view cache decorator cache_page, but I
have a multi-languaje site so the cache engine must generate its key
based on the page language. Using cache_page as is, doesn't work so my
idea is to use the vary headers decorator. I have added

patch_vary_headers(response,['Content-Language'])

to the views I want to caché, but without success, that is, whenever
the page is cached the first time in one language, you could change
the language but the cache returns the previous content.

Example:
I have accessed the page in spanish (es) and now I want to change to
catalan (ca). The response says

Content-Languageca
Content-Encodinggzip
Expires Sun, 09 Dec 2007 19:02:12 GMT
VaryContent-Language, Accept-Encoding, Accept-Language, Cookie
Last-Modified   Sun, 09 Dec 2007 18:02:12 GMT
Etag61c7f9e1202bd85458c7f8dc6df04ebd
Cache-Control   max-age=3600
Content-Typetext/html; charset=utf-8

but the page is still in spanish and it's not accessing to the view,
just taking the content from the caché.

By the way, I don't use the cache middleware.

It seems that the vary header should be the way to add the language to
the cache key, but I not able to make it work.

Any ideas?

I have a test project in http://code.google.com/p/appfusedjango/source
if somebody want's to play with it.

I have modified the django cache code to include the languaje code
when generating the key and it works as expected but this involves to
patch Django.

Language based caching is a common issue on multi-language site, so
perhaps this would be the default if i18n middleware is activated.

Best regards,

-- 
Antoni Aloy López
Binissalem - Mallorca
http://www.trespams.com
Soci de Bulma - http://www.bulma.cat

--~--~-~--~~~---~--~~
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: Cache and i18n

[Antoni Aloy]

2007/10/22, Jeremy Dunck <[EMAIL PROTECTED]>:
>
> On 10/22/07, Antoni Aloy <[EMAIL PROTECTED]> wrote:

> > I had the problems with page cache, now I'm using this snippet
> > although it caches all the site, but I prefered that solution in order
> > to avoid to mantain a patched version of Django.
> >
> > http://code.djangoproject.com/ticket/5691
>
> So, if you're using the low-level cache directly, I agree that this is
> an issue.  But I think most people use the middleware or decorators,
> and in that case, it should be OK.
>
> I commented on that ticket to the same effect.
>
No, previously on using the snippet I was using the cache decorator,
When I added the multilanguage option to my application I realized
that something was going wrong as some pages was'nt changing when I
changed the language.
That's why I say that having the language in the key would solve both
problems, the one that the snippet tries to solve and the one with the
decorator.

I'm sorry about my poor english :(

-- 
Antoni Aloy López
Binissalem - Mallorca
http://www.trespams.com
Soci de Bulma - http://www.bulma.cat

--~--~-~--~~~---~--~~
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: Cache and i18n

[Antoni Aloy]

2007/10/22, Jeremy Dunck <[EMAIL PROTECTED]>:
>
> On 10/22/07, Antoni Aloy <[EMAIL PROTECTED]> wrote:
> > I've found that caches are not i18n friendly, that is the cache is the
> > same for any language. In Django snippets there is a middleware to
> > deal with this fact, and I have send a patch myself to the Django
> > core.
>
> Which cache are you talking about?
>
> If you mean HTTP caches, are you patching your Vary header with 
> Accept-Language?
>
> If you're using LocaleMiddleware, it sounds like you have it listed
> before your cache middleware.
>
> More details, please-- this may be a problem in your configuration, or
> an actual bug.  Either way, we can't fix anything without more
> details.
>
I have just read the changeset 6575 about order in the cache. Im using
the LocaleMiddleware, so I have to make some additional tests. Anyway,
if the cache key add the language prefix/sufix to the actual key would
be a good improvement. Please take a look at
http://www.djangosnippets.org/snippets/443/
Perhaps he had the same problem with order, but in any case having the
language on any key cache will made that snippet obsolete.

I had the problems with page cache, now I'm using this snippet
although it caches all the site, but I prefered that solution in order
to avoid to mantain a patched version of Django.

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

I'm not sure if its the best way to do such thing but I suppose you'll
get the idea.

-- 
Antoni Aloy López
Binissalem - Mallorca
http://www.trespams.com
Soci de Bulma - http://www.bulma.cat

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Cache and i18n

[Antoni Aloy]

Hello!

I've found that caches are not i18n friendly, that is the cache is the
same for any language. In Django snippets there is a middleware to
deal with this fact, and I have send a patch myself to the Django
core.

The change is in fact minor, just add the current locale to the cache
key and it solves the cache problem in multilanguage sites and allows
you to use per page cache and even the new cache tag.

Best regards,

-- 
Antoni Aloy López
Binissalem - Mallorca
http://www.trespams.com
Soci de Bulma - http://www.bulma.cat

--~--~-~--~~~---~--~~
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: Problem: Sessions won't store anything

[Antoni Aloy]

I have also aproblem with sessions, and I filed a ticket. My
workaround is not to use sqlite as a database cache, and use a memory
based backed and store session in cache.
It's a very anonying bug for me, as our development team uses sqlite
as a common database.

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

2007/10/13, Johannes Dahlström <[EMAIL PROTECTED]>:
>
> Hello,
>
> I previously posted to Django Users about this problem, but didn't get
> any replies, so a friend recommended raising the issue here too.
> Here's a link to my earlier message:
>
> http://preview.tinyurl.com/3e5q8p
>
> Thanks in advance for any help,
>
> - Johannes
>
>


-- 
Antoni Aloy López
Binissalem - Mallorca
http://www.trespams.com
Soci de Bulma - http://www.bulma.cat

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---