Skip to content

Z
Zope
Commit 746f8be0 authored by Hanno Schlichting's avatar Hanno Schlichting
Browse files
Options

Updated documentation to new version number.

parent aa808867
Hide whitespace changes
Inline Side-by-side
Showing with 16 additions and 820 deletions
doc/CHANGES.rst
View file @ 746f8be0
......@@ -2,8 +2,8 @@ Changelog
=========
This file contains change information for the current Zope release.
Change information for previous versions of Zope can be found in the
file HISTORY.txt.
Change information for previous versions of Zope can be found at
http://docs.zope.org/zope2/releases/.
Trunk (unreleased)
------------------
......@@ -11,460 +11,12 @@ Trunk (unreleased)
Restructuring
+++++++++++++
- Removed all use of ``zope.app.pagetemplate`` by cloning / simplifying
client code.
- Use ``zope.pagetemplate.engine`` instead of ``zope.app.pagetemplate.engine``.
(update to versions 3.5.0 and 3.7.0, respectively, along with version 3.8.1
of ``zope.app.publisher``).
- Use ``IBrowserView`` interface from ``zope.browser.interfaces``, rather than
``zope.publisher.interfaces.browser``.
- Use ``IAdding`` interface from ``zope.browser.interfaces``, rather than
``zope.app.container``.
- No longer depend on ``zope.app.appsetup``; use the event implementations
from ``zope.processlifetime`` instead.
* Updated documentation to new version number.
Features Added
++++++++++++++
- zExceptions.convertExceptionType: new API, breaking out conversion of
exception names to exception types from 'upgradeException'.
- Launchpad #374719: introducing new ZPublisher events:
PubStart, PubSuccess, PubFailure, PubAfterTraversal and PubBeforeCommit.
- Testing.ZopeTestCase: Include a copy of ZODB.tests.warnhook to silence
a DeprecationWarning under Python 2.6.
- Updated packages:
* python-gettext 1.0
* pytz 2009g
* zope.app.applicationcontrol = 3.5.0
* zope.app.appsetup 3.11
* zope.app.component 3.8.2
* zope.app.container 3.8.0
* zope.app.form 3.8.0
* zope.app.http 3.6.0
* zope.app.interface 3.5.0
* zope.app.pagetemplate 3.6.0
* zope.app.publication 3.7.0
* zope.app.publisher 3.8.0
* zope.browser 1.2
* zope.component 3.7.0
* zope.componentvocabulary 1.0
* zope.container 3.8.2
* zope.formlib 3.6.0
* zope.lifecycleevent 3.5.2
* zope.location 3.5.4
* zope.processlifetime 1.0
* zope.publisher 3.8.0
* zope.security 3.7.0
* zope.testing 3.7.4
* zope.traversing 3.7.0
Bugs Fixed
++++++++++
- Launchpad #374729: Encoding cookie values to avoid issues with
firewalls and security proxies.
- Launchpad #373583: ZODBMountPoint - fixed broken mount support and
extended the test suite.
- Launchpad #373621: catching and logging exceptions that could cause
leaking of worker threads.
- Launchpad #373577: setting up standard logging earlier within the startup
phase for improving the analysis of startup errors.
- Launchpad #373601: abort transaction before connection close in order to
prevent connection leaks in case of persistent changes after the main
transaction is closed.
- Fix BBB regression which prevented setting browser ID cookies from
browser ID managers created before the ``HTTPOnly`` feature landed.
https://bugs.launchpad.net/bugs/374816
- RESPONSE.handle_errors was wrongly set (to debug, should have been
``not debug``). Also, the check for exception constructor arguments
didn't account for exceptions that didn't override the ``__init__``
(which are most of them). The combination of those two problems
caused the ``standard_error_message`` not to be called. Fixes
https://bugs.launchpad.net/zope2/+bug/372632 .
- DocumentTemplate.DT_Raise: use new 'zExceptions.convertExceptionType'
API to allow raising non-builtin exceptions.
Fixes https://bugs.launchpad.net/zope2/+bug/372629 , which prevented
viewing the "Try" tab of a script with no parameters.
Zope 2.12.0b1 (2009/05/06)
--------------------------
Restructuring
+++++++++++++
- No longer depend on ``zope.app.locales``. Zope2 uses almost none of the
translations provided in the package and is not required for most projects.
The decision to include locales is left to the application developer now.
- Removed the dependency on ``zope.app.testing`` in favor of providing a more
minimal placeless setup as part of ZopeTestCase for our own tests.
- updated to ZODB 3.9.0b1
Features Added
++++++++++++++
- zExceptions.convertExceptionType: new API, breaking out conversion of
exception names to exception types from ``upgradeException``.
- Extended BrowserIdManager to expose the ``HTTPOnly`` attribute for its
cookie. Also via https://bugs.launchpad.net/zope2/+bug/367393 .
- Added support for an optional ``HTTPOnly`` attribute of cookies (see
http://www.owasp.org/index.php/HTTPOnly). Patch from Stephan Hofmockel,
via https://bugs.launchpad.net/zope2/+bug/367393 .
Bugs Fixed
++++++++++
- ZPublisher response.setBody: don't append Accept-Encoding to Vary header if
it is already present - this can make cache configuration difficult.
2.12.0a4 (2009-04-24)
---------------------
Bugs Fixed
++++++++++
- fixed versions.cfg in order to support zope.z2release for
creating a proper index structure
2.12.0a3 (2009-04-19)
---------------------
The generated tarball for the 2.12.0a2 source release was incomplete, due to
a setuptools and Subversion 1.6 incompatibility.
Restructuring
+++++++++++++
- Added automatic inline migration for databases created with older Zope
versions. The ``Versions`` screen from the ``Control_Panel`` is now
automatically removed on Zope startup.
- Removed more unused code of the versions support feature including the
Globals.VersionNameName constant.
2.12.0a2 (2009-04-19)
---------------------
Restructuring
+++++++++++++
- If the <permission /> ZCML directive is used to declare a permission that
does not exist, the permission will now be created automatically, defaulting
to being granted to the Manager role only. This means it is possible to
create new permissions using ZCML only. The permission will Permissions that
already exist will not be changed.
- Using <require set_schema="..." /> or <require set_attributes="..." /> in
the <class /> directive now emits a warning rather than an error. The
concept of protecting attribute 'set' does not exist in Zope 2, but it
should be possible to re-use packages that do declare such protection.
- Updated to Acquisition 2.12.1.
- Updated to DateTime 2.12.0.
- Updated to ZODB 3.9.0a12.
- Removed the ``getPackages`` wrapper from setup.py which would force all
versions to an exact requirement. This made it impossible to require
newer versions of the dependencies. This kind of KGS information needs
to be expressed in a different way.
- removed ``extras_require`` section from setup.py (this might possibly
break legacy code).
Bugs Fixed
++++++++++
- Launchpad #348223: optimize catalog query by breaking out early from loop
over indexes if the result set is already empty.
- Launchpad #344098: in ``skel/etc/zope.conf.ing``, replaced commented-out
``read-only-database`` option, which is deprecated, with pointers to the
appropos sections of ZODB's ``component.xml``. Updated the description
of the ``zserver-read-only-mode`` directive to indicate its correct
semantics (suppressing log / pid / lock files). Added deprecation to the
``read-only-database`` option, which has had no effect since Zope 2.6.
- "Permission tab": correct wrong form parameter for
the user-permission report
- PageTemplates: Made PreferredCharsetResolver work with new kinds of contexts
that are not acquisition wrapped.
- Object managers should evaluate to True in a boolean test.
2.12.0a1 (2009-02-26)
---------------------
Restructuring
+++++++++++++
- Switched Products.PageTemplates to directly use zope.i18n.translate and
removed the GlobalTranslationService hook.
- Removed bridging code from Product.Five for PlacelessTranslationService
and Localizer. Neither of the two is actually using this anymore.
- Removed the specification of ``SOFTWARE_HOME`` and ``ZOPE_HOME`` from the
standard instance scripts.
[hannosch]
- Made the specification of ``SOFTWARE_HOME`` and ``ZOPE_HOME`` optional. In
addition ``INSTANCE_HOME`` is no longer required to run the tests of a
source checkout of Zope.
- Removed the ``test`` command from zopectl. The test.py script it was relying
on does no longer exist.
- Updated to ZODB 3.9.0a11. ZODB-level version support has been
removed and ZopeUndo now is part of Zope2.
- The Zope2 SVN trunk is now a buildout pulling in all dependencies as
actual released packages and not SVN externals anymore.
- Make use of the new zope.container and zope.site packages.
- Updated to newer versions of zope packages. Removed long deprecated
layer and skin ZCML directives.
- Disabled the XML export on the UI level - the export functionality
however is still available on the Python level.
- No longer show the Help! links in the ZMI, if there is no help
available. The help system depends on the product registry.
- Updated the quick start page and simplified the standard content.
The default index_html is now a page template.
- Removed deprecated Draft and Version support from Products.OFSP.
Also removed version handling from the control panel. Versions are
no longer supported on the ZODB level.
- Removed left-overs of the deprecated persistent product distribution
mechanism.
- The persistent product registry is not required for starting Zope
anymore. ``enable-product-installation`` can be set to off if you don't
rely on the functionality provided by the registry.
- ZClasses have been deprecated for two major releases. They have been
removed in this version of Zope.
- Avoid deprecation warnings for the md5 and sha modules in Python 2.6
by adding conditional imports for the hashlib module.
- Replaced imports from the 'Globals' module throughout the
tree with imports from the actual modules; the 'Globals' module
was always intended to be an area for shared data, rather than
a "facade" for imports. Added zope.deferred.deprecation entries
to 'Globals' for all symbols / modules previously imported directly.
- Protect against non-existing zope.conf path and products directories.
This makes it possible to run a Zope instance without a Products or
lib/python directory.
- Moved exception MountedStorageError from ZODB.POSExceptions
to Products.TemporaryFolder.mount (now its only client).
- Moved Zope2-specific module, ZODB/Mount.py, to
Products/TemporaryFolder/mount.py (its only client is
Products/TemporaryFolder/TemporaryFolder.py).
- Removed spurious import-time dependencies from
Products/ZODBMountPoint/MountedObject.py.
- Removed Examples.zexp from the skeleton. The TTW shopping cart isn't
any good example of Zope usage anymore.
- Removed deprecated ZTUtil.Iterator module
- Removed deprecated StructuredText module
- Removed deprecated TAL module
- Removed deprecated modules from Products.PageTemplates.
- Removed deprecated ZCML directives from Five including the whole
Five.site subpackage.
Features added
++++++++++++++
- OFS.ObjectManager now fully implements the zope.container.IContainer
interface. For the last Zope2 releases it already claimed to implement the
interface, but didn't actually full-fill the interface contract. This means
you can start using more commonly used Python idioms to access objects
inside object managers. Complete dictionary-like access and container
methods including iteration are now supported. For each class derived from
ObjectManager you can use for any instance om: ``om.keys()`` instead of
``om.objectIds()``, ``om.values()`` instead of ``om.objectValues()``, but
also ``om.items()``, ``ob.get('id')``, ``ob['id']``, ``'id' in om``,
``iter(om)``, ``len(om)``, ``om['id'] = object()`` instead of
``om._setObject('id', object())`` and ``del ob['id']``. Should contained
items of the object manager have ids equal to any of the new method names,
the objects will override the method, as expected in Acquisition enabled
types. Adding new objects into object managers by those new names will no
longer work, though. The added methods call the already existing methods
internally, so if a derived type overwrote those, the new interface will
provide the same functionality.
- Acquisition has been made aware of ``__parent__`` pointers. This allows
direct access to many Zope 3 classes without the need to mixin
Acquisition base classes for the security to work.
- MailHost: now uses zope.sendmail for delivering the mail. With this
change MailHost integrates with the Zope transaction system (avoids
sending dupe emails in case of conflict errors). In addition
MailHost now provides support for asynchronous mail delivery. The
'Use queue' configuration option will create a mail queue on the
filesystem (under 'Queue directory') and start a queue thread that
checks the queue every three seconds. This decouples the sending of
mail from its delivery. In addition MailHosts now supports
encrypted connections through TLS/SSL.
- SiteErrorLog now includes the entry id in the information copied to
the event log. This allowes you to correlate a user error report with
the event log after a restart, or let's you find the REQUEST
information in the SiteErrorLog when looking at a traceback in the
event log.
Bugs Fixed
++++++++++
- Launchpad #332168: Connection.py: do not expose DB connection strings
through exceptions
- Specified height/width of icons in ZMI listings so the table doesn't
jump around while loading.
- After the proper introduction of parent-pointers, it's now
wrong to acquisition-wrap content providers. We will now use
the "classic" content provider expression from Zope 3.
- Ported c69896 to Five. This fix makes it possible to provide a
template using Python, and not have it being set to ``None`` by
the viewlet manager directive.
- Made Five.testbrowser compatible with mechanize 0.1.7b.
- Launchpad #280334: Fixed problem with 'timeout'
argument/attribute missing in testbrowser tests.
- Launchpad #267834: proper separation of HTTP header fields
using CRLF as requested by RFC 2616.
- Launchpad #257276: fix for possible denial-of-service attack
in PythonScript when passing an arbitrary module to the encode()
or decode() of strings.
- Launchpad #257269: 'raise SystemExit' with a PythonScript could shutdown
a complete Zope instance
- Switch to branch of 'zope.testbrowser' external which suppresses
over-the-wire tests.
- Launchpad #143902: Fixed App.ImageFile to use a stream iterator to
output the file. Avoid loading the file content when guessing the
mimetype and only load the first 1024 bytes of the file when it cannot
be guessed from the filename.
- Changed PageTemplateFile not to load the file contents on Zope startup
anymore but on first access instead. This brings them inline with the
zope.pagetemplate version and speeds up Zope startup.
- Collector #2278: form ':record' objects did not implement enough
of the mapping protocol.
- "version.txt" file was being written to the wrong place by the
Makefile, causing Zope to report "unreleased version" even for
released versions.
- Five.browser.metaconfigure.page didn't protect names from interface
superclasses (http://www.zope.org/Collectors/Zope/2333)
- DAV: litmus "notowner_modify" tests warn during a MOVE request
because we returned "412 Precondition Failed" instead of "423
Locked" when the resource attempting to be moved was itself
locked. Fixed by changing Resource.Resource.MOVE to raise the
correct error.
- DAV: litmus props tests 19: propvalnspace and 20:
propwformed were failing because Zope did not strip off the
xmlns: attribute attached to XML property values. We now strip
off all attributes that look like xmlns declarations.
- DAV: When a client attempted to unlock a resource with a token
that the resource hadn't been locked with, in the past we
returned a 204 response. This was incorrect. The "correct"
behavior is to do what mod_dav does, which is return a '400
Bad Request' error. This was caught by litmus
locks.notowner_lock test #10. See
http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JanMar/0099.html
for further rationale.
- When Zope properties were set via DAV in the "null" namespace
(xmlns="") a subsequent PROPFIND for the property would cause the
XML representation for that property to show a namespace of
xmlns="None". Fixed within OFS.PropertySheets.dav__propstat.
- integrated theuni's additional test from 2.11 (see r73132)
- Relaxed requirements for context of
Products.Five.browser.pagetemplatefile.ZopeTwoPageTemplateFile,
to reduce barriers for testing renderability of views which
use them.
(http://www.zope.org/Collectors/Zope/2327)
- PluginIndexes: Fixed 'parseIndexRequest' for false values.
- Collector #2263: 'field2ulines' did not convert empty string
correctly.
- Collector #2198: Zope 3.3 fix breaks Five 1.5 test_getNextUtility
- Prevent ZPublisher from insering incorrect <base/> tags into the
headers of plain html files served from Zope3 resource directories.
- Changed the condition checking for setting status of
HTTPResponse from to account for new-style classes.
- The Wrapper_compare function from tp_compare to tp_richcompare.
Also another function Wrapper_richcompare is added.
- The doc test has been slightly changed in ZPublisher to get
the error message extracted correctly.
- The changes made in Acquisition.c in Implicit Acquisition
comparison made avail to Explicit Acquisition comparison also.
- zopedoctest no longer breaks if the URL contains more than one
question mark. It broke even when the second question mark was
correctly quoted.
Other Changes
+++++++++++++
- Added lib/python/webdav/litmus-results.txt explaining current
test results from the litmus WebDAV torture test.
- DocumentTemplate.DT_Var.newline_to_br(): Simpler, faster
implementation.
doc/WHATSNEW.rst
View file @ 746f8be0
What's new in Zope 2.12
What's new in Zope 2.13
=======================
The article explains the new high-level features and changes found in this
......@@ -8,333 +8,7 @@ You can have a look at the `detailed change log <CHANGES.html>`_ to learn
about all minor new features and bugs being solved in this release.
Support for newer Python versions
---------------------------------
Zope 2 has supported and required Python 2.4 since its 2.9 release in summer
2006. Later versions of Python have so far been unsupported by Zope 2.
This version of Zope 2 adds support for both Python 2.5 and 2.6 at the same
time. As Python 2.4 is no longer maintained itself, it is no longer officially
supported by this Zope 2 version. There is however no code in Zope 2 yet which
requires Python 2.5, so applications built on top of Zope 2 should still
continue to run with Python 2.4.
Python 3 is a backwards incompatible release of Python and not supported. At
this point there is no concrete roadmap for adoption of Python 3. It is
expected to be a question of multiple major Zope 2 releases or years, though.
Fully eggified
--------------
Zope 2 itself is now fully eggified and compatible with `setuptools
<http://pypi.python.org/pypi/setuptools>`_. You can use popular tools like
`easy_install <http://peak.telecommunity.com/DevCenter/EasyInstall>`_ or
`zc.buildout <http://pypi.python.org/pypi/zc.buildout>`_ to install Zope 2.
Releases of Zope 2 can be found at and will be installable from the Python
package index at http://pypi.python.org/pypi/Zope2.
The repackaging of Zope 2 into an eggified form and accompanying changes to the
file system layout have caused a number of changes. The environment variables
`SOFTWARE_HOME` and `ZOPE_HOME` are no longer available nor set in the control
scripts. If you need to access data files inside the Zope 2 package, you can
for example use `import os, OFS; os.path.dirname(OFS.__file__)` to locate the
files inside the OFS package.
In general it is discouraged to rely on the `lib/python` and `Products`
directories to make code available to the running Zope process. While these
mechanisms continue to work, you are encouraged to use normal distutils or
setuptools managed packages and add these to your `sys.path` using any of the
standard Python mechanisms. To create isolated Python environments both
`zc.buildout <http://pypi.python.org/pypi/zc.buildout>`_ and `virtualenv
<http://pypi.python.org/pypi/virtualenv>`_ are in wide-spread use.
Zope Toolkit
------------
This version of Zope 2 is based on the Zope Toolkit. The Zope Toolkit is an
extraction of the reusable and wildly used packages of the former Zope 3
project. The Zope Toolkit is focused on supporting frameworks and applications,
rather than trying to be one itself. Parts of the Zope Toolkit are used by
Zope 2, Plone, Grok, Repoze.bfg, and by many other different applications and
frameworks.
A major focus of the Zope Toolkit was to refactor package dependencies to
generate more maintainable and better structured code. Based on this effort
the number of packages included by Zope 2 could be dramatically reduced from
about 120 additional packages to just over 60. The total code size of Zope 2
and its dependencies has decreased by over 200,000 lines of code as a result.
You can find more information about the changes in the Zope Toolkit at
http://docs.zope.org/zopetoolkit/. Upgrade information from Zope 3 to the Zope
Toolkit can be found at http://docs.zope.org/zopetoolkit/migration/index.html.
ZODB 3.9
--------
This version of Zope 2 includes the latest version of the `ZODB (3.9)
<http://pypi.python.org/pypi/ZODB3>`_. It has a multitude of new configuration
options and bug fixes. File storages have gotten native support for blob
storages and demo storages have been expanded extensively. There is a large
number of options to tune ZEO servers and clients in large scale environments
and control cache invalidation and packaging to a much wider degree.
You can read more about the detailed changes in the `ZODB3 change log
<http://pypi.python.org/pypi/ZODB3>`_ for version 3.9.
Module cleanup
--------------
As with every release of Zope 2 this version has removed various modules
which have been deprecated in prior versions.
Most notably ZClasses and supporting modules have been removed entirely from
Zope 2. As a result the persistent product registry has been made optional, but
is still enabled by default. If your application does not rely on the registry,
you can now disable it by specifying::
enable-product-installation off
inside your `zope.conf` file. With the option turned off Zope will no longer
write any new transactions to your database during startup in most cases.
With the upgrade to ZODB 3.9 database-level version support is no longer
available. Many of the modules in `Products.OFSP` have been removed as a
result. The low level API to load objects from the database has lost its
version argument as a result of this.
Documentation updates
---------------------
Zope 2 now uses `Sphinx <http://sphinx.pocoo.org/>`_ to create pleasant HTML
representations of its documentation. An effort is underway to update the
publicly available documentation using Sphinx at http://docs.zope.org/.
So far the Zope 2 Book, the Zope Developers Guide and many smaller articles
have been converted to reStructuredText and their content updated.
Acquisition redux
-----------------
The short technical version of this change is: "Acquisition has been made aware
of __parent__ pointers". What sounds like a small change is actually a major
step in the integration story for Zope components based technology into Zope 2.
While integrating the Zope component architecture and its many concepts into
Zope 2 an integration layer called Five (Zope 2 + 3) has been created. One of
the major reasons for the necessity of an integration layer has been in the way
Zope 2 was tightly coupled to the concept of Acquisition. The entire security
machinery, object traversal and publication has been relying on this.
All classes, which wanted to interact with Zope 2 in any non-trivial way, had
to inherit from the Acquisition base classes. As a result almost no external
package could directly work inside Zope 2 but required an integration layer.
With this version of Zope 2, objects have a new option of providing location
awareness to Zope APIs. This new option is to provide an explicit parent
pointer in the ``__parent__`` attribute, much like specified by the ILocation
API from `zope.location <http://pypi.python.org/pypi/zope.location>`_. Browser
views and other location-dependent components implement ILocation already.
Classes adhering to this convention need to get `__parent__` pointers set to
their container object, when being put into the container. Code that operates
on such objects can then walk up the containment hierarchy by following the
pointers. In Acquisition based classes no information would be stored on the
objects, but Acquisition wrappers are constructed around the objects instead.
Only those wrappers would hold the container references. The Acquisition
wrapping relies on the objects to provide an `__of__` method as done by the
Acquisition base classes.
The most common way of getting the container of an instance is to call::
from Acquisition import aq_parent
container = aq_parent(instance)
For instances providing the ILocation interface the common way is::
container = instance.__parent__
There are various `aq_*` methods available for various other tasks related to
locating objects in the containment hierarchy. So far virtually all objects in
Zope 2 would participate in Acquisition. As a side-effect many people relied on
Acquisition wrappers to be found around their objects. This caused code to rely
on accessing the `aq_*` methods as attributes of the wrapper::
container = instance.aq_parent
While all the existing API's still work as before, Acquisition now respects
`__parent__` pointers to find the container for an object. It will also not
unconditionally try to call the `__of__` method of objects anymore, but protect
it with a proper interface check::
from Acquisition.interfaces import IAcquirer
if IAcquirer.providedBy(instance):
instance = instance.__of__(container)
In addition to this check you should no longer rely on the `aq_*` methods to be
available as attributes. While all code inside Zope 2 itself still supports
this, it does no longer rely on those but makes proper use of the functions
provided by the Acquisition package.
To understand the interaction between the new and old approach here is a
little example::
>>> class Location(object):
... def __init__(self, name):
... self.__name__ = name
... def __repr__(self):
... return self.__name__
# Create an Acquisition variant of the class:
>>> import Acquisition
>>> class Implicit(Location, Acquisition.Implicit):
... pass
# Create two implicit instances:
>>> root = Implicit('root')
>>> folder = Implicit('folder')
# And two new Acquisition-free instances:
>>> container = Location('container')
>>> item = Location('item')
# Provide the containment hints:
>>> folder = folder.__of__(root)
>>> container.__parent__ = folder
>>> item.__parent__ = container
# Test the containtment chain:
>>> from Acquisition import aq_parent
>>> aq_parent(container)
folder
>>> from Acquisition import aq_chain
>>> aq_chain(item)
[item, container, folder, root]
# Explicit pointers take precedence over Acquisition wrappers:
>>> item2 = Implicit('item2')
>>> item2 = item2.__of__(folder)
>>> item2.__parent__ = container
>>> aq_chain(item2)
[item2, container, folder, root]
For a less abstract example, you so far had to do::
>>> from Acquisition import aq_inner
>>> from Acquisition import aq_parent
>>> from Products import Five
>>> class MyView(Five.browser.BrowserView):
...
... def do_something(self):
... container = aq_parent(aq_inner(self.context))
Instead you can now do::
>>> import zope.publisher.browser
>>> class MyView(zope.publisher.browser.BrowserView):
...
... def do_something(self):
... container = aq_parent(self.context)
As the zope.publisher BrowserView supports the ILocation interface, all of this
works automatically. A view considers its context as its parent as before, but
no longer needs Acquisition wrapping for the Acquisition machinery to
understand this. The next time you want to use a package or make your own code
more reusable outside of Zope 2, this should be of tremendous help.
Object managers and IContainer
------------------------------
One of the fundamental parts of Zope 2 is the object file system as implemented
in the `OFS` package. A central part of this package is an underlying class
called `ObjectManager`. It is a base class of the standard `Folder` used
for many container-ish classes inside Zope 2.
The API to access objects in an object manager or to add objects to one has
been written many years ago. Since those times Python itself has gotten
standard ways to access objects in containers and work with them. Those Python
API's are most familiar to most developers working with Zope. The Zope
components libraries have formalized those API's into the general IContainer
interface in the zope.container package. In this version of Zope 2 the standard
OFS ObjectManager fully implements this IContainer interface in addition to its
old API.
>>> from zope.container.interfaces import IContainer
>>> from OFS.ObjectManager import ObjectManager
>>> IContainer.implementedBy(ObjectManager)
True
You can now write your code in a way that no longer ties it to object managers
alone, but can support any class implementing IContainer instead. In
conjunction with the Acquisition changes above, this will increase your chances
of being able to reuse existing packages not specifically written for Zope 2 in
a major way.
Here's an example of how you did work with object managers before::
>>> from OFS.Folder import Folder
>>> from OFS.SimpleItem import SimpleItem
>>> folder = Folder('folder')
>>> item1 = SimpleItem('item1')
>>> item2 = SimpleItem('item2')
>>> result = folder._setObject('item1', item1)
>>> result = folder._setObject('item2', item2)
>>> folder.objectIds()
['item1', 'item2']
>>> folder.objectValues()
[<SimpleItem at folder/>, <SimpleItem at folder/>]
>>> if folder.hasObject('item2')
... folder._delObject('item2')
Instead of this special API, you can now use::
>>> from OFS.Folder import Folder
>>> from OFS.SimpleItem import SimpleItem
>>> folder = Folder('folder')
>>> item1 = SimpleItem('item1')
>>> item2 = SimpleItem('item2')
>>> folder['item1'] = item1
>>> folder['item2'] = item2
>>> folder.keys()
['item1', 'item2']
>>> folder.values()
[<SimpleItem at folder/>, <SimpleItem at folder/>]
>>> folder.get('item1')
<SimpleItem at folder/>
>>> if 'item2' in folder:
... del folder['item2']
>>> folder.items()
[('item1', <SimpleItem at folder/>)]
News!
-----
No major new features are available in this version yet.
doc/WINDOWS.rst
View file @ 746f8be0
......@@ -16,7 +16,7 @@ How to build and install Zope from source code on Windows.
% python.exe inst\configure.py
It should say something like:
>
> - Zope top-level binary directory will be c:\Zope-2.12.
> - Zope top-level binary directory will be c:\Zope-2.13.
> - Makefile written.
>
> Next, run the Visual C++ batch file "VCVARS32.bat" and then "nmake".
......
doc/ZOPE3.rst deleted 100644 → 0
View file @ aa808867
Using Zope Components in Zope 2 Applications
============================================
Background
----------
Zope 3 is a separate project from the Zope community aimed at web
development. It is designed to be more 'programmer-centric' and easier
to learn, use and extend for programmers. Zope 3 introduces an
interface-centric component architecture that makes it easier to develop
and deploy components without requiring developers to learn and
understand the entire Zope framework.
As of Zope 2.8, the "Five" project has been integrated into the
Zope 2 core. The "Five" project implements a compatibility layer
that allows many Zope 3 components and patterns to be used in
new and existing Zope 2 applications.
Features
--------
The Five integration layer provides support for Zope 3 interfaces,
Zope Configuration Markup Language (ZCML), adapters, views,
utilities and schema-driven content.
Note that the Five layer does *not* attempt to provide a ZMI user
interface for Zope 3 components.
Zope 2 includes the essential Zope 3 packages, so it is not
necessary to install Zope 3.
doc/conf.py
View file @ 746f8be0
......@@ -49,9 +49,9 @@ copyright = u'2009, The Zope Developers Community'
# built documents.
#
# The short X.Y version.
version = '2.12.0'
version = '2.13'
# The full version, including alpha/beta/rc tags.
release = '2.12.0a4'
release = '2.13.0dev'
# The language for content autogenerated by Sphinx. Refer to documentation
# for a list of supported languages.
......
doc/index.rst
View file @ 746f8be0
Zope 2.12 specific documentation
Zope 2.13 specific documentation
================================
Contents:
......
inst/WinBuilders/mk/zope.mk
View file @ 746f8be0
ZOPEVERSION = 2.12.0b1
ZOPEVERSION = 2.13.0dev
ZOPEDIRNAME := Zope-$(ZOPEVERSION)
ZOPE_REQUIRED_FILES=tmp/$(ZOPEDIRNAME).tgz
......
inst/generate_index.py
View file @ 746f8be0
......@@ -49,7 +49,7 @@ server = Server('http://pypi.python.org/pypi')
links = list()
dirname = sys.argv[1]
write_index('Zope2', '2.12.0a3')
write_index('Zope2', '2.13.0dev')
for package in CP.options('versions'):
......
inst/versions.py
View file @ 746f8be0
ZOPE_MAJOR_VERSION = '2.12'
ZOPE_MAJOR_VERSION = '2.13'
ZOPE_MINOR_VERSION = '0'
ZOPE_BRANCH_NAME = '$Name$'[6:] or 'no-branch'
# always start prerelease branches with '0' to avoid upgrade
# issues in RPMs
VERSION_RELEASE_TAG = 'b1'
VERSION_RELEASE_TAG = '0.dev'
setup.py
View file @ 746f8be0
......@@ -19,7 +19,7 @@ from setuptools import setup, find_packages, Extension
EXTENSIONCLASS_INCLUDEDIRS = ['include', 'src']
params = dict(name='Zope2',
version='2.13dev',
version='2.13.0dev',
url='http://www.zope.org',
license='ZPL 2.1',
description='Zope2 application server / web framework',
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7