[Checkins] SVN: zam.api/trunk/src/zam/api/README.txt cleaned up some of the text.

[Roy Mathew]

Log message for revision 103390:
  cleaned up some of the text.
  

Changed:
  U   zam.api/trunk/src/zam/api/README.txt

-=-
Modified: zam.api/trunk/src/zam/api/README.txt
===================================================================
--- zam.api/trunk/src/zam/api/README.txt	2009-08-29 16:28:49 UTC (rev 103389)
+++ zam.api/trunk/src/zam/api/README.txt	2009-08-30 03:50:18 UTC (rev 103390)
@@ -7,9 +7,9 @@
 new software. This allows us to keep the base system compact, and separate
 optional features into clearly separated packages.
 
-There are two different type of plugins offered. A simple plugin can do what it
-needs to do during the install and unistall process. The other base registry
-supported plugin will install a custom component registry.
+There are two different type of plugins offered. Simple plugin do what they
+needs to do during the install and uninstall process. Base registry
+supported plugins will install a custom component registry.
 
 The fundamental concept of the package is that a plugin can be installed for a
 particular site. At any time, you can ask the plugin, whether it has been
@@ -39,7 +39,7 @@
   ...             delattr(site, 'sample')
 
 The title and description of the plugin serve as pieces of information for the
-user and are commonly used in the UI.
+user, and are commonly used in the UI.
 
 So let's use the sample plugin:
 
@@ -49,7 +49,7 @@
 
   >>> sample = SamplePlugin()
 
-At the beginning the plugin is not installed, so we that first:
+At the beginning the plugin is not installed, so let's take care of that.
 
   >>> sample.isInstalled(site)
   False
@@ -61,7 +61,7 @@
   >>> sample.isInstalled(site)
   True
 
-However, once the plugin is isntalled, it cannot be installed again:
+However, once the plugin is installed, it cannot be installed again:
 
   >>> site.sample = 2
 
@@ -98,7 +98,7 @@
   >>> sampleRegistry = baseregistry.BaseComponents(
   ...     zope.component.globalSiteManager, 'sampleRegistry')
 
-Now we can create the plugin, either through instantiation or subsclassing:
+Now we can create the plugin, either through instantiation or sub-classing:
 
   >>> class SampleRegistryPlugin(plugin.BaseRegistryPlugin):
   ...     title = u'Sample Registry'
@@ -123,7 +123,7 @@
   >>> regPlugin.isInstalled(site)
   True
 
-As before installing the plugin again does nothing:
+As before, installing the plugin again does nothing:
 
   >>> len(sm.__bases__)
   2
@@ -158,8 +158,8 @@
 ------
 
 We offer a fine grained layer concept which allows you to use the ZAM skin
-out of the box or you can define your own skins offering what you need.
-Each ZAM plugin should configure it's component for the IZAMBrwoserLayer and
+out of the box, or lets you define your own skins, offering what you need.
+Each ZAM plugin should configure it's component for the IZAMBrowserLayer and
 not for the IZAMCoreLayer. This allows others to use the IZAMCoreLayer without
 any plugin configuration. See the different layer descriptions below for more
 information about the ZAM layer concept.
@@ -168,13 +168,13 @@
 Big note
 ~~~~~~~~
 
-This is only important if you'd like to define a own skin which uses
+This is only important if you'd like to define your own skin which uses
 selective zam plugins.
 
-The layer concept has some limitations if it comes to the adapter lookup. It's
+The layer concept has some limitations when it comes to adapter lookups. It's
 not possible to define a custom layer and make an existing layer act like it
-whould inherit this layer. Implements and provide concept only work on classes
-but not on interfaces. Let's be correct, they work but doesn't affect the
+whould inherit this layer. ``Implements`` and ``provide`` concept only work on
+classes but not on interfaces. Let's be more precise: they work but don't affect the
 request. Which means the request doesn't know about such applied layers. This
 means there is no[*] way to apply a later defined layer to an existing layer.
 This is the reason why we offer all plugin layers in the zam.api.layer package.
@@ -183,10 +183,10 @@
 You can skip the named skin configuration and configure your custom skin.
 
 [*] Ok, there is a way to apply layers to an existing layer or at least it will
-do the same effect. There are two ways, you can add a SkinChangedEvent which
-will do an alsoProvide and inject your layer or you can use a before traversal
-event subscriber which does the same. I decided not to use these patterns here
-as default because such subscriber will affect every skin and will cost
+be effectively the same thing. There are two ways: you can add a SkinChangedEvent which
+will do an alsoProvide and inject your layer, or you can use a 'before traversal
+event' subscriber which does the same. I decided not to use these patterns here
+as defaults, because such subscribers will affect every skin and will cost
 processing time on every request. The option we have with defining an explicit
 configuration for a custom skin is to small to pay that price.
 
@@ -197,27 +197,26 @@
 The core layer provides the ZAM core management views but no plugins and
 skin configuration. This allows us to write skins with a selective choice
 of plugins. Of course each plugin must be configured again for your
-custom skin. There is no way to offer out of the box a working set without
-to configure a plugin twice using two different layers.
+custom skin. Out of the box, there is no way to offer a working set without
+configuring a plugin twice using two different layers.
 
 
 IZAMPluginLayer
 ~~~~~~~~~~~~~~~
 
 The zam plugin layer should not be used in plugins. You need to define a
-plugin layer for your plugin in zam.api.layer and use this new defined layer.
-This layer will then become a part of the IZAMPluginLayer. This makes it
+plugin layer for your plugin in zam.api.layer and use this newly defined layer.
+This layer then becomes a part of the IZAMPluginLayer. This makes it
 possible to use the IZAMPluginLayer and get all it's configuration.
 
 But what happens if you don't develop in the zamplugin.* namespace? Then you
 only have the option to configure your plugins for an additional layer and use
 another skin which uses the IZAMPluginLayer and your custom layer. Using the
 IAZMPluginLayer for your configuration and sharing such packages ends in
-bad configuration and others needs to exlude your configuration and if this
+bad configuration and others needs to exclude your configuration if it
 is not needed in every skin they provide and is based on IZAMPluginLayer.
 Of course you can do this in your own private projects, but please do not
-use it for public shared packages and help us to provide a clean
-IZAMPluginLayer.
+use it for public shared packages. Help us provide a clean IZAMPluginLayer!
 
 Any improvement which offers us a better layer usage concept is very welcome if
 it doesn't need to configure additional subscribers.