[Zope3-checkins] SVN: Zope3/branches/ZopeX3-3.0/src/zope/ More
ReSTification and consistency changes.
Fred L. Drake, Jr.
fred at zope.com
Fri Jul 16 15:28:56 EDT 2004
Log message for revision 26589:
More ReSTification and consistency changes.
Changed:
U Zope3/branches/ZopeX3-3.0/src/zope/app/registration/README.txt
U Zope3/branches/ZopeX3-3.0/src/zope/event/README.txt
U Zope3/branches/ZopeX3-3.0/src/zope/interface/README.txt
U Zope3/branches/ZopeX3-3.0/src/zope/interface/adapter.txt
U Zope3/branches/ZopeX3-3.0/src/zope/interface/tests/foodforthought.txt
U Zope3/branches/ZopeX3-3.0/src/zope/schema/fields.txt
-=-
Modified: Zope3/branches/ZopeX3-3.0/src/zope/app/registration/README.txt
===================================================================
--- Zope3/branches/ZopeX3-3.0/src/zope/app/registration/README.txt 2004-07-16 19:01:59 UTC (rev 26588)
+++ Zope3/branches/ZopeX3-3.0/src/zope/app/registration/README.txt 2004-07-16 19:28:56 UTC (rev 26589)
@@ -76,25 +76,21 @@
There are several major concepts/terms that need to be understood
-- Registerables
-
+Registerables
Registerables are objects that can be registered. They implement the
- ``IRegisterable'' interface.
+ `IRegisterable` interface.
-- Registries
-
+Registries
Registeries are objects that registerables are registered with.
Typically, these are component-management services like the adapter
or utility service.
-- Registration objects
-
+Registration objects
Registration objects store data about registrations. They store
registration data and represent the relationship between registries
and registerables.
-- Registration managers
-
+Registration managers
Registration managers are containers for managing registrations.
Registrations are stored in registration managers. All of the
registrations for objects stored in a site-management folder are
@@ -103,15 +99,14 @@
this so that the registration manager is exposed as a folder tab
rather than as an item.
-- Registration stack
-
+Registration stack
Registries allow multiple registrations for the same set of
registration parameters. At most one registration for a set of
parameters can be active at one time, but multiple registrations are
managed.
- Registries provide functions for looking up (``queryRegistrationsFor'')
- or creating (``createRegistrationsFor'') registration stacks. These
+ Registries provide functions for looking up (`queryRegistrationsFor()`)
+ or creating (`createRegistrationsFor()`) registration stacks. These
methods are passed registration objects whos attribute values are
used to specify the desired registration stacks.
@@ -120,13 +115,12 @@
by the uttility, and the utility name. For a given interface and
name, the utility service may have multiple ustility
registrations. It uses a registration stack to store these. We can
- get the registration stack by calling ``queryRegistrationsFor'' with
+ get the registration stack by calling `queryRegistrationsFor()` with
a registration object that has the desired interface and name. The
registration object passed need not be in in the stack. It is used
soley to provide the parameters.
-- Registered
-
- The interface ``IRegistered'' provides storage and access to the
+Registered
+ The interface `IRegistered` provides storage and access to the
registrations for a registerable. When we make a registration, we
refer to it in a registration stack and in the registered object.
Modified: Zope3/branches/ZopeX3-3.0/src/zope/event/README.txt
===================================================================
--- Zope3/branches/ZopeX3-3.0/src/zope/event/README.txt 2004-07-16 19:01:59 UTC (rev 26588)
+++ Zope3/branches/ZopeX3-3.0/src/zope/event/README.txt 2004-07-16 19:28:56 UTC (rev 26589)
@@ -14,14 +14,16 @@
The package has a list of subscribers. Application code can manage
subscriptions by manipulating this list. For the examples here, we'll
save the current contents away and empty the list. We'll restore the
-contents when we're done with out examples.
+contents when we're done with our examples.
+::
+
>>> import zope.event
>>> old_subscribers = zope.event.subscribers[:]
>>> del zope.event.subscribers[:]
The package provides a `notify` function, which is used to
-notify subscribers that something has happened:
+notify subscribers that something has happened::
>>> class MyEvent:
... pass
@@ -30,18 +32,18 @@
>>> zope.event.notify(event)
The notify function is called with a single object, which we call an
-event. Any object will do:
+event. Any object will do::
>>> zope.event.notify(None)
>>> zope.event.notify(42)
An extremely trivial subscription mechanism is provided. Subscribers
-are simply callback functions:
+are simply callback functions::
>>> def f(event):
... print 'got:', event
-that are put into the subscriptions list:
+that are put into the subscriptions list::
>>> zope.event.subscribers.append(f)
@@ -57,7 +59,7 @@
got: 42
also got: 42
-To unsubscribe, simply remove a subscriber from the list:
+To unsubscribe, simply remove a subscriber from the list::
>>> zope.event.subscribers.remove(f)
>>> zope.event.notify(42)
@@ -68,6 +70,6 @@
frameworks will install subscribers that then dispatch to other
subscribers based on event types or data.
-We're done, so we'll restore the subscribers:
+We're done, so we'll restore the subscribers::
>>> zope.event.subscribers[:] = old_subscribers
Modified: Zope3/branches/ZopeX3-3.0/src/zope/interface/README.txt
===================================================================
--- Zope3/branches/ZopeX3-3.0/src/zope/interface/README.txt 2004-07-16 19:01:59 UTC (rev 26588)
+++ Zope3/branches/ZopeX3-3.0/src/zope/interface/README.txt 2004-07-16 19:28:56 UTC (rev 26589)
@@ -37,23 +37,23 @@
In the example above, we've created an interface, `IFoo`. We
subclassed `zope.interface.Interface`, which is an ancestor interface for
all interfaces, much as `object` is an ancestor of all new-style
-classes [#create]_. The interface is not a class, It's an Interface,
-an instance of `InterfaceClass`:
+classes [#create]_. The interface is not a class, it's an Interface,
+an instance of `InterfaceClass`::
>>> type(IFoo)
<class 'zope.interface.interface.InterfaceClass'>
-We can ask for the interfaces documentation:
+We can ask for the interfaces documentation::
>>> IFoo.__doc__
'Foo blah blah'
-and it's name:
+and it's name::
>>> IFoo.__name__
'IFoo'
-and even it's module:
+and even it's module::
>>> IFoo.__module__
'__main__'
@@ -80,7 +80,7 @@
methods that are not instance methods.
You can access the attributes defined by an interface using mapping
-syntax:
+syntax::
>>> x = IFoo['x']
>>> type(x)
@@ -90,12 +90,12 @@
>>> x.__doc__
'X blah blah'
-You can use `in` to determine if an interface defines a name:
+You can use `in` to determine if an interface defines a name::
>>> 'x' in IFoo
True
-You can iterate over interfaces to get the names they define:
+You can iterate over interfaces to get the names they define::
>>> names = list(IFoo)
>>> names.sort()
@@ -103,14 +103,14 @@
['bar', 'x']
Remember that interfaces aren't classes. You can't access attribute
-definitions as attributes of interfaces:
+definitions as attributes of interfaces::
>>> IFoo.x
Traceback (most recent call last):
File "<stdin>", line 1, in ?
AttributeError: 'InterfaceClass' object has no attribute 'x'
-Methods provide access to the method signature:
+Methods provide access to the method signature::
>>> bar = IFoo['bar']
>>> bar.getSignatureString()
@@ -146,7 +146,7 @@
declaring interfaces.
The most common way to declare interfaces is using the implements
-function in a class statement:
+function in a class statement::
>>> class Foo:
... zope.interface.implements(IFoo)
@@ -164,28 +164,28 @@
In this example, we declared that `Foo` implements `IFoo`. This means
that instances of `Foo` provide `IFoo`. Having made this declaration,
there are several ways we can introspect the declarations. First, we
-can ask an interface whether it is implemented by a class:
+can ask an interface whether it is implemented by a class::
>>> IFoo.implementedBy(Foo)
True
-And we can ask whether an interface is provided by an object:
+And we can ask whether an interface is provided by an object::
>>> foo = Foo()
>>> IFoo.providedBy(foo)
True
-Of course, `Foo` doesn't provide `IFoo`, it implements it.
+Of course, `Foo` doesn't provide `IFoo`, it implements it::
>>> IFoo.providedBy(Foo)
False
-We can also ask what interfaces are implemented by an object:
+We can also ask what interfaces are implemented by an object::
>>> list(zope.interface.implementedBy(Foo))
[<InterfaceClass __main__.IFoo>]
-It's an error to ask for interfaces implemented by a non-class:
+It's an error to ask for interfaces implemented by a non-class::
>>> IFoo.implementedBy(foo)
Traceback (most recent call last):
@@ -197,7 +197,7 @@
...
TypeError: ('ImplementedBy called for non-type', Foo(None))
-Similarly, we can ask what interfaces are provided by an object:
+Similarly, we can ask what interfaces are provided by an object::
>>> list(zope.interface.providedBy(foo))
[<InterfaceClass __main__.IFoo>]
@@ -208,7 +208,7 @@
we want to document what the `__init__` method of the `Foo` class
does. It's not *really* part of `IFoo`. You wouldn't normally call
the `__init__` method on Foo instances. Rather, the `__init__` method
-is part of the `Foo`'s `__call__` method:
+is part of the `Foo`'s `__call__` method::
>>> class IFooFactory(zope.interface.Interface):
... """Create foos"""
@@ -220,11 +220,11 @@
... """
It's the class that provides this interface, so we declare the
-interface on the class:
+interface on the class::
>>> zope.interface.directlyProvides(Foo, IFooFactory)
-And then, we'll see that Foo provides some interfaces:
+And then, we'll see that Foo provides some interfaces::
>>> list(zope.interface.providedBy(Foo))
[<InterfaceClass __main__.IFooFactory>]
@@ -233,7 +233,7 @@
Declaring class interfaces is common enough that there's a special
declaration function for it, `classProvides`, that allows the
-declaration from within a class statement:
+declaration from within a class statement::
>>> class Foo2:
... zope.interface.implements(IFoo)
@@ -260,7 +260,7 @@
Sometimes, we want to declare interfaces on instances, even though
those instances get interfaces from their classes. Suppose we create
-a new interface, `ISpecial`:
+a new interface, `ISpecial`::
>>> class ISpecial(zope.interface.Interface):
... reason = zope.interface.Attribute("Reason why we're special")
@@ -268,7 +268,7 @@
... "Brag about being special"
We can make a an existing foo instance special by providing `reason`
-and `brag` attributes:
+and `brag` attributes::
>>> foo.reason = 'I just am'
>>> def brag():
@@ -279,18 +279,18 @@
>>> foo.brag()
"I'm special!"
-and by declaring the interface:
+and by declaring the interface::
>>> zope.interface.directlyProvides(foo, ISpecial)
-then the new interface is included in the provided interfaces:
+then the new interface is included in the provided interfaces::
>>> ISpecial.providedBy(foo)
True
>>> list(zope.interface.providedBy(foo))
[<InterfaceClass __main__.ISpecial>, <InterfaceClass __main__.IFoo>]
-We can find out what interfaces are directly provided by an object:
+We can find out what interfaces are directly provided by an object::
>>> list(zope.interface.directlyProvidedBy(foo))
[<InterfaceClass __main__.ISpecial>]
@@ -302,7 +302,7 @@
Inherited declarations
----------------------
-Normally, declarations are inherited:
+Normally, declarations are inherited::
>>> class SpecialFoo(Foo):
... zope.interface.implements(ISpecial)
@@ -317,7 +317,7 @@
[<InterfaceClass __main__.ISpecial>, <InterfaceClass __main__.IFoo>]
Sometimes, you don't want to inherit declarations. In that case, you
-can use `implementsOnly`, instead of `implements`:
+can use `implementsOnly`, instead of `implements`::
>>> class Special(Foo):
... zope.interface.implementsOnly(ISpecial)
@@ -338,7 +338,7 @@
definition. Sometimes, we may want to make declarations from outside
the class definition. For example, we might want to declare interfaces
for classes that we didn't write. The function `classImplements` can
-be used for this purpose:
+be used for this purpose::
>>> class C:
... pass
@@ -347,7 +347,7 @@
>>> list(zope.interface.implementedBy(C))
[<InterfaceClass __main__.IFoo>]
-We can use `classImplementsOnly` to exclude inherited interfaces:
+We can use `classImplementsOnly` to exclude inherited interfaces::
>>> class C(Foo):
... pass
@@ -362,7 +362,7 @@
-------------------
When we declare interfaces, we create *declaration* objects. When we
-query declarations, declaration objects are returned:
+query declarations, declaration objects are returned::
>>> type(zope.interface.implementedBy(Special))
<class 'zope.interface.declarations.Implements'>
@@ -370,7 +370,7 @@
Declaration objects and interface objects are similar in many ways. In
fact, they share a common base class. The important thing to realize
about them is that they can be used where interfaces are expected in
-declarations. Here's a silly example:
+declarations. Here's a silly example::
>>> class Special2(Foo):
... zope.interface.implementsOnly(
@@ -383,7 +383,7 @@
The declaration here is almost the same as
``zope.interface.implements(ISpecial)``, except that the order of
-interfaces in the resulting declaration is different:
+interfaces in the resulting declaration is different::
>>> list(zope.interface.implementedBy(Special2))
[<InterfaceClass __main__.IFoo>, <InterfaceClass __main__.ISpecial>]
@@ -395,7 +395,7 @@
=====================
Interfaces can extend other interfaces. They do this simply by listing
-the other interfaces as base interfaces:
+the other interfaces as base interfaces::
>>> class IBlat(zope.interface.Interface):
... """Blat blah blah"""
@@ -421,7 +421,7 @@
>>> names
['bar', 'eek', 'x', 'y']
-Note that `IBaz` overrides eek:
+Note that `IBaz` overrides eek::
>>> IBlat['eek'].__doc__
'eek blah blah'
@@ -432,19 +432,19 @@
extending an interface, the extending interface should be compatible
[#compat]_ with the extended interfaces.
-We can ask whether one interface extends another:
+We can ask whether one interface extends another::
>>> IBaz.extends(IFoo)
True
>>> IBlat.extends(IFoo)
False
-Note that interfaces don't extend themselves:
+Note that interfaces don't extend themselves::
>>> IBaz.extends(IBaz)
False
-Sometimes we wish they did, but we can, instead use `isOrExtends`:
+Sometimes we wish they did, but we can, instead use `isOrExtends`::
>>> IBaz.isOrExtends(IBaz)
True
@@ -456,7 +456,7 @@
When we iterate over an interface, we get all of the names it defines,
including names defined by base interfaces. Sometimes, we want *just*
the names defined by the interface directly. We bane use the `names`
-method for that:
+method for that::
>>> list(IBaz.names())
['eek']
@@ -467,7 +467,7 @@
Interfaces and attribute descriptions support an extension mechanism,
borrowed from UML, called "tagged values" that lets us store extra
-data:
+data::
>>> IFoo.setTaggedValue('date-modified', '2004-04-01')
>>> IFoo.setTaggedValue('author', 'Jim Fulton')
@@ -482,7 +482,7 @@
['author', 'date-modified']
Function attributes are converted to tagged values when method
-attribute definitions are created:
+attribute definitions are created::
>>> class IBazFactory(zope.interface.Interface):
... def __call__():
@@ -500,7 +500,7 @@
provide them. These conditions are expressed using one or more
invariants. Invariants are callable objects that will be called with
an object that provides an interface. An invariant raises an `Invalid`
-exception if the condition doesn't hold. Here's an example:
+exception if the condition doesn't hold. Here's an example::
>>> class RangeError(zope.interface.Invalid):
... """A range has invalid limits"""
@@ -511,7 +511,7 @@
... if ob.max < ob.min:
... raise RangeError(ob)
-Given this invariant, we can use it in an interface definition:
+Given this invariant, we can use it in an interface definition::
>>> class IRange(zope.interface.Interface):
... min = zope.interface.Attribute("Lower bound")
@@ -519,7 +519,7 @@
...
... zope.interface.invariant(range_invariant)
-Interfaces have a method for checking their invariants:
+Interfaces have a method for checking their invariants::
>>> class Range(object):
... zope.interface.implements(IRange)
@@ -540,7 +540,7 @@
If you have multiple invariants, you may not want to stop checking
after the first error. If you pass a list to `validateInvariants`,
then a single `Invalid` exception will be raised with the list of
-exceptions as it's argument:
+exceptions as it's argument::
>>> errors = []
>>> IRange.validateInvariants(Range(2,1), errors)
@@ -548,7 +548,7 @@
...
Invalid: [RangeError(Range(2, 1))]
-And the list will be filled with the individual exceptions:
+And the list will be filled with the individual exceptions::
>>> errors
[RangeError(Range(2, 1))]
Modified: Zope3/branches/ZopeX3-3.0/src/zope/interface/adapter.txt
===================================================================
--- Zope3/branches/ZopeX3-3.0/src/zope/interface/adapter.txt 2004-07-16 19:01:59 UTC (rev 26588)
+++ Zope3/branches/ZopeX3-3.0/src/zope/interface/adapter.txt 2004-07-16 19:28:56 UTC (rev 26589)
@@ -94,7 +94,7 @@
>>> registry.lookup([IR1], IP1, 'bob')
"Bob's 12"
-You can leave the name off when doing a lookup:
+You can leave the name off when doing a lookup::
>>> registry.lookup([IR1], IP1)
12
@@ -118,8 +118,8 @@
lookup1
-------
-Lookup of single adapters is common enough that there is a
-specialized version of lookup that takes a single required interface:
+Lookup of single adapters is common enough that there is a specialized
+version of lookup that takes a single required interface::
>>> registry.lookup1(IR2, IP1, '')
21
@@ -133,7 +133,7 @@
object that implements an interface is adapted to another object that
supports a different interface. The adapter registry supports the
computation of adapters. In this case, we have to register adapter
-factories:
+factories::
>>> class IR(zope.interface.Interface):
... pass
@@ -149,7 +149,7 @@
>>> registry.register([IR], IP1, '', Y)
In this case, we registered a class as the factory. Now we can call
-`queryAdapter` to get the adapted object:
+`queryAdapter` to get the adapted object::
>>> x = X()
>>> y = registry.queryAdapter(x, IP1)
@@ -158,7 +158,7 @@
>>> y.context is x
True
-We can register and lookup by name too:
+We can register and lookup by name too::
>>> class Y2(Y):
... pass
@@ -170,8 +170,8 @@
>>> y.context is x
True
-An alternate method that provides the same function as `queryAdapter` is
-`adapter_hook`:
+An alternate method that provides the same function as `queryAdapter()` is
+`adapter_hook()`::
>>> y = registry.adapter_hook(IP1, x)
>>> y.__class__.__name__
@@ -184,7 +184,7 @@
>>> y.context is x
True
-The `adapter_hook` simply switches the order of the object and
+The `adapter_hook()` simply switches the order of the object and
interface arguments. It is used to hook into the interface call
mechanism.
@@ -223,7 +223,7 @@
Unregistering
-------------
-You can unregister by registering None, rather than an object:;
+You can unregister by registering None, rather than an object::
>>> registry.register([zope.interface.implementedBy(C2)], IP1, '', None)
>>> registry.lookup([zope.interface.implementedBy(C2)], IP1, '')
@@ -261,12 +261,12 @@
Multi-adaptation
----------------
-You can adapt multiple objects:
+You can adapt multiple objects::
>>> class Q:
... zope.interface.implements(IQ)
-As with single adapters, we register a factory, which is often a class:
+As with single adapters, we register a factory, which is often a class::
>>> class IM(zope.interface.Interface):
... pass
@@ -276,7 +276,7 @@
... self.x, self.q = x, q
>>> registry.register([IR, IQ], IM, '', M)
-And then we can call `queryMultiAdapter` to compute an adapter:
+And then we can call `queryMultiAdapter` to compute an adapter::
>>> q = Q()
>>> m = registry.queryMultiAdapter((x, q), IM)
@@ -285,7 +285,7 @@
>>> m.x is x and m.q is q
True
-and, of course, we can use names:
+and, of course, we can use names::
>>> class M2(M):
... pass
@@ -300,7 +300,7 @@
----------------
As with single adapters, you can define default adapters by specifying
-None for the *first* specification:
+None for the *first* specification::
>>> registry.register([None, IQ], IP2, '', 'q2')
>>> registry.lookup([IS, IQ], IP2, '')
@@ -309,7 +309,7 @@
Null Adapters
=============
-You can also adapt no specification:
+You can also adapt no specification::
>>> registry.register([], IP2, '', 2)
>>> registry.lookup([], IP2, '')
@@ -321,14 +321,14 @@
----------------------
Adapters are named. Sometimes, it's useful to get all of the named
-adapters for given interfaces.
+adapters for given interfaces::
>>> adapters = list(registry.lookupAll([IR1], IP1))
>>> adapters.sort()
>>> adapters
[(u'', 11), (u'bob', "Bob's 12")]
-This works for multi-adapters too:
+This works for multi-adapters too::
>>> registry.register([IR1, IQ2], IP2, 'bob', '1q2 for bob')
>>> adapters = list(registry.lookupAll([IR2, IQ2], IP1))
@@ -336,7 +336,7 @@
>>> adapters
[(u'', '1q22'), (u'bob', '1q2 for bob')]
-And even null adapters:
+And even null adapters::
>>> registry.register([], IP2, 'bob', 3)
>>> adapters = list(registry.lookupAll([], IP1))
@@ -437,7 +437,7 @@
We normally register adapter factories, which then allow us to compute
adapters, but with subscriptions, we get multiple adapters. Here's an
-example of multiple-object subscribers:
+example of multiple-object subscribers::
>>> registry.subscribe([IR, IQ], IM, M)
>>> registry.subscribe([IR, IQ], IM, M2)
@@ -460,7 +460,7 @@
output. It returns None. A handler is unlike adapters in that it does
all of it's work when the factory is called.
-To register a handler, simply provide None as the provided interface:
+To register a handler, simply provide None as the provided interface::
>>> def handler(event):
... print 'handler', event
Modified: Zope3/branches/ZopeX3-3.0/src/zope/interface/tests/foodforthought.txt
===================================================================
--- Zope3/branches/ZopeX3-3.0/src/zope/interface/tests/foodforthought.txt 2004-07-16 19:01:59 UTC (rev 26588)
+++ Zope3/branches/ZopeX3-3.0/src/zope/interface/tests/foodforthought.txt 2004-07-16 19:28:56 UTC (rev 26589)
@@ -3,7 +3,7 @@
================================
-This file gives more subscription examples using a cooking-based examples
+This file gives more subscription examples using a cooking-based example::
>>> from zope.interface.adapter import AdapterRegistry
>>> registry = AdapterRegistry()
@@ -19,7 +19,7 @@
... pass
Adapting to some other interface for which there is no
-subscription adapter returns an empty sequence:
+subscription adapter returns an empty sequence::
>>> class IRecipe(zope.interface.Interface):
... pass
@@ -30,32 +30,32 @@
>>> class IKFC(IRecipe):
... pass
->>> list(registry.subscriptions([IPoultry], IRecipe))
-[]
+ >>> list(registry.subscriptions([IPoultry], IRecipe))
+ []
unless we define a subscription::
->>> registry.subscribe([IAnimal], ISausages, 'sausages')
->>> list(registry.subscriptions([IPoultry], ISausages))
-['sausages']
+ >>> registry.subscribe([IAnimal], ISausages, 'sausages')
+ >>> list(registry.subscriptions([IPoultry], ISausages))
+ ['sausages']
-And define another subscription adapter:
+And define another subscription adapter::
->>> registry.subscribe([IPoultry], INoodles, 'noodles')
->>> meals = list(registry.subscriptions([IPoultry], IRecipe))
->>> meals.sort()
->>> meals
-['noodles', 'sausages']
+ >>> registry.subscribe([IPoultry], INoodles, 'noodles')
+ >>> meals = list(registry.subscriptions([IPoultry], IRecipe))
+ >>> meals.sort()
+ >>> meals
+ ['noodles', 'sausages']
->>> registry.subscribe([IChicken], IKFC, 'kfc')
->>> meals = list(registry.subscriptions([IChicken], IRecipe))
->>> meals.sort()
->>> meals
-['kfc', 'noodles', 'sausages']
+ >>> registry.subscribe([IChicken], IKFC, 'kfc')
+ >>> meals = list(registry.subscriptions([IChicken], IRecipe))
+ >>> meals.sort()
+ >>> meals
+ ['kfc', 'noodles', 'sausages']
-And the answer for poultry hasn't changed:
+And the answer for poultry hasn't changed::
->>> meals = list(registry.subscriptions([IPoultry], IRecipe))
->>> meals.sort()
->>> meals
-['noodles', 'sausages']
+ >>> meals = list(registry.subscriptions([IPoultry], IRecipe))
+ >>> meals.sort()
+ >>> meals
+ ['noodles', 'sausages']
Modified: Zope3/branches/ZopeX3-3.0/src/zope/schema/fields.txt
===================================================================
--- Zope3/branches/ZopeX3-3.0/src/zope/schema/fields.txt 2004-07-16 19:01:59 UTC (rev 26588)
+++ Zope3/branches/ZopeX3-3.0/src/zope/schema/fields.txt 2004-07-16 19:28:56 UTC (rev 26589)
@@ -152,4 +152,4 @@
on the basis of uniqueness and other constraints.
This level of indirection may be unnecessary for some applications, and can be
-disabled with simple zcml changes within zope.app.
+disabled with simple ZCML changes within `zope.app`.
More information about the Zope3-Checkins
mailing list