[Zope3-dev] Third Zope 3 (mini-)Newsletter

13 Nov 2002 12:00:12 -0500

WELCOME TO THE ZOPE 3 MINI-NEWSLETTER: ISSUE 3 (13 NOV 2002)

  Find out what's going on in Zope 3 development, then contribute your 
  opinions, your experience, and your code to one of the most exciting 
  Open Source projects going.

  Most news is submitted.  Tell us what you're doing!  Send anything 
  from a sentence to a few paragraphs about your latest efforts, be 
  they code, documentation, research, or design, to gary@zope.com.  

  I'll send one of these out whenever we have enough to warrant it--
  just two or three submissions are enough--and I'll also specifically 
  request news from the zope3-dev@zope.org group once a month.  I send 
  them to zope@zope.org and zope3-dev@zope.org (subscribe at 
  http://www.zope.org/Resources/MailingLists), announce it on the front 
  page of zope.org, and archive it at

http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3Newsletter

LITE 'N' EASY GLOSSARY: 

  Each newsletter begins with a high-level glossary that might help you 
  understand a bit about what's going on with some of the announcements.
  Want to help others get a grasp on your favorite Zope 3 (or pertinent
  Zope 2) concept?  Send in a definition, or request one, or fix these.

  Starred (or italicized) items have definitions also in the glossary.  
  Only terms discussed in this newsletter or newly submitted or 
  corrected terms are included here.  For full glossary, see

http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/NewsletterGlossary

  This glossary contains a number of corrected definitions from the last
  newsletter that are otherwise not pertinent to the news--blame the 
  editor! :-)

  [PRELIMINARY, from Steve Alexander]
  CachingService: Right now, the caching service is for caching data so 
  that the cache is common to all the threads in Zope. An example of 
  data cached like this would be the results of calling an SQL method.
  Different cache implementations can be plugged into the Caching 
  service. Currently, there is one implementation that works like the 
  Zope2 Ram Cache Manager.  The scope and functionality of this service
  is under development.

  [CORRECTED]
  Placeful: An adjective describing an object that has a *traversal
  context* in Zope.  For example, an object is placeful if it can be
  reached by traversing a URI path, be it "/myObject",
  "/myFolder/myObject", "/myFolder/myNonZODBConnection/myObject", or
  "/++etc++Services/Packages/default/myErrorService" (the last example 
  is a hypothetical *placeful service*).  More technically, these 
  objects are wrapped, mostly invisibly, with one or more
  "Zope.ContextWrapper"s, which provide the ability to get contextual
  information similar to aq_parent etc. in Zope 2; moreover, following
  these nested wrappers to their ultimate (top or root) context must
  reach the top (root) Zope object (i.e., the object found by traversing
  the path "/").  Note that the correct usage of context wrappers should
  actually use the methods in Zope.Proxy.ContextWrapper, which also
  provide and handle security proxies.  Opposite of *placeless*.

  [PART OF PLACEFUL CORRECTION]
  Placeful Service: a *service* that is *placeful* and is pertinent only
  to the Zope traversal branch (or "folder" and all children) in which
  it resides.  This usually means that the service resides in the *ZODB*
  (and so is *persistent*). Similar to standard programming "local"
  concept of variables in that a placeful service's scope is restricted,
  where the scope in this case is the scope of a traversal branch. A
  placeful service is usually obtained by using a traversal context: in
  Python, after importing Zope.ComponentArchitecture.getService,
  one would use 'getService(myTraversalContext, "Events")' to get a
  placeful event service, where myTraversalContext is another placeful
  object.  Note that if a placeless event service is not installed
  within the traversal context, a *placeless service*, if such exists
  with the requested name (such as "Events"), will be returned.  
  Opposite of *placeless service*.

  [CORRECTED]
  Placeless: An adjective describing an object that does not have a
  traversal context, and usually is not intended to have one.  This
  usually means that one cannot traverse to such an object via any URL
  path, for instance.  Technically, it also means that these objects do
  not have nested "Zope.ContextWrapper"s that resolve eventually and
  finally to the root Zope object (i.e., URI path "/") and, in fact, in
  all to almost all cases, means that they do not have any 
  ContextWrappers at all.  Opposite of *placeful*.

  [PART OF PLACEFUL CORRECTION]
  Placeless Service: a *service* that is *placeless* and is available to
  any object.  This usually means that it does not reside in the *ZODB*
  and is not *persistent*--connections to placeless services, therefore,
  usually must be made on every Zope startup, and are often controlled
  through *ZCML*.  Somewhat similar to standard programming "global"
  concept of variables, in that they are not restricted by any scope,
  where scope in this case is the scope of traversal context (that is, 
  the context of where an object is found in Zope via URI path). A
  placeless service can be obtained (if one by the requested name is
  installed) in Python by importing
  Zope.ComponentArchitecture.getService and then calling
  "getService(None, 'Events')"--that is, the traversal context
  (first argument) is None.  Opposite of Placeful.

  [REPEAT]
  ZCML: Zope Configuration Meta Language.  The XML language that is the 
  file-system configuration tool for site administrators.  One uses it 
  to declare new Zope 3 products, new services, new views, and so on.

NEWS SNIPPETS:

  * Jim Fulton wrote a preliminary Zope 3 roadmap: see 

http://cvs.zope.org/Zope3/doc/ROADMAP.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup
    This is maintained by Godefroid Chapelle and Tom Deprez.  If you 
    head a project on Zope 3 and have not yet contacted Godefroid or Tom
    with information about where your Zope3 job is situated, what the 
    status is (level of completeness) and, briefly, what the project's
    definition is, please do so when you can.

  * Many of the news snippets are covered in Martijn's discussion 
    below.  Workflow and UI got particular attention in the mailing
    list lately.

MARTIJN FAASSEN: Infrae Content Management Sprintathon Update

  The Infrae Sprintathon in Rotterdam, the Netherlands, will have about
  30 developers present (if everybody makes it). This is great! It's
  also a rather dauntingly large number. We've stopped taking
  applications; you can still try (mail faassen@infrae.com) but you'd
  better have a very convincing reason on why you should be joining us
  (for instance, you work for Zope Corporation).

  Having such a large amount of developers present means the preparation
  needs to be very good, so that we won't waste precious time at the
  event itself and avoid utter chaos. We're going to be strict about
  this, so do read the wiki page about this here:

http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/CMSprintPreparation

  We have several project teams and not everybody has joined a project
  yet. So hurry and join one -- here's the hype!

    * Workflow. The very active workflow team seems to be full of
      workflow gurus; they seem to be writing their fourth workflow
      system or so. If you're not a guru then this may be a great
      opportunity to learn more about workflow!

http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/CMSprintWorkflow

    * Documentation. The documentation project will be working on
      providing stand-alone narrative documentation for Zope 3
      developers. Writing documentation is a great opportunity to learn
      more about the way Zope 3 works. It is also a good opportunity to
      influence the design of Zope 3 by writing what Jim calls "science
      fiction" documentation -- documentation of code that does not yet
      exist.

      The documentation project also has an interest in generating
      documentation from the current codebase.

http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/CMSprintDocumentation

    * Searching. Struggling with the ZCatalog in Zope 2? Think there
      should be a better way? Here's your opportunity to make your life
      better in Zope 3. EventService! ObjectHub! Learn more about them
      and improve life for future generations.

http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/CMSprintSearching

    * User Interface. Everybody likes to talk about it. Everybody has
      ideas. The User Interface project will be laying the groundwork
      and will actually do something about it. Join user interface
      experts in our user interface team!

http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/CMSprintUserInterface

    * User Management. Zope 2's user management system is, out of the
      box, rather simple. In order to really do something you need to
      install one of the many extension products. Now the challenge is
      to take the lessons learned from these and build a solid
      foundation for user management in Zope 3. A concrete
      get-your-hands-dirty project.

http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/CMSprintUserManagement

  For regular updates see the main page about the sprintathon:

http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/InfraeSprintathon

  The CodeWorksSprint in Vilnius, Lithuania will be held in the week
  after the InfraeSprintathon.  Several people present at the
  sprintathon will be at this sprint as well, including Jim Fulton. See
  this page for more information:

http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/CodeWorksSprint

STEVE ALEXANDER: Logger, cache manager, and bug fixing

  I fixed up the components that log http and ftp requests: the 
  interface and implementations were out of synch.

  I've been helping CodeWorks out with their CacheManager work.

  Brad at CodeWorks found a curious security bug, which we tracked down 
  to some problems in ZopeSecurityPolicy, and successfully fixed.

R. DAVID MURRAY: ZCML documentation, doc tools, and polish

  I checked in my changes to Zope.Configuration (the zcml parser) to
  allow directives and attributes to have description strings attached
  in the meta.zcml files, and a utility to extract those descriptions
  into structured text files following the format laid down by Steve
  Alexander in the doc/zcml/namespaces.zope.org documentation.

  Now all we have to do is get all the meta.zcml files updated to
  include descriptions.  The doc tool (makezcmldocs) prints error
  messages to stdout if a directive or attribute doesn't have a doc
  string (it tries to guess the directory the directive is defined in;
  most of the time it gets it right).  I'll work on adding proper
  description strings as I learn various modules, but it's a non-trivial
  job and help would be welcome.  Take a look at
  Zope.App.ContentDirective/meta.zcml for an example (or the first part
  of doc/zcml/meta.stx).

  Note: if you change a meta.zcml file over to the "new style", you
  will probably have to update the module's tests by inserting

    XMLConfig('metameta.zcml',Zope.Configuration)()

  before the corresponding line in the unit test setUp that loads
  the module's own meta.zcml file.

  After a mailing list discussion, I also simplified the
  Zope.Configuration by eliminating the top level 'directive'
  directive.  Directive definitions now *must* be enclosed in a
  'directives' markup.  This is how all the existing zcml was written
  anyway.

NEWS CONTRIBUTION GUIDELINES:

  We want to know what you're doing, be it code or design, so just 
  write something quick and easy.  First person and casual is fine, as 
  you can see.  Send to gary@zope.com whenever the spirit moves you.

LEARN MORE ABOUT ZOPE 3:

  See http://lists.zope.org/mailman/listinfo/zope3-dev
  See
http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/FrontPage 
  but be aware the design docs often lag as we develop prototypes.
  Again, these newsletters and the compiled glossary are archived at 

http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3Newsletter