On Thu, 26 Jan 2006 10:25:09 -0500 Jim Washington wrote:
> I have been watching with some interest the thread about zcml
> simplification (ZCML bad et.al.), and of course I looked at Philipp's list
> of things that could be dead chickens in ZCML. I agree with most, and
> even with the <xmlrpc:view> directive.
> My question starts with the fact that for the jsonserver package, I copied
> the <xmlrpc:view> pattern for JSON-RPC. Should xmlrpc views be
> browser:views, and more specifically for me, should jsonrpc views be
> browser:views? Do we really need other types of views than browser:views?
> Anyway, I am considering removing the jsonrpc:view directive from my
> third-party project (to be replaced by the already available
> browser:view), and am wondering if there is a risk I have not considered.
> The main risk I see is angry customers, but I think I can calm them by
> explaining the added simplicity it brings.
In my opinion, the advantage of the jsonrpc:view directive is control
above what should and what should not be seen on the URL namespace. Since
one of the strongnesses is Z3/Five vs. plain Z2 is this, I am happy to
have the directive and be able to do it.
So this is where I see the importance of this: allow access to a
method/template via RPC only, and disallow the method to be called
directly from the browser. The other way around, (allow normal requests
but disallow RPC) does not seem to make sense. The third use case: allow
access from both normal requests and RPC, is already implemented by the
The risk of not having this directive would be only that anything that is
designated to be an RPC-only method can also be called up from the browser
by a playful user. As far as for the jsonserver for Z2/Five and Z3
packages are concerned, I would leave this attribute in until more usage
experience is gathered.
Zope3-dev mailing list