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
_______________________________________________
Twisted-web mailing list
[email protected]
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
