[Zope3-checkins] CVS: Zope3/src/zope/schema - readme.stx:1.3

Steve Alexander steve@cat-box.net
Tue, 28 Jan 2003 06:24:25 -0500


Update of /cvs-repository/Zope3/src/zope/schema
In directory cvs.zope.org:/tmp/cvs-serv12550/src/zope/schema

Modified Files:
	readme.stx 
Log Message:
whitespace + typos


=== Zope3/src/zope/schema/readme.stx 1.2 => 1.3 ===
--- Zope3/src/zope/schema/readme.stx:1.2	Wed Dec 25 09:15:20 2002
+++ Zope3/src/zope/schema/readme.stx	Tue Jan 28 06:24:22 2003
@@ -10,9 +10,9 @@
      should you care?
 
      What does a Schema look like 
-     
+
      Where Schemas make sense: Providing views from Schemas 
-     
+
      Issues to be solved 
 
 
@@ -85,11 +85,12 @@
                        constraint = re.compile("\d{5,5}(-\d{4,4})?$").match)
 
     'TextLine' is a field and expresses that an attribute is a single line
-    of unicode text.  'Text' expresses an arbitrary unicode ("text") object. 
-    The most interesting part is the last attribute specification. It constrains
-    the 'postalCode' attribute to only have values that are US postal codes.
-      
-    Now we want a class that aheres to the IContact Schema:
+    of unicode text.  'Text' expresses an arbitrary unicode ("text") object.
+    The most interesting part is the last attribute specification. It
+    constrains the 'postalCode' attribute to only have values that are US
+    postal codes.
+
+    Now we want a class that adheres to the IContact Schema:
 
     class Contact(Persistence.Persistent):
         __implements__ = IContact
@@ -108,24 +109,24 @@
     someone = contact('Tim','Roberts', 'tim@roberts', '','')
     validateMapping(IContact, someone.__dict__)
 
-     
+
 Issues to be solved
 
-    These issues were written up at Rotterdam Sprint (12/4/2002). 
- 
- I18n 
- 
+    These issues were written up at Rotterdam Sprint (12/4/2002)
+
+ I18n
+
     How i18n interferes with Schemas is not thought out. In an non-english
-    context we probably want to have titles and descriptions easily 
-    translatable.  The best idea so far is to use an attribute name 
-    together with its surrounding namespace (Interface-name etc.) 
-    as the canonical unique id used for looking up translations. 
+    context we probably want to have titles and descriptions easily
+    translatable.  The best idea so far is to use an attribute name
+    together with its surrounding namespace (Interface-name etc.)
+    as the canonical unique id used for looking up translations.
 
     Example:
-  
+
     class book(Interface):
         author = ITextLine()
-     
+
     To get to the And in view, while the widget or widget's messages
     are constructed:
 
@@ -140,9 +141,9 @@
 
     Shouldn't the 'implements' function on the interface package be
     named setImplements as opposed to getImplements? This way if you write
-    
+
       setImplements(klass, interface) 
-    
+
     it is obvious what you mean (as opposed to implements(klass, interface)
     which could mean *asking* if the klass implements the interface.
 
@@ -150,11 +151,11 @@
 
     Some use cases are not easy to understand.  A lot of them look like 
     features rather than use cases.  The list of schema use cases 
-    needs to be cleaned up and be (sometimes) more detailed.  
+    needs to be cleaned up and be (sometimes) more detailed.
 
 References
 
- Use case list, 
+ Use case list,
    http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3SchemasUseCases
 
  documented interfaces, Zope/Schema/IField.py