Re: How to work with views like classes
Thanks for your responses. The problem here is that there are some "dirty" solutions to this problem, but i'm sure there is a good way to proceed with it. This issue should be really simple to resolve if django make use of classes instead of functions for views, and then, template would be benefited receiving that class as parameter, using all provided data from that class (and its superclasses). Anyway, I think the django solution to accomplish it is to use middleware nowadays, like i18n or authentication django plugins do. On Thu, Mar 17, 2011 at 12:52 PM, Daniel Roseman wrote: > On Thursday, March 17, 2011 11:35:55 AM UTC, chubz wrote: >> >> What I've found as a solution, though I don't know how much it is >> recommended as a programming practice is to have your variable defined in a >> "custom" request context and then use that request context instead of the >> default one. >> >> You create you request context and based on the default context then just >> set it up in settings to be used for the whole site. >> You can star of on this link than expand to other sites: >> >> http://docs.djangoproject.com/en/dev/ref/templates/api/#writing-your-own-context-processors >> >> I'm still in the process of gathering all the information, and would like >> to see a response from a more experienced and versed py/django programmer on >> this matter. >> >> What's the trade off. I know it comes down to : "We're all conseting >> adults here" so don't do bad stuff or bad stuff will be done unto you. But >> still, is there any other concerns with this solution? >> >> hope this helps. >> > > Why should there be concerns? This is the proper way to define data that > needs to be sent to every template. > > The alternative is to define custom templatetags in the base templates that > get their own data from wherever they need to get it from. > -- > DR. > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: How to work with views like classes
On Thursday, March 17, 2011 11:35:55 AM UTC, chubz wrote: > > What I've found as a solution, though I don't know how much it is > recommended as a programming practice is to have your variable defined in a > "custom" request context and then use that request context instead of the > default one. > > You create you request context and based on the default context then just > set it up in settings to be used for the whole site. > You can star of on this link than expand to other sites: > > http://docs.djangoproject.com/en/dev/ref/templates/api/#writing-your-own-context-processors > > I'm still in the process of gathering all the information, and would like > to see a response from a more experienced and versed py/django programmer on > this matter. > > What's the trade off. I know it comes down to : "We're all conseting adults > here" so don't do bad stuff or bad stuff will be done unto you. But still, > is there any other concerns with this solution? > > hope this helps. > Why should there be concerns? This is the proper way to define data that needs to be sent to every template. The alternative is to define custom templatetags in the base templates that get their own data from wherever they need to get it from. -- DR. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: How to work with views like classes
What I've found as a solution, though I don't know how much it is recommended as a programming practice is to have your variable defined in a "custom" request context and then use that request context instead of the default one. You create you request context and based on the default context then just set it up in settings to be used for the whole site. You can star of on this link than expand to other sites: http://docs.djangoproject.com/en/dev/ref/templates/api/#writing-your-own-context-processors I'm still in the process of gathering all the information, and would like to see a response from a more experienced and versed py/django programmer on this matter. What's the trade off. I know it comes down to : "We're all conseting adults here" so don't do bad stuff or bad stuff will be done unto you. But still, is there any other concerns with this solution? hope this helps. On Wed, Mar 16, 2011 at 4:52 PM, Isaac XxX wrote: > t (normally Requ -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
How to work with views like classes
Hi folks,
Currently i'm getting trouble with a single feature in django. When i've
some inheritance in templates, like the following
TemplateA
TemplateB inherits A
TemplateC inherits B
TemplateD inherits B
If I need to define something depending on provided data in TemplateA or
TemplateB, then all views that render TemplateC and TemplateD should provide
the needed data. For example
Template A
...
{% my_var %}
...
How can define "my_var" as global variable for all views that would render
an inherited template of A (or B, or whatelse needed) without recurring to
middlewares?
I've have programmed many time in RoR, and is really simple to define global
vars, or complex inheritance patterns to share common data.
BTW, I though about decorators, implement some "pre-post" processment, but
it's not as clean as i want, because I should get the specific context
(normally RequestContext, but it can be another one in other projects)
rendered by view.
Thanks in advance
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
