def index(self, **responseMap):
is the "normal" index signature. If there are no parameters, then
responsemap will be an empty dict. I think it is a mistake to present
code that is brittle and will fail when the actual request differs from
the expected request.
Similarly the default signature is really
def default(self, *urlpath, **responseMap):
I realize the current examples may look less threatening by only
presenting the expected arguments, but I think it does a disservice to
gloss over issues that should not be ignored.
I am willing to work through the documentation and make corrections so
that the examples are more robust, but do not want to waste my time if
that is not wanted.
This is example #7 from my 2.0 installation.
def default(self, user):
# Here we react depending on the virtualPath -- the part of the
# path that could not be mapped to an object method. In a real
# application, we would probably do some database lookups here
# instead of the silly if/elif/else construct.
if user == 'remi':
out = "Remi Delon, CherryPy lead developer"
elif user == 'hendrik':
out = "Hendrik Mans, CherryPy co-developer & crazy German"
<snipped>
I'd rather see:
def default(self, user, *discard, **ignore):
and explain why discard and ignore should be included. It might even be
worth pointing out that no default value is needed for user because if
there were no path value for user, the index method will be called
rather than default.
Is the example code really the preferred way to write a CherryPy
application?
IMO that is exactly what you want to have happen--failure. Errors should not pass silently.
> Similarly the default signature is really
> def default(self, *urlpath, **responseMap):
>
> Is the example code really the preferred way to write
> a CherryPy application?
IMO, yes. In almost all of the cases where I've experienced errors due to extraneous arguments, it's been during my own development and testing. I can honestly say that I haven't had a single occurrence of extraneous-arg errors in production unless it pointed out a bug that needed fixing in my own app code. YMMV--maybe you're writing mashup apps that demand fuzzier interfaces.
Any other anecdotal opinions out there?
Robert Brewer
System Architect
Amor Ministries
fuma...@amor.org