[Zope3-dev] Re: skin support for xmlrpc
Philipp von Weitershausen
philipp at weitershausen.de
Mon Aug 27 17:32:10 EDT 2007
Christian Theune wrote:
> Am Freitag, den 24.08.2007, 07:55 +0200 schrieb Jodok Batlogg:
>> hi christian,
>> it seems like your recent changes to support skins in xmlrpc views
>> introduced some troubles.
>> we spent several hours to debug not working xmlrpc views and finally
>> found that nailing the zope.traversing egg to 3.4.x resolved the
>> while looking at your changes we were wondering why you want to
>> support skins in xmlrpc views? for me, a xmlrpc call is a remote
>> procedure call and has to do nothing with skins. it's not yellow,
>> pink or orange and has no templates associated. can you explain your
>> use-case for this?
> Let me try to wrap some of the things up here.
> When we drafted this change, we followed the idea of the refactoring for
> skins as they are now (switching from a separate skin/layer
> implementation to the current marker interfaces on requests) which was
> very technically focused. So were we.
> I see that we're misusing the ++skin++ traversal namespace and should
> introduce another namespace instead. Our mistake.
> We introduced the change as we thought it to be straightforward and a
> logical extension. As stated above we overlooked the simple solution of
> another traverser. We did not anticipate it to be such a strong problem
> otherwise we'd created a separate proposal instead of just going
> Zagy posted a reply to your question for a use case on that thread in
> the checkins list  but unfortunately that thread died off with this
> message and nobody returned to it.
> Let me propose a change:
> 1. We revert the change.
> 2. We create a new traverser with a different namespace that implements
> our intended behaviour.
> Two options after that:
> 3a. We supply this traverser by default, or
> 3b. We ship it in a separate package.
> I do have the feeling that differentiating
> the XML/RPC-API based on specifics of the request are of value (it
> certainly is for us) as are skins.
> If we can decide to ship a new traversal namespace for zope.publisher
> then we'd be happy to do that. Otherwise we'll just go on with a
> separate package. Hooray for the CA.
+1 to everything
+1 to a separate package, as suggested by myself earlier
http://worldcookery.com -- Professional Zope documentation and training
More information about the Zope3-dev