On Wed, Nov 9, 2011 at 7:10 PM, Doug Ballance wrote:
> I very much like the idea of an optional keyword argument and
> fallback. The template loader is one of the few places I've been
> forced to use threadlocals to get get the job done.
>
Please no - an optional argument is all well and good, u
Hi,
On Thursday, November 10, 2011 10:43:01 AM UTC+1, Tom Evans wrote:
>
> Please no - an optional argument is all well and good, until people
>
> I don't get why it is difficult to extract what you want from the
> request, place it in a context and render it.
>
I think you missunderstood me, I di
> in my opinion, the loader object should handle the request, so that
> can be sublassed to pass different template folder based on request
> params.
>
> i need this feature for my app, is it possible to have different
> template folder based on request params with the current django
> release?
On Thu, Nov 10, 2011 at 10:20 AM, Florian Apolloner
wrote:
> Hi,
>
> On Thursday, November 10, 2011 10:43:01 AM UTC+1, Tom Evans wrote:
>>
>> Please no - an optional argument is all well and good, until people
>>
>> I don't get why it is difficult to extract what you want from the
>>
>> request, p
On 10/11/11 07:46, Aymeric Augustin wrote:
>> I haven't actually reviewed any of the test code - I ran out of energy,
>> and test code is so dull, sorry!
>>
>> I did run coverage for the tests and found:
>>
>> - without pytz installed, the new LocalTimezone class
>
> You apparently ran out of ene
To reinforce the already commented issue:
Werkzeug suffers from the same problem, since it's SecureCookie
implementation pickles data by default.
https://github.com/mitsuhiko/werkzeug/issues/60 (See proof of concept
added)
To unpickle data from an untrusted client by default is a big
potential r
I believe the solution is to actually figure a migration path to move
everything that is non-essential to outside the User model. To
identify a User, it should be enough to have username, password and
permissions, and have the rest of the fields live in a
django.contrib.auth.models.DefaultUserProfi
This is a harder problem then just that. While doing that would allow a
solution to the name problem, there are more problems django.contrib.auth's
User model and it would be best to come up with a generic solution that fixes
all of these problems, instead of applying bandaid fixes.
On Thursday
It would be really nice to be *able* to create a template loader that
can use the request object. If, for instance, you have a site that
needs to be able to change the template used based on user preferences
or based on the current Site object, it's a lot cleaner to be able to
do that once in a c
that is just a proposition, i know that if you need a non relation db
the best thing to do is to have a non relational data store.
but you need a relational data store only if you need to query non
relational data, in the other cases you can use a relational db,
because relational db got foreign k
django could archive to manage non-relational data on relational db.
i don't want to use a non relational db, because i need foreign key
and i need non relational data.
read the couchdb guide, i think that you can find inspiration to
create powerful things.
i think that some ability of non relati
it was just an idea, Russel... maybe too hard to accomplish in the
right way.
i can use json field in my trunk and that's good for me.
i thought maybe, with validators, django could be be able to
accomplish some of the features of a non relational data store,
without messing up with low lowel dat
the first thing i have thought was that "loader shouldn't care about
the request"
but, request could be an optional argument, that can be none, with
this simple thing i can create a custom template loader, and add
whatever folder i want, based on request.
it's a way to customize a Site. i manage
> There's no reason to not use JSON by default since it's adequate for
> most cases where you need to store lightweight data client-side, since
> it's most useful to use with FormWizard and such, where the fields are
> easily serialized as strings. If it can't be a drop-in replacement to
> the othe
> If you're using class-based views, override get_templates to provide the
> right templates for the request.
i would like a django-wide feature, to customize admin folder and
third party app.
--
You received this message because you are subscribed to the Google Groups
"Django developers" grou
i agree with nan, it would be a nice feature.
On 10 Nov, 21:12, Ric wrote:
> > If you're using class-based views, override get_templates to provide the
> > right templates for the request.
>
> i would like a django-wide feature, to customize admin folder and
> third party app.
--
You received
maybe even a simple request.template_folders could do the job...
but it would work only with the new templateresponse class...
On 10 Nov, 21:23, Ric wrote:
> i agree with nan, it would be a nice feature.
>
> On 10 Nov, 21:12, Ric wrote:
>
>
>
>
>
>
>
> > > If you're using class-based views, over
i'm reading other post on this forum
django use pickle to store non relational data with session...
--
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
hi, i receive django email on 500 error.
with that kind of mail is difficult to debug, because i don't have a
lot of informations.
it's much more simple to debug when i set DEBUG = True and i receive
an html technical response.
with that response i can read a lot of informations (like vars,
reque
With email you can send and html email and text email in the same
email. You are basically sending and html "alternative" email and part
of a multi-part email.
That would be the best bet.
On Thu, Nov 10, 2011 at 3:03 PM, Ric wrote:
> hi, i receive django email on 500 error.
>
> with that kind of
i don't think so...
the debug response have got a lot of javascript... and a lot of email
client (gmail, outlook) escape javascript and could brake some
functionality of the web page... the safest way, in my opinion, is to
leave the content of email as plain text and to attach the html file
to the
not a lot of javascript, really. just a script to expand the local
vars...
but make a an alternative content it's not easy.
attach the html response it's pretty easy, maybe just a few line of
code and some import
--
You received this message because you are subscribed to the Google Groups
"Djan
On Nov 10, 10:05 pm, Paul McMillan wrote:
> > There's no reason to not use JSON by default since it's adequate for
> > most cases where you need to store lightweight data client-side, since
> > it's most useful to use with FormWizard and such, where the fields are
> > easily serialized as string
On 10 nov 2011, at 22:03, Ric wrote:
> hi, i receive django email on 500 error.
>
> with that kind of mail is difficult to debug, because i don't have a
> lot of informations.
>
> it's much more simple to debug when i set DEBUG = True and i receive
> an html technical response.
> with that respon
24 matches
Mail list logo
