On Feb 24, 2009, at 12:59 PM, Shane Hathaway wrote:
> Jim Fulton wrote:
>> I disagree strongly with many of the assertions made in these
>> articles. (I can't judge the pipeline proposal, since it is only
>> fleshed out in code.) While I do think zope.publisher has some
>> problems, they aren't the same problems that shane sees.
> What are the problems with zope.publisher as you see it?
- It has too many dependencies. Obviously.
- It has too much in it. This contributes to the large number of
- I think the attempt to support multiple protocols through different
request types has turned out to be a mistake. I think it was a
reasonable approach to try, but I don't think it turned out well, in
part because it seems too heavy. Last year, I implemented some Ajax
support framework without anything like the complexity that's in the
xml-rpc support. I did end up defining a new request marker type to
facilitate component lookup, but I was able to do this in a very light-
- It's not well enough documented. While I think there's merit in
doing some things at the WSGI level, I remain pretty happy with the
publication interface for separatating generic publisher functions
from application policies. I which the use of this API was better
communicated and understood.
A less major complaint is some baggage from the past. There are a
number of request features that I never use and tend to forget about.
The biggest of these is the special form data unmarshalling and url
manipulation support. (I was amused to read in your introduction to
your pipeline proposal that people wanted to know the answer to the
question: "When does Zope respect the :method form variable?". :)
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -