Am Mon, 2002-08-05 um 21.21 schrieb Greg Ward:
> On 05 August 2002, Holger Duerer said:
> > As I understood Andreas's comment, he was wondering why the request
> > arguments weren't passed straight into the function as parameters
> > (i.e. matching function parameter names with request field names).
> > There would be no need to parse the arguments into types other than
> > strings, i.e. that is a concept unrelated to this.
>
> Over my dead body.
Well, I wouldn't want to be a murderer ;)
>
> Remember that one of the core principles of Quixote is NO MAGIC.
> This is a direct response to Zope's stupendous complexity.
Well, it always take some definition of magic. If you take the uninited
CGI perl coder, than the namespace traversal already looks like magic.

The problem with ZPublisher (IMHO) are:
- many features, which are only useful to Zope.
  (Like the authentication stuff)
- to many hacks around to work the pre-Python 1.3 way.
  For example many hooks to deal with "DocumentTemplate" methods,
  because Python in it's early days did not know about
  new.instancemethod.
- Some times useful, but more often the source of confusion: Multiple
  ways to do the samething: getattr,getitem,__before_traverse__,
  __bobo_traverse__, ...

So basically ZPublisher's problem is combination of useful and unneeded
magic which is intermixed in an archaic way and which exhibits an
archaic API. (which is set in stone, because of many commercial
applications).

Line count: My (at the moment) naive implementation takes:
andreas@vaio2:~/work/fax> wc -l reqpublish.py
    106 reqpublish.py
Only 52 lines are my naive implementation, while the rest includes
the boilerplate try_publish method, etc.
It would get some additional lines for :float and other modifiers, at
the moment it only understands :int.

This is about one eighth of the Zope implementation you yanked out.

Performance:
My tests with a much more complete (and unneeded, because the builtin
apply can do half the work :) ) implementation indicate, that it's about
one magnitude slower than a direct function call. BUT it is still far
below 0.1ms (on my 700MHz Duron), so it should have minimalistic impact
upon realworld webperformance.

Compability:
My Publisher seems to work with my small WebFax application, but that
doesn't have to say much. It would break for application that name the
request object something else than "request" :(
[One could probably fix this with some heuristics, but that would get us
 into the Zope backwards compability nightmare]

Conclusion:
3 possible ways to proceed:
a) ignore the thread.
b) include some hooks to make modifying the behaviour easier:
   instead of
       output=object(request)
   make it something like this:
       output=self.callrequest(object,request)
   with
   def callrequest(self,object,request):
       return object(request)

   This would make it easier to fix the behaviour.
c) include some patch to make the argument processing behaviour the
   normal behaviour. If so, I volunteer to clean up my try_publish
   method :)

Andreas