right after I wrote this (especially about clases, calling "super"
class methods), perhaps a more useful, and general function than
what I just suggested for {{extends}} (that being: just append to
parent's block), would be NOT to do that, but rather have a {{super
blockname}},
which would be valid within a block, and would literally work like
the class "super";
This would be more general than what _I_ had suggested for {{extends}}
since you would be able to WRAP a parent's block in this way (i.e.
either prefix a parent's block; append it, o}}r wrap it).
Of course, the additional gain: it would not confuse, would allow
leaving the current "common use" of {{extends file}} as a way to
declare lineage (i.e., a parent).
This _is_ exciting!
- Yarko
On May 5, 2:35 am, Yarko Tymciurak <[email protected]>
wrote:
> On May 5, 12:11 am, Massimo Di Pierro <[email protected]> wrote:
>
> > Less that two days ago Thadeus made a request:
>
> > http://web2py.uservoice.com/forums/42577-general/suggestions/702804-b...
>
> > for this to be supported in web2py:
>
> > http://docs.djangoproject.com/en/dev/topics/templates/#template-inher...
>
> > Today Thadeus sent me patch that implements it. It is a complete
> > rewrite of the web2py template module with better comments, new
> > functionality and - of course - backward compatible.
>
> NOTE: Blocks are a general extension / inheritence point, and will
> help write website templates, not only for layout but also for dynamic
> adaptation.
>
> In general, an "empty" block should be "just like" the old template:
> {{ extends somefile.html}}
> In taking a quick look at the code, it appears as if they've made
> {{include}} from parent templates continue in backward
> compatibility.
> I also see a hint that an {{include}} could have an {{end}}, so I've
> got some questions (maybe some test cases for the code will help clear
> it up).
>
> For example: with the keyword: {{block name}} ==> I would
> expect that "inheritence" behavior is accomplished. That is, any
> such block in a parent would be replaced by the same-named block in
> the child (recursively). I believe this is what we have here.
>
> What I'm less clear about, looking at this is 'extends'. It looks
> like (and I expect) that {{extends}} will behave as it did before,
> that is it will "replace" an empty, unnamed block (and for backward
> compatability, this is the block aliased as {{include}} ).
>
> What I _hope_ --- but am not clear about, is if 'extends' has also
> been given the power of 'block', that is - if it is general: i.e.:
>
> {{ [block | extends] blcok-name }}
>
> such that {{ extends blockname }} will act like
> blockname.append (and if blockname is a filename, will extend the
> unnamed, or "plain include" block in the named file.
>
> If not for backward compatibility, I think we do not need to refer to
> filenames at all, as {{extends blockname}} is general, and for the
> current behavior of "insertion" decays to extending an empty block.
>
> I welcome multiple insertion points and block-override ("inheritence")
> points.
>
> I have one remaining question: currently the "parent" is named by
> {{extends filename}} at the beginning of the child template.
>
> With this change, how will that be handled? The "old" meaning of
> extends was overloaded with 2 actions: name my parent, and
> "override" (i.e. 'insert myself') the "empty" {{include}} block in my
> parent.
>
> The _more general_ version here (multiple extension points; multiple
> inheritance-override points) extends seems like it's previous two
> functions need to be split out.
>
> Django, for example, uses "extends" to indicate "inherits from", but
> that looses the opportunity to "piggy back" (extend) blocks. This
> is a _great_ opportunity to go one better.
>
> I would like to propose this addition:
>
> [ ] REALLY do {{extends ...}} as I have suggested here; it is
> symmetric, and I think will be useful (particularly when applying
> "styles" to sites);
> This will give us the template equivalent of a derived class _adding_
> the parent class (e.g. initializer).
>
> [ ] If the first {{}} template directive in a file is
> {{ extends ...}} FOR BACKWARD COMPATIBILITY: assume the argument is
> a filename, and process it as a deprecated version of this new
> directive:
>
> [ ] New Directive: {{ inherits filename}} --- to do what
> "extends" does now in web2py (and django, I think), but says more
> explicitly what the intended action is: it states a parent.
>
> IF an {{include ....}} 'ed file inherits, should this be:
> - valid composition (?), i.e., the "stylesheet" for a side menu
> could be composed and applied this way in a component-like way.
> - invalide (and assumed that the include-er should have included
> the "parent"
>
> If you think about user changeable styles, I think the first option
> has clear appeal.
>
> Thanks for this great direction guys. I hope these steps (and
> perhaps my suggestions, after people think about, comment abou thtm)
> will make for a truly orthogonal, skinnable templating package. I
> went thru this rather quickly (and I am quite positively excited about
> the change!), so I hope I didn't miss anything, misunderstand anything
> - if I did, please correct.
>
> Regards,
>
> - Yarko
>
> I'm just scanning through the code change, and it looks like they have
> made "extends" general
>
>
>
> > Please help us test it. Here you can get the latest trunk:
>
> >http://web2py.com/examples/static/nightly/web2py_src.ziphttp://web2py...
>
> > Thank you. This is a big improvement.
>
> > Massimo
