[Twisted-web] fragments with child lookup

Markus Schiltknecht markus at bluegap.ch
Tue Sep 26 14:41:50 CDT 2006


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]).



[1]: Zope 3 FAQ:

[2]: Wikipedia about Zope:

[3]: http://www.zope.org/Wikis/zope-dev/AcquisitionMadness

[4]: Problems with WSGI:

[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
                 return ()
         return _

class ContactInfoPage(BasePage):

class ContactPage(BasePage):
     addSlash = True
     child_info = ContactInfoPage

class ProductsPage(BasePage):
     addSlash = True
     products = True

class EnterPage(BasePage):

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>

More information about the Twisted-web mailing list