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 dependencies. - 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- weight way. - 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?". :) Jim -- Jim Fulton Zope Corporation _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
