[Twisted-web] fragments with child lookup
L. Daniel Burr
ldanielburr at mac.com
Thu Oct 12 12:12:02 CDT 2006
Sorry I've been so tardy in responding, and thanks for reminding me.
On Thu, 12 Oct 2006 03:57:03 -0500, Markus Schiltknecht
<markus at bluegap.ch> wrote:
> L. Daniel Burr wrote:
>> I'm a bit busy today, but I will respond in greater length about why I
>> not care for the "every URL segment is a template" design approach, and
>> what I prefer to do instead.
>> Also, thanks for actually reading up on Zope Acquisition and WSGI
>> I'll try to explain where I think they go wrong.
Ok, first things first. The reason I hate "template per segment" designs
is the same reason that I hate Zope acquisition. They both suffer from
the same illness, which is complexity. Take the following URL:
This URL identifies a resource, and when some client requests this URL,
a representation of that resource will be sent to the client. In order
to render this representation in "template-per-segment" design, I have
to first traverse the tree and render "foo", then "bar" then lastly,
"baz". This enforces a needless dependency upon containment. Why does
the resource living at "baz" have to depend upon "foo" and "bar" in
order to produce a representation of "baz"? Answer: It doesn't have to,
and it shouldn't. By imposing this kind of dependency, you are *not*
gaining the componentization you desire; on the contrary, you've now
got tight coupling, and changes to the way "foo" is rendered may cause
problems when rendering "bar" or "baz". The longer your URLs get, and
the more segments you have to render, the greater the likelihood that
you are going to start breaking stuff each time you fiddle with one of
The same argument applies to acquisition. In the above example, let's
suppose that I need to access an object, named "userData". Using the
acquisition model, this means that first "baz" will be searched, then
"bar", then "foo". If you are lucky, or extremely careful, you can
code to avoid problems with this, but sooner or later, you will run
into the situation where more than one resource in the URL has a
userData object. When this collision occurs, the userData object
nearest to the end of the URL will be used. Maybe that is what you
want, but maybe it isn't.
Put more simply, the problem with both "template-per-segment" and
acquisition is that they do not scale. Cannot scale. Will never
be made to scale without massive effort on the part of the coder,
and weren't you thinking that you wanted this model because it would
be *less* work?
> My current project which started all this is almost over now. As you
> might know, I tried to do it the nevow way. And I guess I've come to the
> root of my problem: I'm more looking for a _website_ building system,
> while nevow seems to be a system to build web applications. Which is in
> no way meant to put nevow down, it just has a slightly different focus.
This is an excellent observation. I find that I build far more web apps
than web sites, in my work, although it seems that the vast majority of
developers seem to still be building sites. Note though, that I do not
think that the "template-per-segment" design is good for large web-sites
either. The scale argument still applies.
That said, nevow could certainly use some help in documenting what the
"best practices" are, for building both nevow sites, and nevow apps.
I have long had good intentions about helping in this area, but I have
so far failed to find time to do it.
> Another thought I've had was: most probably I could come away with just
> having the templates split up. I don't need (and as you have pointed
> out, it's probably dangerous) to split the code behind. One way to do
> that would be writing a docFactory which compiles a template from
> multiple XML fragments.
That's not a bad idea. Another idea is to simply stop worrying about
HTML duplication, and let each URL segment be fully responsible for
rendering itself, rather than enforcing a meaningless inheritance
model on what should be a simple resource. Seriously, URL segments
show containment, but nowhere is it written in stone that containment
Once you stop thinking this way, you can achieve great flexibility, just
as using interfaces is more flexible that relying on subclassing.
> Anyway, before writing any code I'd love to hear what concepts others
> have in mind. Especially your argumentation against WSGI would be
> interesting for me.
WSGI. This is one that I am virtually certain to be alone on. The
fact is, some very smart people came up with WSGI. Another fact is
that some very smart people came up with SOAP, WSDL, UDDI, etc.
I find WSGI of little value because, to me, it is just another attempt
at creating the "lego" model. Every once in awhile, some smart people
get together and try to come up with a component model that will truly
give them "lego" style pluggability. WSGI is all about saying, "hey,
choose whatever app server you want, as long as it speaks German. Want
a session component? Go ahead, use any one you like, as long as it
speaks German. An ORM? If it speaks German, you're good to go!"
Seriously, the whole pluggability, freedom-of-choice thing is a bunch
of nonsense. Who the hell cares if you can plug stuff together, when
it all has to plug together in the same way? Any color you want, as
long as it is black.
Also, I've been using twisted since version 0.9 or so, and WSGI is
very honest about saying that it doesn't really have anything useful
to contribute to the async model of web development. WSGI is really
great for those people who like threads, and that's great for them.
For people who prefer async architectures, WSGI will never be a good
fit. Note that web2 does support WSGI, but in order to do so, it
has to give up most of the value of being async.
One last gripe with regards to WSGI: It claims to be a solution to
the problem of "too many web stacks" in Python-land. In reality,
it is just another attempt at creating The One True Stack, and I
have been opposed to that since the first blog appeared,
complaining that other languages are "winning", due to the existence
of one overwhelmingly popular choice for web dev.
Many people will disagree with my stance on these topics, I'm sure.
On the other hand, this rant is so long that many will simply avoid
Have a good one,
L. Daniel Burr
More information about the Twisted-web