[Zope3-checkins] CVS: Zope3/src/zope/proxy/context - decorators.txt:1.1.2.7

[Steve Alexander]

Update of /cvs-repository/Zope3/src/zope/proxy/context
In directory cvs.zope.org:/tmp/cvs-serv28339/src/zope/proxy/context

Modified Files:
      Tag: stevea-decorators-branch
	decorators.txt 
Log Message:
Added a few comments and corrections from Marius.


=== Zope3/src/zope/proxy/context/decorators.txt 1.1.2.6 => 1.1.2.7 ===
--- Zope3/src/zope/proxy/context/decorators.txt:1.1.2.6	Mon May 19 04:21:00 2003
+++ Zope3/src/zope/proxy/context/decorators.txt	Mon May 19 07:20:25 2003
@@ -81,10 +81,16 @@
   +--------+ +-<>| ContextDecoratedFolder |<>-+  +------------------------+
                  +------------------------+
 
-[Folder realizes IFolder. ZopeContainerDecorator realizes IZopeContainer.
- The notional class ContextDecoratedFolder, made up at runtime by the
- decorator composite object, realizes both IFolder and IZopeContainer]
+Folder realizes IFolder. ZopeContainerDecorator realizes IZopeContainer.
+The notional class ContextDecoratedFolder, made up at runtime by the
+decorator composite object, realizes both IFolder and IZopeContainer.
+
+(Marius writes:
+  XXX I'm still in two minds about decorator mixins claiming that they
+      implement IFoo when they really implement only a part of it.  It is
+      really the notional composite class that implements it fully.)
 
+ 
 
 [Insert decorator object diagram.]
 
@@ -169,7 +175,7 @@
    wrong to apply extra context-aware behaviour. So, decoration is made
    dependent on implementation class, not on interface.
 
-Q: Why is the context decorator to use "inherited" by subclasses?
+Q: Why is which the context decorator to use not "inherited" by subclasses?
    For example, if I register a decorator for use with SampleContainer,
    and considering that Folder derives from SampleContainer, why do I need
    explicitly to register the same decorator for Folder?
@@ -252,6 +258,8 @@
 This allows us to use interfaces to define permissions, even if we're only
 using some of the names from the interfaces in the mixin.
 This also allows us to use the '<require like_class="..."' directive.
+Any permissions declared in the 'decorator' directive that do not appear in
+'names' are ignored.
 
 Note that __providedBy__ and __Security_checker__ are reserved names, and
 cannot be used.