Re: Attach a technincal html response to email on server error
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 response i can read a lot of informations (like vars, > request information, server settings and so on) > > my idea is to attach an html file, that is the very same response you > got on error with DEBUG = True. > > this response has got no external dependencies (css and js are inline > in the html), so it can be attached as a file in the email that is > sended on server error. > > this is very simple to archieve, and developers can open it with the > browser and see a lot of information. This is already possible since Django 1.3 with the logging framework and AdminEmailHandler: https://docs.djangoproject.com/en/dev/topics/logging/#django.utils.log.AdminEmailHandler -Andreas -- 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: Removing pickle from cookie-based session storage
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 strings. If it can't be a drop-in replacement to > > the other session storage, just document it and offer a > > PickleSignedSessionStorage, but don't push a possibly insecure > > default. > > The default is secure. If you don't disclose your secret key, you > don't have a problem. > > JSON is considerably more verbose. Cookie space is limited. JSON > doesn't support many of the data structures people store in sessions. > There are many reasons to store data in sessions beyond FormWizard. It > already isn't a drop-in replacement, since it has limitations the > other ones don't have. Would it make sense to allow easier subclassing of signed_cookies.SessionStore? The standard SessionStore could use self.serializer instead of the hardcoded PickleSerializer (patch size 3 lines). Then document how to subclass SessionStore: from django.contrib.sessions.backends.signed_cookies import SessionStore from django.core.signing import JSONSerializer class JSONSessionStore(SessionStore): self.serializer = JSONSerializer This would allow the developer to pick the tradeoff between JSON and Pickle instead of Django enforcing the choice. Not that it is that hard to subclass the SessionStore currently, but this would make it even easier, and documentation would make it part of the public API. - Anssi -- 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: Attach a technincal html response to email on server error
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 "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: Attach a technincal html response to email on server error
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 mail. in that way you gat a plain text version and a rich version as attachment that can be opened with any browser. -- 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: Attach a technincal html response to email on server error
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 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, > request information, server settings and so on) > > my idea is to attach an html file, that is the very same response you > got on error with DEBUG = True. > > this response has got no external dependencies (css and js are inline > in the html), so it can be attached as a file in the email that is > sended on server error. > > this is very simple to archieve, and developers can open it with the > browser and see a lot of information. > > -- > 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. > > -- 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.
Attach a technincal html response to email on server error
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, request information, server settings and so on) my idea is to attach an html file, that is the very same response you got on error with DEBUG = True. this response has got no external dependencies (css and js are inline in the html), so it can be attached as a file in the email that is sended on server error. this is very simple to archieve, and developers can open it with the browser and see a lot of information. -- 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: JsonField
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 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: TemplateResponse and loader should handle request
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, 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" 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: TemplateResponse and loader should handle request
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 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: TemplateResponse and loader should handle request
> 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" 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: Removing pickle from cookie-based session storage
> 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 other session storage, just document it and offer a > PickleSignedSessionStorage, but don't push a possibly insecure > default. The default is secure. If you don't disclose your secret key, you don't have a problem. JSON is considerably more verbose. Cookie space is limited. JSON doesn't support many of the data structures people store in sessions. There are many reasons to store data in sessions beyond FormWizard. It already isn't a drop-in replacement, since it has limitations the other ones don't have. -- 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: TemplateResponse and loader should handle request
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 different site and i would like to have a different template folder for each site, template folder that can be different even for country or language, a lot of things that can be extracted from request. -- 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: JsonField
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 database api, and use the powerful model and queryset django api. forget about 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: JsonField
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 relational data store can be archived on any datastore, with a framework. validation of non relational data and creation of indexes we can validate data on save, and we can create index of non relational data on save. that is just my opinion, but maybe i'm not a programmer, i'm just an hacker! On 10 Nov, 20:20, Ric wrote: > 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 keys, a things that rocks! > > i need to handle documents (real documents, paper), and what i have > done is to store cleaned_data inside a model and give to that a > number. > > i need to do a lot of different documents (iso 9000 sheet, ddt, > invoices, quotations), and i don't need to query non relational data > that are inside (not all of them, of course). > > what i need, instead, is to have some common field for all my document > (document date, document number, document prefix, document owner, and > maybe a content type field) to query and order them, and store them in > an unique db table. > > that kind of schema is better than a non relational database, because > i can use foreign keys and index for fast query the things i need to > query, and create different kind of classes to handle different kind > of documents. > > to archive that kind of job, a json field is great. and i dont't whink > i'm the only django user that needs stuff like that (business staff). > > sometimes you might need to save raw html inside db, and sometimes you > may need to store raw json to db. > > that's all. > > On 8 Nov, 19:47, diogobaeder wrote: > > > > > > > > > Hi, guys, > > > I agree that we should use the right tool for the job; But even a > > relational database can be used for semi-structured data when it's not > > going to be directly queried. Matter of fact, there's even a design > > pattern recognized for > > that:http://martinfowler.com/eaaCatalog/serializedLOB.html > > > Example of use: think of a semi-structured data store (in a relational > > database) that is going to be read through a search engine (think > > about ElasticSearch of Solr, here). > > > But yes, if you're going to need to query for this data by parts of > > the JSON field, then you're shooting your own foot. So, in the end, we > > have to think a lot about what's the problem we're trying to solve - > > it's not as simple as "don't use RDBMS for non-relational data" -, > > IMHO. > > > Well, at least here's my 2 cents. > > > Cheers, > > > Diogo > > > On 8 nov, 08:34, Tom Evans wrote: > > > > On Mon, Nov 7, 2011 at 11:48 PM, Torsten Bronger > > > > wrote: > > > > > While I appreciate that Django core is supposed to enforce good > > > > design practices, one must be careful with that if some practice may > > > > have valid use cases. You cannot prevent the user from shooting in > > > > the foot anyway. > > > > > While we make extensive use of the relational model in our project, > > > > I remembered to have a couple of JSON fields (though we don't have a > > > > field class them them so far), so I skimmed through our code to see > > > > why we did this. > > > > And so do I - the main point here is that we have both successfully > > > loaded the gun and aimed it at our foot without this field existing in > > > core. I think it's important to have that distinction between things > > > you can do and things you should do, in order to make you think > > > "should I really be doing this". > > > > Cheers > > > > Tom -- 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: JsonField
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 keys, a things that rocks! i need to handle documents (real documents, paper), and what i have done is to store cleaned_data inside a model and give to that a number. i need to do a lot of different documents (iso 9000 sheet, ddt, invoices, quotations), and i don't need to query non relational data that are inside (not all of them, of course). what i need, instead, is to have some common field for all my document (document date, document number, document prefix, document owner, and maybe a content type field) to query and order them, and store them in an unique db table. that kind of schema is better than a non relational database, because i can use foreign keys and index for fast query the things i need to query, and create different kind of classes to handle different kind of documents. to archive that kind of job, a json field is great. and i dont't whink i'm the only django user that needs stuff like that (business staff). sometimes you might need to save raw html inside db, and sometimes you may need to store raw json to db. that's all. On 8 Nov, 19:47, diogobaeder wrote: > Hi, guys, > > I agree that we should use the right tool for the job; But even a > relational database can be used for semi-structured data when it's not > going to be directly queried. Matter of fact, there's even a design > pattern recognized for > that:http://martinfowler.com/eaaCatalog/serializedLOB.html > > Example of use: think of a semi-structured data store (in a relational > database) that is going to be read through a search engine (think > about ElasticSearch of Solr, here). > > But yes, if you're going to need to query for this data by parts of > the JSON field, then you're shooting your own foot. So, in the end, we > have to think a lot about what's the problem we're trying to solve - > it's not as simple as "don't use RDBMS for non-relational data" -, > IMHO. > > Well, at least here's my 2 cents. > > Cheers, > > Diogo > > On 8 nov, 08:34, Tom Evans wrote: > > > > > > > > > On Mon, Nov 7, 2011 at 11:48 PM, Torsten Bronger > > > wrote: > > > > While I appreciate that Django core is supposed to enforce good > > > design practices, one must be careful with that if some practice may > > > have valid use cases. You cannot prevent the user from shooting in > > > the foot anyway. > > > > While we make extensive use of the relational model in our project, > > > I remembered to have a couple of JSON fields (though we don't have a > > > field class them them so far), so I skimmed through our code to see > > > why we did this. > > > And so do I - the main point here is that we have both successfully > > loaded the gun and aimed it at our foot without this field existing in > > core. I think it's important to have that distinction between things > > you can do and things you should do, in order to make you think > > "should I really be doing this". > > > Cheers > > > Tom -- 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: TemplateResponse and loader should handle request
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 custom template loader than to have to write (or inherit) that into every single view -- especially once you start integrating third-party apps with their own not-necessarily-class- based views. On Nov 10, 6:27 am, Tom Evans wrote: > 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, place it in a context and render it. > > > I think you missunderstood me, I didn't ment to add a optional keyword > > argument like request, but pass **kwargs down the chain -- The current > > template loaders would just ignore it completly but users might override it > > to supply extra data to their template loader. Either way it was just a > > suggestion and I am not really sold on it either… > > > Cheers, > > Florian > > I tend to lurch from one extreme to another - I've calmed down a little now! > > I worry about coupling things to the request, having used frameworks > where that has happened over time. It always leads to problems down > the line, as in my experience, a lot of what happens on a web site > happens outside of the request/response cycle. > > It's already pretty hard to generate the same content outside of a > request/response if your template expects things from > TEMPLATE_CONTEXT_PROCESSORS. > > Cheers > > Tom -- 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: Localization on User model
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, November 10, 2011 at 12:53 PM, hcarvalhoalves wrote: > 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.DefaultUserProfile. > > On 22 set, 02:26, lvella http://gmail.com)> wrote: > > The User model included in Authentication subsystem is very annoying > > to use here in Brazil. The common "first name" and "last name" method > > of identifying people found in English speaking countries is very > > unnatural to our culture, which people usually have two or more family > > names. It is a cultural trait of here that renders unsuitable the > > splitting of the name into first and last on the model. There are > > countries/cultures with other people naming customs that is also hard > > to localize with this model [1][2]. > > > > What about changing this in future versions? Maybe simply a > > "true_name" field would do? Or maybe a way to customize the fields in > > the User model. > > > > [1]:http://en.wikipedia.org/wiki/Arabic_name > > [2]:http://en.wikipedia.org/wiki/Eastern_Slavic_naming_customs > > > > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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-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: Localization on User model
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.DefaultUserProfile. On 22 set, 02:26, lvella wrote: > The User model included in Authentication subsystem is very annoying > to use here in Brazil. The common "first name" and "last name" method > of identifying people found in English speaking countries is very > unnatural to our culture, which people usually have two or more family > names. It is a cultural trait of here that renders unsuitable the > splitting of the name into first and last on the model. There are > countries/cultures with other people naming customs that is also hard > to localize with this model [1][2]. > > What about changing this in future versions? Maybe simply a > "true_name" field would do? Or maybe a way to customize the fields in > the User model. > > [1]:http://en.wikipedia.org/wiki/Arabic_name > [2]:http://en.wikipedia.org/wiki/Eastern_Slavic_naming_customs -- 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: Removing pickle from cookie-based session storage
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 remote code execution exploit, and a leaking SECRET_KEY shouldn't lead to such a compromise. 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 other session storage, just document it and offer a PickleSignedSessionStorage, but don't push a possibly insecure default. On 2 out, 02:26, Paul McMillan wrote: > We recently committed changes to 1.4 that added signed cookie based > session storage. Session data is pickled, signed, and sent to the > client as a cookie. On receipt of the cookie, we check the signature, > unpickle, and use the data. We could use JSON instead of pickle, at > the expense of longer cookies. > > I believe that our signing implementation is secure and correct. > > However, I know that users of Django screw up from time to time. It's > not uncommon to see SECRET_KEY in a git repository, and that value is > often used in production. If SECRET_KEY is compromised, an attacker > can sign arbitrary cookie data. The use of pickle changes an attack > from "screw up the data in this application" to "arbitrary remote code > execution". > > In light of this, we should be conservative and use JSON by > default instead of pickle. > > -Paul -- 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: Request for review / Multiple time zone support for datetime representation
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 energy mid-sentence :) Do you remember what > you were going to say? At that point I realised that a previous comment in my email was wrong (I thought I'd found a bug in the new version of LocalTimezone), went back and fixed it, but never deleted that line! Please ignore that half finished sentence :-) Luke -- "Where a person wishes to attract, they should always be ignorant." (Jane Austen) Luke Plant || http://lukeplant.me.uk/ -- 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: TemplateResponse and loader should handle request
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, place it in a context and render it. > > I think you missunderstood me, I didn't ment to add a optional keyword > argument like request, but pass **kwargs down the chain -- The current > template loaders would just ignore it completly but users might override it > to supply extra data to their template loader. Either way it was just a > suggestion and I am not really sold on it either… > > Cheers, > Florian I tend to lurch from one extreme to another - I've calmed down a little now! I worry about coupling things to the request, having used frameworks where that has happened over time. It always leads to problems down the line, as in my experience, a lot of what happens on a web site happens outside of the request/response cycle. It's already pretty hard to generate the same content outside of a request/response if your template expects things from TEMPLATE_CONTEXT_PROCESSORS. Cheers Tom -- 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: TemplateResponse and loader should handle request
> 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? If you're using class-based views, override get_templates to provide the right templates for the request. It's not quite a tidy to handle inclusion tags though - you need to subclass django.template.base.Library, and override inclusion_tag, grabbing the request out of the context (use the 'request' context processor) - then use whatever mechanism you used before to pick a template based on the request. Cheers, Dan -- Dan Fairs | dan.fa...@gmail.com | www.fezconsulting.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: TemplateResponse and loader should handle request
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 didn't ment to add a optional keyword argument like request, but pass **kwargs down the chain -- The current template loaders would just ignore it completly but users might override it to supply extra data to their template loader. Either way it was just a suggestion and I am not really sold on it either… Cheers, Florian -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/ES0qs5Lko_wJ. 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: TemplateResponse and loader should handle request
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, until people start relying on that feature. Suddenly, you then have templates that are functionally tightly coupled to requests. I don't get why it is difficult to extract what you want from the request, place it in a context and render it. The OP's use case of wanting to modify the template used can be achieved either by calculating which template to use in the view, or by passing in the name of the template that should be extended as a variable when rendering. Cheers Tom -- 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.
