On May 5, 8:58 am, mdipierro <[email protected]> wrote:
> I am not completely sure I understand. I think you should try what is
> there now and see if already does what you ask. If not, please provide
> an example of what you expect and what you get. One issue is that
> tamplates have to be bytecode compiled. Mixing logic with pure
> template keywords sometimes makes compilation not possible.
I don't think what I'm talking about affects bycode, nor "mixing
logic" any more than current template provides; merely an additional
directive.
I just looked at the code.... It still looks like skinning will be
difficult, because the net effect is the "document" is constrained to
3 parts....
Think of it in graphical terms, read my post;
To be able to ADD to a block, and choose order (i.e., if I want to
wrap a new div around a parent's block because my user has added a
skin, I need to add something to the beginning AND the end of a block
--- if I replace it, I have to know too much).
If I have {{super someblock}} as a form similar to how it is used in
classes, now a child can effect skinning:
New color for menu frame:
{{ block some_menu }} # but I don't want to replace it all - just
wrap my div around it, maybe
{{ = head_of_menu_skin( some_settings ) }}
{{ super some_menu }}
{{ = closing_of_menu_skin( some_settings2 ) }}
{{ end some_menu }} # I didn't check if endblock naming is tolerated
- if not, it should be...
I think this cannot be currently done, and will enable effective
skinning. Block overrides in this case require too much knowledge;
simply being {{include}} ed in my parent is too rigid.
I think the right mix of actions is:
{{ extends declared_parent }} ## currently there
{{ include some_helper }} # currently there
{{ block some_part }} # currently there, but only for replacement
- too limited, I claim;
# {{super}} solves this: creates a way to "extend", "decorate",
pre-pend etc. a block
{{ super some_part }} # not there - I argue needs to be added, is
important (_and_ pythonic)
in parent:
{{include} # single insertion point of child content: I argue this
is useless - a special case of an empty block, but unfortunately
_only_ one point, so ... rigid
Think about it. Think about it in the context of designing user
modifyable skinning (i.e. user settings)
- Yarko
>
> On May 5, 2:42 am, Yarko Tymciurak <[email protected]>
> wrote:
>
> > 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
