On Thu, Nov 12, 2009 at 1:31 PM, bruno desthuilliers
<bruno.desthuilli...@gmail.com> wrote:
> On 12 nov, 12:16, Maksymus007 <maksymus...@gmail.com> wrote:
>> I have some problem with templates and separating templates blocks.
>>
>> There is a list of messages. Some properties are common, some are
>> application specific.
>> Properties are just html columns :)
>>
>> I got following templates
>> main.html -> basic "frame", which consists of common html, headers, scripts
>> etc.
>> frame.html - which introduce additional division - tabs and content,
>> extends main.html
>>
>> app_specific.html - app specific tab lists - extends frame.html
>>
>> messages.html - common message list, which contains common properties
>> and block in the middle to add custom properites, extends
>> app_specific.html to be part of app, with proper tabs etc.
>>
>> app_msg.html - additional properties for messages list, extends
>> messages.html.
>
>
> This indeed makes quite a few layers. But anyway...
>
>> My problem is - i need different app_specific.html for different
>> app_msg.html
>
> Hmmm... Then I'm not sure your layering scheme is appropriate. Do not
> forget that while pretty cool, template inheritance is by no mean the
> only way to factor out / reuse template code. You also have simple
> inclusions and custom templatetags. It's hard to tell without reading
> your code, but it might be possible that getting the "message.html"
> layer out of the inheritance tree and refactoring it as an inclusion
> or custom templatetag solve your problem. If not:
>
>> - is there any way I can achieve that without using
>> variables from view like context['app_specific_frame'] =
>> 'someapp.html' ?
>
> You can't put *anything* before an extends Node, anything in a "child"
> template that's outside a block Node will be just ignored - even if
> it's just a "context extending" node [1] - and there's AFAIK no way to
> pass additional context thru the extends templatetag|2]. So this leave
> you with passing these "params" thru the context, one way or another
> (cf below).
>
> [1] I posted about this on the dev list last year or so - I had a
> working patch but well, I managed to solve my "problem" differently
> (and more cleanly IMHO) so I finally didn't bother opening a ticket
> and submitting the patch.
>
> [2] but while we're at it, I think I once saw some "better extends"
> templatetag somewhere - and well (thinking out loud), FWIW it should
> not be that hard to implement an "extended extends" tag that could
> takes more arguments...
>
>> I want to keep clear line between view and
>> controller.
>
> A bit OT, but <pedantic>in Django, you have views and templates - no
> controllers</pedantic>. But let's not waste time about terminology
> issues !-)
>
> I recently solved a more or less similar (even if probably way
> simpler) problem using the "kwargs" argument to url patterns.
>
> My problem was to pass additional per view project-specific context
> stuff to the templates - stuff that the app's views shouldn't be aware
> of, and that was not necessarily fitted for a ContextProcessor (like,
> which section of the main menu was to be 'hilited' for a given view,
> etc).
>
>
> The solution looks like this (simplified):
>
> 1/ in the project's urls.py, override the app's default urls and pass
> the extra context:
>
> urlpatterns = patterns('',
> url("^some/pattern/(?P<model_id>\d+)/$"
> "app.some_view",
> name="app_view_name",
> # project specific extra context here:
> kwargs={'extra_context':{'active_section_name'}}
> ),
> ...
> )
>
> 2/ in the app's views.py:
>
> def some_view(request, model_id, **kwargs):
> context = dict()
> # take care of eventual extra context, but without
> # assuming anything about it:
> extra_context = kwargs.get("extra_context", None)
> if extra_context:
> context.update(extra_context)
>
> # then proceed as usual to setup the context, render to response
> etc...
> # normal view code here
>
>
> This of course requires having full control on the app's views (or
> being willing and able to fork the app), but hey, it really helps
> making the app's views code "project-agnostic" for a very low cost.
>
> Don't know if this (or anything else in this post) can be a solution
> to your actual problem, but HTH nonetheless !-)
Well, yes, messages,html can be split into several files and then
app_messages.html can include them in order. But then every
app_messages.html must include them, which, in fact, is just
copy-paste messages.html with different {%extends %}
all I needed was to include a string within extended template and I
found http://www.djangosnippets.org/snippets/447/ which, despite its
age, worked (some changes were needed to have variables properly
handeled, but well) like a charm.
Then in app_messages.html i got:
{% load xextends %}
{% xextends "messages/messages.html" with parent="app/app.html" %} -
which points to my additional frame with tabs, etc. Exactly what i
wanted. Your solution is way cool, but again, its violates DRY -
additional code in every view (can be probably ommited by decorators,
but still, the same decorator for every view ;) )
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@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=.
