First off -- let me say that my usage of the templating in this case
is somewhat peculiar, and if they are not supposed to work like this,
that is fine.
After reviewing my app, I only have one instance of code like this,
and it is "vestigial" and should be removed anyhow. But I thought it
strange that it broke, and I'm wondering if I might have another
include/block problem.
Solution:
diff -r fe58378e989b gluon/template.py
--- a/gluon/template.py Wed May 04 18:58:40 2011 -0500
+++ b/gluon/template.py Thu May 05 14:46:21 2011 -0500
@@ -454,7 +454,8 @@
writer = self.writer,
delimiters = self.delimiters)
- content.append(str(t.content))
+ content.append(t.content)
+ #content.append(str(t.content))
def extend(self, filename):
"""
Read on for how I got there and a strange LDAP_auth issue...
On May 5, 1:37 pm, Massimo Di Pierro <[email protected]>
wrote:
> Hello kasapo,
>
> I do not completely follow you code. If I do, you have two blocks. The
> code included in one of the blocks seems to extend a block included
> in another block. I am unsure this is supposed to work. Anyway, let's
> try figure out what has changed that broke and then we may be able to
> revert the previous behavior.
>
So I have this structure:
bare (defines html, head, style, script (jquery includes), body
sections, and some containing blocks) -- ancestor to almost all
templates
right-col (included by bare, defines blocks which base will extend --
base extends bare, bare includes right-col so therefore base should be
able to see blocks defined by bare)
base (defines styles, background, etc -- the base template for most
things -- defines actual markup for blocks which are DEFINED in right-
col)
page (extends base, does not use blocks -- the menu rendered on the
page view is defined in base inside of a block that is defined in bare
via right-col include)
page-no-side-nav ( extends base, uses {{ block right-col }}{{end}} to
delete the right column )
> Can you try:
>
> hg revert -r 1488 gluon/template.py > ~/Downloads/template.diff
>
Sadly, I am on RHEL and mercurial isn't present... so I will use my
local machine (Macintosh).
First off, I use LDAP authentication for a login method, and (this
happened on 1.95.1 on RHEL server as well) I get this error:
Traceback (most recent call last):
File "/Users/csburreson/web2py/gluon/restricted.py", line 181, in
restricted
exec ccode in environment
File "/Users/csburreson/web2py/applications/icecube/models/
0_init.py", line 42, in <module>
from gluon.contrib.login_methods.ldap_auth import ldap_auth
File "/Users/csburreson/web2py/gluon/custom_import.py", line 80, in
_web2py__import__
return _old__import__(name, globals, locals, fromlist, level)
File "/Users/csburreson/web2py/gluon/contrib/login_methods/
ldap_auth.py", line 5, in <module>
except e:
NameError: name 'e' is not defined
So I just copied the working ldap_auth.py from the 1.89 version of
web2py... problem solved (could this somehow create an issue with
templates?)
Then I realized I did not have python-ldap installed, so I did
easy_install python-ldap and all was good.
[I did exactly these same things earlier today when installing the
TEST server]
SO, now the application is again working, and I check out my code into
the applications folder using SVN.
The menu is not present :(
Then I run :
hg revert -r 1488 gluon/template.py
And check my app and the side menu IS present
So, I go back to 1.95.1 (with the exception of the old ldap_auth.py
from 1.89)
and try
hg diff -r 1488 gluon/template.py
This bugger seems to be the culprit:
@@ -455,7 +454,7 @@
...
+ content.append(str(t.content))
- content.append(t.content)
After changing it, i verified that I had not changed anything else by
re-diffing the file against the repo:
bash-3.2$ hg diff gluon/template.py
diff -r fe58378e989b gluon/template.py
--- a/gluon/template.py Wed May 04 18:58:40 2011 -0500
+++ b/gluon/template.py Thu May 05 14:46:21 2011 -0500
@@ -454,7 +454,8 @@
writer = self.writer,
delimiters = self.delimiters)
- content.append(str(t.content))
+ content.append(t.content)
+ #content.append(str(t.content))
def extend(self, filename):
"""
So, that seems to be the problem.
Is there a case where not explicitly calling str() on the content
causes something else undesirable to happen?
Well, thanks very much Massimo, mystery solved. I'll leave it to you
whether this is actually an issue that should be patched or an
unnecessary mis-use of templates and {{block}}s
I plan to remove the include of right-col since in the end I really
don't need it.
-Kasapo
> Dow it work?
>
> If yes, download the latest web2py again and do
>
> hg diff -r 1488 gluon/template.py > ~/Downloads/template.diff
>
> you will see what has changed in the file. mostly comments.
> Try manually revert each of the changes. Which ones causes the
> problem?
>
> On May 5, 11:55 am, kasapo <[email protected]> wrote:
>
>
>
>
>
>
>
> > Hi all,
>
> > I recently setup another instance of web2py for testing on a new
> > system, and noticed something strange with blocks.
>
> > Basically, I have three slightly different versions of web2py running:
> > 1.89.3 (DEMO server), 1.91.6 (DEV server) and 1.95.1 which I just
> > installed with the auto-upgrade feature (TEST server -- soon to be the
> > Production server).
>
> > The problem is, i have an include directive inside of a block/end
> > block pair. The included file (right-col.html) then goes on to define
> > a couple other blocks (for navigation mainly) which are filled in by
> > different templates associated with different areas of the site.
>
> > However, templates which extend the file which includes right-col.html
> > do not have access to BLOCKs that are defined INSIDE of right-
> > col.html, but this behavior occurs only on the TEST server (v1.95.1)
>
> > This code WORKED before 1.95.1 (on DEMO and DEV):
>
> > #################
> > # views/bare.html
> > #################
> > <html>
> > ... (abbreviated for brevity's sake)
> > <div id='content'>
> > {{ block content }}{{ end }}
> > </div>
>
> > {{ block right-col }}
> > {{ include 'base/right-col.html' }}
> > {{ end }}
>
> > ...
> > </html>
> > #EOF bare.html
>
> > #######################
> > # views/base/right-col.html
> > #######################
> > <div id='right-col'>
> > {{ block nav }}
> > {{ end }}
>
> > <section id='social'>
> > {{ block social }}{{end}}
> > </section>
>
> > </div>
> > #EOF
>
> > #################
> > # views/base.html
> > #################
> > {{ extends 'bare.html }}
>
> > {{ block content }}
> > {{ include }}
> > {{ end }}
>
> > <!-- defines stuff inside of right-col -->
> > {{ block nav }}
> > <nav id='side-nav'>
> > {{=MENU(get_menu(request.controller) or standard_menu)}}
> > </nav>
> > {{ end }}
>
> > {{ block social }}
> > ... stuff to do with social networking
> > {{ end }}
> > #EOF
>
> > ####################
> > # view/some-page.html
> > ####################
> > {{ extends 'base.html' }}
>
> > Blah blah blah. Wait, my side menu is missing. Crap.
>
> > But the outline of the sidebar is still there since div#right-col is
> > present....
>
> > #EOF
>
> > What I had to do to get it to work with the TEST version was to take
> > away the include statement for right-col.html and move the contents of
> > the file inside the right-col block in bare.html. This works fine.
>
> > The strange thing is that the <div id='right-col'><section
> > id='social'></section></div> (the markup in right-col.html) shows up
> > -- even if I wrap it in a block within the included file. The problem
> > is just that the template blocks defined in the right-col.html file
> > seem to be forgotten later on in the template. So even though
> > bare.html includes right-col, the base file, which extends bare,
> > cannot access the blocks defined in the right-col file. Thus, when
> > rendering "some-page" which extends "base", the contents of the right
> > column aren't included.
>
> > So, the question:
>
> > Is my usage of blocks improper? Or is this an undesired outcome of
> > code updates?
>
> > I just checked the code.google.com page and did not see any issues,
> > open or closed, that mentioned anything about this.
>
> > Thanks,
> > Faithful web2py user
>
> > PS:
>
> > I think the reason I did this was to be able to reuse HTML chunks
> > which might be included in different places on the page, or even among
> > different templates from the site (e.g. bare.html is the ancestor of
> > most public pages, but user.html is the ancestor of another, and both
> > should be able to use right-col.html).
>
> > Also, I would love to see the include directive supported within for
> > loops, though I think I see why it is not. I think the include
> > directives are always handled first and the file is included before
> > the template is parsed, thus template variables are not available and
> > loops cannot be iterated. Oh well.
