On Tuesday, January 10, 2012 at 1:13 PM, IgorS wrote:
> First of all, thanks a lot to everyone who replied :-)
>
> Tom:
>
> As i mentioned, i am new to Django and could be missing big parts.
> Please do not hate me too much for my naivete :-)
>
> The approach you suggested regarding the static files seems to be
> reasonable. Especially considering that the static files will
> eventually go to a separate server.
>
> But I have some doubts regarding the templates. And the doubts come
> exactly from that [explicit vs. implicit] perspective. Why not making
> it more explicit? I mean to change it in a way that there is no need
> to relay on the order in which Django searches for the templates. The
> order is defined at the project level and this unnecessarily couples
> my application with the project.
>
>
A big reason to keep it the current way, is that typically the project level
templates will override app level templates. This let's you create reusable
apps and distribute them with default templates, but allow other apps or the
project itself to override those templates without having to modify the
original app.
>
> The only two places where the templates are referenced are the views
> and other templates (in the “extends” tag). Please correct me if I am
> wrong. Making it more explicit in the views is simple. E.g., it can be
> done like this:
> template = app_settings.path_to_template('base.html')
> return render_to_response(template, …)
> Here app_settings.py is a settings file that stays in the
> application's root folder; and path_to_template is an application-
> specific function, which returns absolute path to the template (using
> os.path and the name of the app's folder).
>
> Dealing with the templates that reference other templates (in the
> “extends” tag) seems a bit trickier... One way that I found is to use
> a variable in the “extends” tag. But that will require some code in
> the application-specific context processor, which in turn will need to
> be specified at the project level in settings.py in
> TEMPLATE_CONTEXT_PROCESSORS.
> In that case I can do something like this in the templates:
> {% extends <APP>_TEMPLATES.base %}
> where base is a key in the <APP>_TEMPLATES dictionary whose value
> contains absolute path to the base.html.
>
> This approach seems to be more explicit but also a bit more
> complicated and still depends on the settings at the project level (on
> the other hand, having an application-level context processor seems to
> be almost inevitable). And yes, my solution seems to be somehow half-
> baked…
>
> Can this problem with the “extends” tag be solved in a more elegant
> way?
> Am I digging in a wrong direction? Is it easier to just rely on the
> Django's template scanning order and to forget the whole thing?
> What do you think?
>
> Thank you,
> -igor
>
> >
> > Looks pretty good, the only thing I would change would be to prefix
> > templates and static files with the app name, by placing them inside a
> > directory named after the app, eg 'app/templates/app/index.html', as
> > this will avoid conflicts with other templates/static media.
> >
> > Cheers
> >
> > Tom
>
> --
> 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
> (mailto:django-users@googlegroups.com).
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com
> (mailto:django-users+unsubscr...@googlegroups.com).
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>
--
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.
