I thought about doing that, but the problem with that approach is it
sort of violates the distinction between developer and designer that
the Django template system establishes. I'm not sure having the
designer muck around in Python to change which template their design
extends is a good idea.
I've come up with a somewhat hackish approach to this though. There
are three pieces to this:
1) You adopt a naming convention with mobile templates -- e.g. the
mobile version of bob.html would bob.html.m. Or something. Your
choice.
2) Instead of setting a mobile variable in the context, set it in some
global.
3) Write a custom template loader that checks said global variable and
gets a modified template according to naming convention if the mobile
variable evaluates to True.
I'm not a huge fan of that -- first, not a fan of forced naming
conventions that the designer can't easily change. Second, that global
variable could potentially pollute other requests. You basically have
to ensure it's reset for every request (e.g. using middleware) and
mark that piece of code as not thread safe.
Any suggestions?
-- Andrew
On Jun 6, 6:29 am, Matthias Kestenholz <matthias.kestenh...@gmail.com>
wrote:
> On Fri, Jun 5, 2009 at 6:35 PM, Andrew Fong <fongand...@gmail.com> wrote:
>
> > I was hoping someone could explain to me what the exact behavior would
> > be if the Extends Node in the template was not first.
>
> > Here's my use-case scenario: I need to maintain separate mobile and
> > desktop templates for my site. I'm finding out that 90% of my
> > templates would be identical -- the only difference would be which
> > templates they extended from -- e.g. {% extends 'base.html' %} vs. {%
> > extends 'm_base.html' %}.
>
> > My views insert a mobile variable into the context if they think the
> > user-agent is a mobile device. So I want behavior like this:
>
> > {% if mobile_var %}
> > {% extends 'm_base.html' %}
> > {% else %}
> > {% extends 'base.html' %}
> > {% endif %}
>
> > This won't work because the the extends tag doesn't really understand
> > the {% if %} tag above it and just throws up when it comes to the {%
> > else %} tag. So as an alternative, I plan to encapsulate that logic in
> > a custom extends tag -- e.g. {% mextends mobile_var 'm_base.html'
> > 'base.html' %} that wraps the existing do_extends function.
>
> > When going over the ExtendNode source code however, I noticed it has
> > to be first. However, in order to use my custom tag, I need to call {%
> > load %}, and that call means any ExtendNode created after that can't
> > be first. I'm tempted to simply disable that, but I'm not really sure
> > what will happen if I do. Are there any problems with calling a load
> > tag before an extends?
>
> I don't know the answer to your question, but here is a suggestion how
> you might accomplish using a different base template for the mobile
> version of your site. The extends tag accepts a variable too, so you
> could just use a context processor to pass the base template into the
> renderer, something like this (in pseudo-code):
>
> def base_template(request):
> return {'base_template': is_mobile(request) and 'm_base.html' or
> 'base.html'}
>
> And inside your templates, use:
> {% extends base_template %}
>
> Matthias
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
