[Twisted-web] fragments with child lookup
Markus Schiltknecht
markus at bluegap.ch
Tue Sep 26 14:41:50 CDT 2006
Hi,
your answer was quite a 'hammer' for me. I've slept over it and though a
lot about it. Up until now I've been a firm believer in the 'render each
URL segment as a child of another segment'. Especially with HTML::Mason,
I've done quite some websites, which follow that architectural
principle. Thus questioning that is quite hard for me.
Anyway, I'm willing to learn. And I like to question things, so I have
decided not to give up, but to try to do it the nevow way (yes, without
that ContainerPage thing).
Thus I think neither Valentino's efforts nor yours are all wasted. And I
hope he, you or other nevow hackers still has enough patience to answer
my questions.
L. Daniel Burr wrote:
> For an example of how awful this kind of design strategy is, please Google
> for anything involving Zope Acquisition. It ends up as a nightmare of
> complexity, and the Zope guys got rid of it after a lot of painful
> real-world experience.
The FAQ for Zope 3 [1] says: "I expect implicit acquisition to fade from
usage. Acquisition will still be important, but will be more explicit,
more predictable, and ultimately, more useful."
"The use of acquisition has been severely narrowed in Zope 3." says the
Wiki Page about Zope in [2], but unfortunately no reason is given.
The Zope wiki has three links from 'AcquisitionMadness' in [3], two of
them descripbe acquisition, (mostly saying it's powerful but complex),
the third is called 'AcquisitionProblems', but it states right at the
beginning, that the problem 'was fixed'.
So unfortunately, I'm still unclear about what's so awful about it.
Honestly, I also have to admit that I don't completely understand what
Acquisition exactly is in Zope.
> I agree the concept is simple, and I understand why so many people find it
> tempting. This is why we have WSGI (another bad idea IMO), and various
> implementations of "render each URL segment as a child of another segment".
Yes, most people like simple concepts. The question is: does it
over-simplify? Does it make other things impossible or overly complex?
Above, you state that it "ends up as a nightmare of complexity". But I
don't see how WSGI (or other implementations) would make anything else
more complex. A discussion about problems with WSGI in [4] brings up:
- a missing base wsgi package
- slow when servinc static files
I agree with the writer, that serving static files via WSGI is a pain.
But it can easily be circumvented with a reverse proxy or by letting the
server (apache) serve static files.
> Again, I think this is terrible. All you've done is inflict the hell of
> an arbitrary number of server-side includes into the rendering process.
What harm does that do? It's not like that number is growing
exponentially. In contrast to CPUs, the 'processing power' of template
designers is not growing steadily.
> I'm sorry, but I don't, and I feel very strongly that attempts to provide
> this kind of rendering strategy within nevow are misguided. Twisted does
> provide WSGI support, via web2; please consider implementing this as some
> kind of WSGI rendering component, so that you can leverage the behavior
> you desire without promoting this style of coding within nevow itself.
Okay, okay, I won't. I want to learn the nevow way (and why it's
superior). Please help me with that (see [5]).
Regards
Markus
[1]: Zope 3 FAQ:
http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/FAQ
[2]: Wikipedia about Zope:
http://en.wikipedia.org/wiki/Zope
[3]: http://www.zope.org/Wikis/zope-dev/AcquisitionMadness
[4]: Problems with WSGI:
http://lucumr.pocoo.org/entry/wsgi-and-the-unsolved-problems/
[5]: My current pages.py code.
Hopefully a more nevow-like approach: based on the 'render_switch' I do
turn on or off certain parts of the template (the docFactory of the
BasePage). I'm currently only using one template, but I could easily
split and use macros to include them, as Valentino taught me.
I'm tempted to write a docFactory which compiles a template from
multiple files, instead of using macros. That could automatically
include all the 'switches' in the template and the designer would not
have to hard-wire all children by hand. This would already serve my
needs, I guess. Would this still count as 'nevow like' or is it a no-no-no?
from nevow import rend, loaders, tags as T, inevow, static
class BasePage(rend.Page):
docFactory = loaders.xmlfile('templates/common.html')
title = 'per page title'
main_menu = 1
def render_title(self, ctx, data):
ctx.fillSlots('title', self.title)
return ctx
def render_switch(self, attr):
assert(attr is not None)
def _(ctx, data):
if hasattr(self, attr) and self.__getattribute__(attr):
return ctx
else:
return ()
return _
class ContactInfoPage(BasePage):
pass
class ContactPage(BasePage):
addSlash = True
child_info = ContactInfoPage
class ProductsPage(BasePage):
addSlash = True
products = True
class EnterPage(BasePage):
pass
class RootPage(BasePage):
addSlash = True
default_background = 1
main_menu = 0
child_kontakt = ContactPage
child_products = ProductsPage
child_layout = static.File('layout')
child_enter = EnterPage()
The template has lots of blocks like that one here:
<nevow:invisible nevow:render="switch products">
<div id="products"><img src="..." border="0" /></div>
</nevow:invisible>
More information about the Twisted-web
mailing list