On Mar 16, 2009, at 7:20 PM, Martin Aspeli wrote:
Hi David,
I've just been reviewing the collective.flowplayer code as part of
the process for approving it for use on our Plone sites. It looks
great, with one exception: we host many Plone sites in one Zope
instance, and want to selectively install collective.flowplayer to
only some of those sites. Based on inspection of the code, it
looks like there are two ways in which collective.flowplayer will
pollute the other sites:
1. It registers various browser views without specifying a browser
layer.
I don't generally have a problem with this, if nothing is linking to
those views without the product installed. I think that's pretty
common practice.
It's obviously a different story for viewlets.
I'm generally against having all views in the same namespace; you can
end up with collisions if you forget to think about it. However, in
the case of collective.flowplayer they have reasonable names and I
have opted not to introduce the plone.browserlayer dependency, in
hopes of keeping compatibility with Plone 3.0 a little longer.
2. It subtypes objects in response to object events without
checking to make sure that the object is within a site that has
collective.flowplayer installed.
That would be a good thing to fix, definitely.
I just checked in a fix so that the event handlers check for a marker
utility in the local site manager (instead of a marker interface,
since local utilities gets removed for us by the quick installer for
free).
David Glick
Web Developer
ONE/Northwest
New tools and strategies for engaging people in protecting the
environment
http://www.onenw.org
[email protected]
work: (206) 286-1235 x32
mobile: (206) 679-3833
Subscribe to ONEList, our email newsletter!
Practical advice for effective online engagement
http://www.onenw.org/full_signup
_______________________________________________
Product-Developers mailing list
[email protected]
http://lists.plone.org/mailman/listinfo/product-developers
