On May 5, 9:56 pm, Thadeus Burgess <thade...@thadeusb.com> wrote:
> Right.
>
> As much as I would like the functionality... This cannot be done as
> the system stands. Child templates know nothing of their parent,
> therefore they are unable to request anything from the parent
> template.
>
> The way that you effectively override a block is by effort of the
> parent looking at all its children and going "Hey, you have the same
> block I do, so I will use yours".
This should be no more a problem than inheritence of classes - that
is, none.
The only "problem" now is the parent trying to figure this out - when
it shouldn't be doing more than handing it's stuff - it's blocks as
objects - to the next offspring, and so on.... the offspring then
either uses, ignores, overrides, or incorporates with own (as in
"super" - which is just a name-space thing).
All this is simple tree handling, and should not be any trouble.
PARTICULARLY: if it (the tree of blocks) is handed down to the next
person who is going to carry it (much like real children) until the
final one delivers his version to the client.
The problem is really in the upside-down concept of "knowledge"; we
straighten that out, and not just this will get easy: templating, and
implementing (and controlling) user-level custom skinning &
modifications will get easy, I think.
>
> So the way to do this, is for the child to know about its parent, and
> its parents parents, and parents parents parents (etc, depending on
> the level of hierarchy.)
To just have the tree, and the tree "available" (here's your box of
goodies from your family; "Oh! Look! A toy train-block; and there's
a teddy-bear-block! and... and.... oh, I'm going to throw away
grandma's doll-block, we wont use that in _this_ view) :-)
The only reason to have "super" is name-space: I have a bb-gun; dad
gave me one too; I want to play with _both_.
So: {{block BB_gun}} is not specific enough. You have a stack of
BB_guns; super.BB_gun is the one just before the one at the top or
the stack.
> The issue is, how does this element then
> determine which parent it should pull from, assuming the grandparent
Which parent - address that later. A tree of objects should be
suffiecient; when there is more than one object with the same name,
treat it as a stack.
You can walk up the stack if you want _all_ of them.
Later, you can add attributes to the stack (template name), and
select / search in that way.
The Python parallel of Super(cls, ....) could return / extract the
tree with only items from the "stack" of elements with attribute
"cls" - in our case, template names (e.g. "layout.html").
But for starters, I am not sure we will want or need that - let's just
not preclude it / not put anything in the way of us easily doing it
when / if we want.
- Yarko
> defines a block, and the parent overrides the block, what is left is
> not what is intended.
>
> --
> Thadeus
>
> On Wed, May 5, 2010 at 8:28 PM, Yarko Tymciurak
>
> <resultsinsoftw...@gmail.com> wrote:
> > nyway, 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 w
