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 !-)
--
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=.
