Branch off Five 1.4. We're not releasing Five 1.4b yet, but we need a Five
branch that is geared towards Zope trunk (=Zope 2.10).
Rocky should merge his work only to the Five 1.4 branch. Five 1.4 is geared
towards Zope 2.9.

Add a file argument to the five:loadProducts and five:loadProductOverrides
directives. Use this in the Five site.zcml to load all the Product meta before
any Product configure.
NOTE: Anyone who copied the Five site.zcml to their ${instance}/etc/ directory
is going to need to update it.

Added many five:deprecatedManageAddDelete for all Zope 2 classes that
have a manage_afterAdd & co method.
Simplified the transition, there are no more "phases", no more
transitional mode, it's either <five:containerEvents/> or not.
In event mode, even if a class doesn't have a five:deprecatedManageAddDelete,
we still try to call the manage_afterAdd & co methods.

Merged 18937:18978 from efge-object-event branch:
The standard Zope 2 containers can now send events.
<five:sendEvents class=.../> is removed, and replaced by
<five:containerEvents/> and <five:deprecatedManageAddDelete class=.../>
manage_afterAdd, manage_beforeDelete and manage_afterClone are deprecated.
tests/event.txt gives more details about the exact events sent.
This includes a "transitional" phase, which will only be used
during development but will be removed when things have been suitably
tested with Zope and CMF, and deprecated classes have been converted or
identified.
In the transitional phase (<five:containerEvents transitional="true"/>),
you use <five:containerEventAware class=.../> to specify which classes
are "modern" with respect to events, instead of specifying which ones
are "old" using five:deprecatedManageAddDelete like described above.

Merged the philikon-restructuring branch.
Three subpackages were introduced:
- Five.browser: contains all browser-related code, such as browser
page configuration, our special Page Template implementation, etc.
Five.browser.tests also contains the extensive test suite for all
browser-related things.
- Five.form: contains mostly configuration code for the form machinery
and its tests (Five.form.tests).
- Five.skin: contains the (now only beginnings) of Five's skinning
support and tests of primarily the StandardMacros view.
As the subpackages were introduced, the tests were split up accordingly.
They are now grouped by feature and can be run much more atomically. The
FiveTest product is no longer.
For more information, see
http://codespeak.net/pipermail/z3-five/2005q2/000434.html

Zope 3 style ``ISized`` adapters for objects are now exposed to the
ZMI and other Zope 2 frameworks via the known ``get_size`` method,
provided this is turned for the class in question via the
<five:sizable /> ZCML directive.

Initial support for add views.
What it adds:
* browser:view directive
* container/+/addfoo.html style add views, based on schema. That is, addform
and adding (+) support for ObjectManager.
Limitations:
* no tests yet (this will be corrected soon)
* if you want to do this for something else than ObjectManager subclasses,
may be complicated.
* browsing to +/ directly doesn't work properly yet.
* completely untested support for container constraint machinery

Enable 'subscriber' directive and add special five directive 'sendEvents'.
When applied to a Zope 2 class it plugs into its manage_afterAdd etc to
make send them send out Zope 3 events, which can then be subscribed to by code.
Todo:
* more extensive testing whether it works with things like Zope 2 folders etc
* ensuring that the event-sending behavior is as close to Zope 3's as
possible. A lot of edge cases with different behavior likely remain,
and things like IObjectModifiedEvents are not sent yet for folders.

five:viewable is now called five:defaultViewable, which more accurately
reflects what it is doing, which is making an object's public view be
handled by Five.
five:viewable directive was earlier renamed to five:traversable; five:viewable
now does the same thing as five:traversable but raises a deprecation warning,
so that users can update their ZCML.
Some other cleanups like breaking long lines and getting rid of commented out
code.

- five:viewable has changed to five:traversable
- __bobo_traverse__ now uses an ITraverser adapter
- five monkeypatched methods now have a __five_method__ attribute,
making it easier to not stomp on existing methods
- five:viewable now acts on __browser_default__. by default, it tries
to return the browser:defaultView configured for an object. This is
hookable by the use of a IBrowserDefault adapter
- registered absolute_url view and IAbsoluteURL adapter for *
- by default, OFS.SimpleItem.Item and OFS.ObjectManager.Manager are
five:traversable
- zope.app.traversing is registered by default, to make special
namespaces available (eg: @@, ++resource++)
- we now have resources (FileResource, ImageResource,
PageTemplateResource) and directory resources.
- backported the 'StandardMacros' thing from zope 3
- browser:page now correctly handles the allow_attributes and protects
the named attributes on the view with the same permission used for
the view (this sounds a bit strange, doesn't it?)
- ViewPageTemplateFile 'modules' uses zope2 SecureModuleImporter now
(eg: browser:page)
- zopeconf.py will try to find etc/zope.conf on INSTANCE_HOME

Implemented the <five:loadProductsOverrides /> directive which searches
Zope2 Products whether they provide an 'overrides.zcml' file. This
is then included using includeOverrides, such that the directive override
other ones.
Changes the <five:loadProducts /> directive to call the handler for
<zope:include /> instead of xmlconfig.file; this is symmetric to
loadProductsOverrides now.

Since it's ok now to depend on specific zope.app packages and we
already were depending on zope.app.component for the directive schemas,
we can just as well use the directive handlers from there, too (except
for the content directive handler). We were using mostly verbatim
copies, anyway.

Moved directives for the <browser:*> namespace to browserconfigure.py
Handlers are now spread over the three modules as follows:
* metaconfigure.py: handlers for <zope:*> directives
* browserconfigure.py: handlers for <browser:*> directives
* fiveconfigure.py: handlers for Five-specific directives (<five:*>)

Start to move schemas in zope.app instead of redefining them ourselves.
Use the same ZCML namespaces as zope 3 as much as possible. This means
that instead of five:page, you need browser:page; the 'five' namespace
is now reserved for directives that unique to Five.

Add deny directive. Add one test to make sure declarations are equivalent. Tried to make security stick on auto-generated metaclasses, but its not as easy as it seems. The code in question is marked with XXX.