On May 6, 2:22 pm, Thadeus Burgess <[email protected]> wrote:
> We don't need an {{import}} you can already do that with {{include}}.
.... include inserts (textual); I intended that import would make
available block content definitions,
for my template to call on - but would not insert block-content into
the output tree...
Maybe you are right - include is macro in scope (you include the whole
thing);
Import is ... "here is stuff from my list of blocks - use whatever you
want"
and would be a way to have related things defined in one file , one
place...
I'm not sure how important that will be in practice, but my point is
that.
I want to try to describe how to write templates to design a site, in
a way you can
co-work with a site UI/graphic designer..... so I want to push the
pieces that really
can be, and make sense to be view things, out into the view file.
I also want to structure that file in a way that is simple and easy,
and clearliy
reflects the page, it's layout, and it's "skinning", position, and
content parts.
Anyway, my concept of include and import are distinct.
>
> {{include functions.html}} # which defines child_page_items
but would also place them all on the page; I want to defer the
placement to _this_ template file (the one which is doing the...
well, import)
>
> {{for page_item in child_page_items(page_items):}}
> etcetc.
>
> As far as layout, thats just a variable
>
> if (user.preferences.layout == 3): extend layout3col.html
> if (user.preferences.layout == 2): extend layout2col.html
How would this work, be written???
is it:
{{ if (user.pref.layout==two_panel): extend layout2.html }}
as the conditional form of
{{ extend layout2.html }} ? Could you also write this as:
{{ if (user.pref.layout==two_panel): }}
{{ extend "layout2.html"}}
>
> Also, as a note, {{extend}} will take a varaibel, so you can do something
> like..
>
> return dict(pages=pages, layout=user.preferences.layout)
>
> {{extend layout}}
Ok - this is very powerful, and very cool, then.
That means something like this is valid too:
{{ if (user.pref.layout==two_panel): }}
{{ layout_type = "layout2.html" }}
{{ extend layout_type }}
Very exciting.
Maybe the next step for me (then) is to write a tutorial
on page layout and design in web2py (as I would like to write it),
and get your feedback on that --- on how we would like to be able to
do things (or how we already can, but I am not aware of)....
That would probably be a good next excercise...
If you can help me coblle up a template2.py prototype to try to
use, while doing this kind of tutorial excercise, then we could
discover what else might be called for (if anything).
I'm feeling really positive about this.... cool stuff...
I'll send you private mail, how to move with this... hopefully, you'll
want to review, comment, help.
- Yarko
> --
> Thadeus
>
> On Thu, May 6, 2010 at 2:15 PM, Yarko Tymciurak
>
> <[email protected]> wrote:
>
> > On May 6, 1:52 pm, Thadeus Burgess <[email protected]> wrote:
> >> I need an example of "dynamic skin behavior".
>
> >> Code. (even if pseudocode). I need some code to understand.
>
> > .... more:
>
> > App has layout with header, status bar, body, footer.
> > Any app page can use a body layout (within the main site page layout)
> > this is application designers decision / choice.
>
> > One page (main) uses standard 3-panel template;
> > Most detail activity pages use 2-panel template for body;
> > Maybe admin, or "heaving interaction" / busy pages use 1-panel body.
>
> >> --
> >> Thadeus
>
> >> On Thu, May 6, 2010 at 1:48 PM, Yarko Tymciurak
>
> >> <[email protected]> wrote:
> >> > ther than fixing the point of responsibility point, and making the
> >> > actions naturally there to try to enable effective skinning, I have no
> >> > pre-insights... I am exploring... I think more than include is
> >> > needed for dynamic skin behavior (at a higher level than simply
> >> > manipulating css - you can do
