[Twisted-web] fragments with child lookup
markus at bluegap.ch
Thu Oct 12 13:41:00 CDT 2006
thank you for your answer, it's definitely not to long for me ;-)
L. Daniel Burr wrote:
> 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,
Yes, that's how Mason, Myghty and all those do it.
> 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.
Please define 'resource' here.
I agree with the 'should not have to depend on' statement if you are
speaking about programm code, i.e. perl or python objects.
Concerning HTML Fragments or templates, I do not agree. You don't want
to output a table row (<tr...>) if you are not in a table definition
I think it's important do distinguish between those two. I'm not sure
how to call it: code vs. design, controller vs. view or in your words:
dependency vs containment.
As of now, I don't know a decent way on how to represent containment in
nevow. (Yes, there are macros, but...) I very much agree with you that
it has nothing to do with (code) dependencies even (OOP) inheritance.
> 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
> your templates.
> 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?
Your 'scaling' is referring to the amount of human work, right?
Maybe it's not "template-per-segment", but some form of template
containment is necessary, IMHO. It reduces the amount of work for
> 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.
Well, some people even read mailing lists. So you've already helped
> 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
> equals inheritance.
Certainly URL segments do not equal inheritance in the code. Sometimes
not even containment on the template level (as in
"template-per-segment"). OTOH, the URL hierarchy very often resembles
the template hierarchy (especially for websites).
> 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.
Please define 'smart' ;-)
No, seriously, I'm not a fan of all of those, so...
> 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!"
Oh, I'm glad I'm speaking German :-)
> 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.
I guess they are all looking for the most colorful variant of 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.
I don't want to get into the sync vs async issue now, but it would
certainly be possible to write an async WSGI-like interface, doing
similar URL segment processing, content filtering and such. Why should
such a thing not be great if you consider WSGI to be "great for people
who like threads" (i.e. sync)?
As you might have guessed, I do not agree with your point of view
regarding the 'lego model'. I'm surprised to read that "pluggability ...
is a bunch of nonsense" from somebody who obviously knows OOP, python,
interfaces, etc.. I don't understand how you came to that conclusion (or
believe) WRT templates.
Again, thank you for your answer. I very much enjoy discussing such
More information about the Twisted-web