On May 5, 10:50 am, Thadeus Burgess <[email protected]> wrote:
> {{include}} must stay there for backwards compatibility.
---> yes, it can stay for compatibility; no problem. I just say I
think it is useless, and should be deprecated.
If you like, think of it this way: if you have a class, which
inherits from another class --- if the parent class is "called", it
does nothting with those who inherit it. In fact, it leaves
responsibility to those who inherit to perform, be called, extend,
override, etc. In a human sense, it is a parent who "allows" the
child to have responsibility (an adult, appropriately independent /
interdependent responsibility boundary).
{{include}} Takes responsibility FROM the inheriting "class" (in this
case, template);
For example, "layout.hml" isn't being called, - default/index.html
is.
So _why_ on earth is layout (the parent) constraining and dictating
the child's behaviors (that is, rendering, script setups, etc.). In
the human realm, this is "not letting go of apron strings"; in the
analogy of how classes work, this also has no parallel.
The only, pythonic parallel is when a class (for example (chooses
when / if to call it's parent's (for example) __init()__;
For everything / anything that {{include}} accomplishes here, now ---
I am stating precisely that the same functionality can be achieved
with a similar call to {{super block_name}} (only in this case, it
will be block inclusion -- the class inheritance analogy is only
partial, since this is more like macro inclusions --- but the concept,
the perspective of appropriate responsibilities still applies).
I have no doubts that it is precisely this impedence mismatch between
appropriate structuring (ordering) of responsibilities in templates
that is subtley, yet very directly getting in the way of effective
layouts, skinning, and easy design of user-options for skinning. Of
this I am sure.
> Basically, {{include}} will take any line from the child template that
> is not in a block that is declared in the parent and places it in
> {{include}}
> Simply, what gets left over is put into {{include}}.
Right - and I am saying this is upside down: what gets left over from
the layout (what is not in a block) is what should be the topic (_not_
the other way around). In fact it might become evident (once we have
blocks in place) that one of either the parent, or the child should
_not_ have any content not enclosed in a block - and if it is found
to, this should be treated as an error. The reason is exactly
because of this criss-cross responsibility between parent and child:
I think it is not useful, on the contrary is creating a rigid
situation which is inhibiting effective layout management (you only
need to look at why response.files.append is being used all over the
place, and the flow of where those get processed, which component
determines that sequence of processing to see it is a gordonian knot -
it must be broken!
>
> Lets see if I understand you correctly
>
> So what you are saying is, you want a block to be able to include the
> block it is replacing in itself, IE: ``{{super}}``?
Yes, but more generally to include "a" block from the extended file -
to have control / responsibility over layout (it is what was called,
after all)! -
>
> I do not understand what {{super some_part}} is supposed to accomplish ?
I wrote it this way because it is pythonic: "explicit is better"
We would not have {{block ...}} without a name identifying which
block you are referring to, so "super" is a reference to a block, only
instead of declaring one in "this" template, it refers to the block
in the "extended" template.
I do not know that there is any reason to prevent something like (for
example):
{{ block three_pane_body }}
...
{{ block right_pane }}
{{ super vertical_menu }}
{{ end right_pane }}
{{ end three_pane_body }}
It might be just the kind of idiom to best accomplish user selectable
location for menus (I am sure Massimo will chime in if this
_currently_ makes sense: {{ if menu_setting ==
default_layout_menu }} {{ super vertical_manu }} {{pass}} ... will
this makes sense? I don't know, but I do know the example is useful
regardless..
Another thing with naming super-blocks: it makes the parsing code
easier (you don't need to keep / use any information about the
current block in order to parse (include) the block - just dump the
named block from "super" (i.e. the parent tree of blocks).
I've already mentioned it's explicit for the person reading the code,
so 3 reasons to name super blocks. None (that I see) not to.
Finally, since I am making an analogy between template files and
inheriting classes, I ask you: is there any restriction in a class
method that _only_ the parent? In fact, in Python Super(cls,
instance) returns an object of the base class. Calling a base class
method is similar, e.g.:
class B(A):
def __init__(self, some_val):
self.some_action(some_val)
A.__init__(self, self.some_val)
is reasonable.
By analogy, you could want to enter a discussion for templates such
that
{{ layout.html verticle_menu }}
would be analogous to a class call such as A.__init__(), and in
templates would in effect include a block from another file.
Anyway, I don't know what the right syntax / implementation (exactly)
of a template "super" function is - I just know it makes sense, and I
think we should have it (I am certainly investing a lot of effort in
driving exploration of how it would work, look, and why we might want
it).
>
> From a user perspective, it would look like this?
>
> #layout.html
> <h1>
> {{block title}}
> {{=request.function}}
> {{end}}
> </h1>
>
> #index.html
>
> {{block title}}
> <div style="custom1">
> {{super}}
> </div>
> {{end}}
>
> Which will render out to
>
> <h1><div style="custom1">{{=request.function}}</div></h1>
>
> ? If I understand you correctly, then lets discuss the feasibility of this.
>
Yes, exactly - it would behave like an "include" of a block - it would
behave just like outputting any other included block.
One discussion that seems hanging, and needs to be covered with some
thought (still, I am quite sure):
While a parent layout having an "empty" block, suck as
{{block include_child}}{{end include_child}}
is functionaly equivalent to current behavior of a parent containing:
{{include}}
and inserting the child there, the issue of responsibility comes into
play, and needs careful consideration.
Currently, the "layout" (i.e. ordering and placement) of blocks is
_dictated_ by the parent. The parent is not called, and yet it is in
control, and I think this is a problem.
If there is no child template, this is equivalent to voluntary
acquiescing to hand control over to "layout.html", and that is
appropriate - it is equivalent to an adult saying "can you do this for
me?" and having another agree to.
BUT - when there is a child, should not the child set (voluntarily?)
layout order, including additions? Particularly placing additions.
In fact, this might be the place where a
Template.Super('layout.htmlm') does something equivalent to Super(),
i.e. return the current layout (i.e., the current ordering and nesting
of blocks, so that the child _may_ follow, or _may_ modify
As it is now, the only way a child knows what that layout is, is when
the _programmer_ looks at the layout file. It seems to me this makes
it impossible to "skin", since that can change the layout. By only
allowing _one_ insertion point for the child, this is "not a problem"
but it also fails to enable behaviors which would be useful to
skinning and layout.
This change would potentially be a little more significant that adding
blocks to templates, so I hope people digest what I've said, think
about it --- simmer on it a bit.
The "super" in the sense of including a parent's block seems like it
is a gimme, and will be useful both immediately, and later
(considering repairing the scope of responsibilities of template
files). The only thing which is important is to consider is the
syntax (so it doesn't get in the way later).
Super might be best reserved for other things.
{{extended block_name}} would preclude ever extending from more than
one (something you might want to do, once the responsibilities are
appropriately laid out).
I think probably something like {{ 'layout.html' block_name }} , or
{{ block layout.html::block_name}} might be clear, whichever way we
go in the future.
Thanks for all the efforts to bring us blocks, and for entertaining my
discussions.
Kind Regards,
- Yarko
> --
> Thadeus
>
> On Wed, May 5, 2010 at 9:42 AM, Yarko Tymciurak
>
> <[email protected]> wrote:
> > nclude} # single insertion point of child content: I argue this
> > is useless - a special case of an empty block, but unfortunately
> > _only_ one point, so ... rigi
