[Twisted-web] fragments with child lookup

L. Daniel Burr ldanielburr at mac.com
Thu Oct 12 14:36:50 CDT 2006

Hi Markus,

On Thu, 12 Oct 2006 13:41:00 -0500, Markus Schiltknecht  
<markus at bluegap.ch> wrote:

> Hi,
> 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:
>>  http://myhost.com/foo/bar/baz
>>  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".
> 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.

See http://en.wikipedia.org/wiki/Representational_State_Transfer

> I agree with the 'should not have to depend on' statement if you are  
> speaking about programm code, i.e. perl or python objects.

You can't get away from it: a python object is responsible for rendering
the template.  The template by itself is just a text file; in order to
define the kind of template inheritance you seem to prefer, you have to
do it in code.  So you are, in fact, enforcing dependencies in code.

> 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  
> (<table...>).

Precisely.  Given that you have to output the table anyway, you have
created a tight coupling between your "row" template and your "table"
template.  If you can show me how having a "row" template and a "table"
template as opposed to a single template describing the entire table,
is in any way useful to a designer, I'll be amazed ;)

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

I call it a misguided emphasis on componentizing templates, rather than
componentizing application functionality, but that's just me ;)

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

Nevow does containment just fine.  There is a tree of resources, that's
the containment.  I think you're just way too focused on html markup, and
that causes you to ignore the fact that a resource in the tree may be
more than just a means of emitting html to a browser.

>>  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?

Yes, and also to the performance of the application.  The more complex
your template nesting becomes, the slower the server will be.  The
common answer is "but, caching!".  My rebuttal: Caching is a great
thing, but it shouldn't be used as a means of making inefficient
architectures tolerably performant.  It should be used to make an
efficient architecture more scalable.  In other words, it should
be a vitamin supplement, not a pain-reliever.

> Maybe it's not "template-per-segment", but some form of template  
> containment is necessary, IMHO. It reduces the amount of work for  
> template designers.

There's the magic phrase: IMHO.  I simply can't agree with you on this,
as my own experience is the opposite of yours.

Creating snippets of html does *not* reduce the designer's work.  The
average designer uses tools, and those tools usually result in complete
page of html markup.  You're actually imposing more work on them, not
by making them cut-down their tool's output to match your vision of
template reusability.

Someone will doubtless object strenuously to my use of the phrase, "the
average designer".  Insert disclaimer about how my generalizations do
not apply to anyone else in the world, etc.

>> 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  
> somewhat!

I'm certainly glad if this discussion proves useful to someone.

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

It does?  Your statement assumes that most web sites do things the way
Myghty or Mason do.  I'd revise that statement to say "the URL hierarchy
in a Mason or Myghty application often (always) resembles the template

Whether the majority of web sites actually do things that way or not
is open to debate of course.

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

By "smart", I mean "possessed of intelligence, education, and experience".
That's certainly not the best definition in the world, but it is the one
I find useful.

I made mention of it to underscore the fact that simply because some
very smart people produce a solution, it does not always follow that the
solution is good.

The twisted devs are all very smart people, and they'll certainly attest
that there are things in twisted that didn't turn out to be great.  That
they recognize it, and work to improve those areas, is one of the things
I like about the twisted project.

>> 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 :-)

Nicht sprechen sie gut Deutsch, I'm afraid :)

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

Again, that's precisely my point.  Everyone likes their own idea best.

>> 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)?

Read the WSGI archives from the beginning.  You'll see the debate about
async apps, and you'll see why they decided that WSGI doesn't really
address asynchronous servers.  Trust me, the reasons are there, and
they are laid out in excellent detail by Phillip J. Eby.

Also, when I say "great for people who like threads", I am being mean.
I think people who like threads are hopelessly misguided, much as I
think people who focus on server-side template includes are misguided ;)

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

I was fairly certain you weren't going to change your views based on
any argument I might make.  This *is* the Internet, after all, and I
find very few cases where someone actually changes their mind about
anything as the result of a debate on a mailing list.

As for being surprised by my dislike of the "lego" model, I'll answer

According to some accounts, Emerson visited Thoreau in jail and
asked, “Henry, what are you doing in there?” Thoreau replied,
“Waldo, the question is what are you doing out there?”

> Again, thank you for your answer. I very much enjoy discussing such  
> design issues.

You're welcome.  I doubt we'll ever agree on these matters, but I
do believe in respectful disagreement.

> Regards
> Markus

L. Daniel Burr

More information about the Twisted-web mailing list