Roger Ineichen wrote:
>> Betreff: Re: [Zope-dev] [Checkins] SVN: zope.publisher/trunk/ 
>> Added some BBB code to setDefaultSkin

>> I don't mind if the skinnable story gets less intermingled 
>> with the request story in a new zope.skinnable package and 
>> breaks some backwards compatibility at that point. Right now 
>> that mix of the two concepts is so prevalent in all kinds of 
>> places, that I'd rather stay on the backwards compatible side.
> Can you tell me what was not backward compatible?

The setup of the default skin layer now required to load some ZCML from
the zope.publisher package. So far Zope2 didn't load any of that ZCML
and lots of test cases all over Zope2 (for example OFS, ZPublisher and
parts of Five) don't use any kind of ZCML aware layers. Crafting a
request via a simple dictionary and using it in rather straight unit
tests is extremely common in Zope2 and things like CMF and Plone. People
do combine that with the helper functions in to get
browser components of some kind set up easily.

This is a typical "grown" story that isn't particular well defined and
shouldn't block well devised future refactorings of the skinnable
concept. I'd just rather not break tons of tests now, with half a
refactoring in zope.publisher.

If we get a real refactoring of the skinnable concept into its own
package and can simplify the CA-overuse in it (things like interface
classes used as adapters which implement interfaces themselves make my
head hurt), I think it time to break backwards compatibility. I'd rather
see methods like setDefaultSkin, which doesn't happen to set a default
skin anymore be renamed to configureSkin or something else for example
and let the setDefaultSkin method still do what it names suggests.

> Sorry if I'm bother you about this details but I spent
> a full day with this refactoring and one of my apps depends
> on this deault browser layer less concept. You just reverted
> the hole refactoring with 3 lines of code.

I didn't revert the major part of the refactoring, which was about
disentangling the two concepts and making it possible to use skins for
other types of requests.

I still don't understand why you don't override the default adapter that
uses getDefaultSkin as a factory with one that returns a
IDontWantTheDefault skin. You have to use an override instead of the
exclude pattern, but given that nobody else seems to have had that
particular use-case of yours so far, I tend to believe it's an uncommon
edge-case scenario and the override pattern makes perfect sense to use
for this.


Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to