[Twisted-web] fragments with child lookup

Markus Schiltknecht markus at bluegap.ch
Thu Oct 12 13:41:00 CDT 2006


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.

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

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

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

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

Regards

Markus




More information about the Twisted-web mailing list