Welcome to the tenth Zope 3 newsletter.  Information about Zope 3
  and newsletter contributions and suggestions can be found at the
  bottom of this newsletter.


  Encounter a term in this newsletter you don't know?  Try this
  glossary:  http://dev.zope.org/Zope3/NewsletterGlossary


- Be sure to read Stephan's release management news item, below.

 - Next "geddon" (big change to Zope 3, a la Armageddon) appears
   likely to be container-geddon, which in part is a parent- or
   context-wrapper-geddon.  In a big move from Zope 2 approaches,
   Zope 3 will not rely on context wrappers in the default
   configuration.  Objects stored in the Zope 3 ZODB will either
   implement an interface that allows their immediate parent to be
   stored as a reference, or be adaptable to a persistent wrapper
   that implements this behavior.

   The advantage is expected to be that references to other objects
   in the system can be much more Pythonic--foregoing storing paths
   in favor of actually storing the Python object references.  This
   should greatly simplify writing local services and other
   context- and Zope-aware machinery.  The disadvantage for some
   applications is that objects can then only have one traversal
   parent, and thus only one traversal path.  This limitation is
   expected to be mitigated, as necessary, with alternate
   configurations using context wrappers (which will still be
   available) or with other mechanisms such as proxies.

   Questions or concerns?  See
   http://dev.zope.org/Zope3/ParentGeddon or the other resources
   listed at the bottom of the newsletter!



    Jim's ZCMLGeddon had finally landed, so Stephan and I went
    through the complete source tree and converted all directives
    using schemas. The biggest benefit was that user strings in
    configuration (like titles or descriptions) are translated now.
    Other benefits are better extensibility, override support and
    cleaner meta-configuration code.

    I also made an attempt to get XML schema interfaces working
    again (support for it had to be dropped temporarily in order
    to advance with ZCML geddon). While I succeeded in doing that,
    my changes are slowly rotting in zcml-interface-field-branch. I
    had to do it in a branch since the change involved a few
    hard-wirings in zope.app which I wanted Jim to look at.
    Unfortunately, he was very busy with ParentGeddon at the time.


    Now that we had quite a few MessageIDs coming from ZCML, it
    only made sense to go through the python code and
    internationalize it. Fortunately, Stephan took on that part.
    However, I was happy to help him translate all of Zope3 to
    German, once his work was done. I have also started translating
    it to Spanish, but as I am not a native speaker, help from
    someone who is would be greatly appreciated.

    Sidnei da Silva and Godefroid Chappelle started translations
    for Brazilian Portuguese and French, respectively.

i18n and ZCML

    While translating, I found that a few English words like "View"
    or "Change" are ambiguous when used without a context. For
    example, "View" could both mean a view component or the "View"
    permission. While (sadly)  one word applies to them in English,
    the contrary is the case in most other languages.

    While Stephan first argued for different i18n domains, like
    zope_components, zope_permissions etc. (we currently have
    everything under one domain, zope), him, Fred and I came to the
    conclusion that using explicit MessageIDs was the better
    solution. While both python and TAL support setting explicitly
    MessageIDs, ZCML's i18n machinery didn't so far. For a
    directive such as::

<permission id="zope.View" title="View" />

I proposed the following syntax::

<permission id="zope.View" title="[view-permission] View" />

    Martijn Faassen and Godefroid Chapelle rejected this idea,
    mainly because it created a new syntax and was incoherent to
    TAL's i18n support. Their suggestion was to be coherent with
    TAL and use i18n:attributes. Stephan and I however argued that

a) ZCML isn't TAL

b) namespaces have a different connotation in ZCML

      c) i18n is currently not part of the core ZCML machinery
         -- should it be?

      d) it would thus require major changes to the ZCML machinery
         -- again!

    The discussion drifted slowly away from the main issue (i18n)
    into a general ZCML discussion which is still going on. Shane
    Hathaway expressed his general doubts on ZCML usability and
    Martijn announced he will put some effort in studying ZCML's
    current usage and try to come up with improvements.

    While we appreciated this rich input concerning ZCML (even
    though it came *after* ZCML geddon), Stephan and I needed a fix
    for our original i18n problem, so we went ahead and implemented
    my proposal.  It seems the issue remains open. We are glad to
    have a fix for the problem now, but we surely appreciate
    suggestions on how to solve it in a more elegant way.

Unused imports

    Having found many unused imports during ZCMLGeddon and the
    following i18n work, I took an hour to mock up Martijn's
    importchecker tool to produce grep-style output. The benefit is
    not only better readability of the output (above all: line
    numbers) but it means that Emacs now understands its output,
    making it a lot easier actually removing all of those unused

    After I had successfully removed all unused imports from Zope3,
    I contributed my patch to Martijn. He promised to revise the
    code and make a release asap.

FRED DRAKE: Improved security for zsync checkouts

   The "zsync" client for Zope's filesystem synchronization support
   now makes it easier to separate authentication data from a
   checked-out copy of objects in Zope's database.

   New "login" and "logout" commands, modeled on those of CVS,
   allow authentication tokens to be stored in a persistent cache
   separate from a checkout.  This can be used to avoid storing the
   password as part of the URL used to check out an object tree.
   For example, to check out a portion of a Zope site without
   storing the password in the tree, "log in" to the site and then
   perform the checkout::

      % zsync login -u username http://example.com/
      Password for username at example.com:
      % zsync checkout http://[EMAIL PROTECTED]/some/directory/

   If *user* or *url* are omitted, the values are selected from an
   existing checkout in the current directory, if any.  If there is
   no checkout in the current directory but *url* is given, the
   user will be prompted for *user* interactively.  The only
   information used from the URL are the protocol scheme (HTTP or
   HTTPS), the host and port, and the username.

   The "logout" command removes an authentication token from the
   persistent cache.

ANTHONY BAXTER: A Zope 3 Catalog!

    As part of the Melbourne sprint, the catalog was implemented
    and hooked up to the existing indexes. There's both
    content-space and utility space catalogs. There's a simple
    query interface  provided, and the catalogs participate in the
    ObjectHub. There was also some refactoring of indexes to start
    pulling out common code - there's a bunch more to do on this,


I18n and TAL

    When internationalizing Zope 3 , we ran into some bugs with
    TAL's I18n  support. Thanks to Godefroid and Fred these are
    fixed now and backported into  Zope 2.7.0. After having
    actually worked with the Zope 3 I18n support by  translating
    Zope 3 itself, I am proud to say that Zope 3's I18n is
    superior  to many other systems I have seen. We also fixed up
    the extraction tool to be  much more flexible and to support
    explicit message ids better. Phillips section has more on that.

Python <script> support in TAL

    I finally got around implementing a TAL "script" attribute to
    work. The  support was mainly written for scripters to give
    them a better entry point to  Zope 3. Here an example of what
    you can do:

      <script type="text/server-python">
        print "Hello World!"


     <p tal:script="text/server-python">
       print "Hello World!"

A more elaborate example would be:

      <script type="text/server-python">
        global x
        x = "Hello World!"
      <b tal:content="x" />

    This support is currently only available in "Templated Pages"
    after you activate the hook using the "Inline Code" screen.

TTW Development

    After Sidnei implemented "Mutable Schemas", I started work on
    (and finished) a  schema-based Content Component type for TTW
    development. Coming from the  user's point of view we also
    implemented a local Browser Menu Service, which  allows you to
    create new menus and menu items.

Here is what you can do now in a package:

1. Create a Utility Service.

2. Create a Menu Service

    4. Create a Persistent Schema Utility (this begs to be
       renamed). Call it 'IDocument'. Add some fields.

    5. Create a Content Component Definition. Call it 'Document'.
       Find the IDocument schema and set it to the definitions
       schema. Make security assertions as desired. If you like,
       you can also adjust the menu  entry.

    6. Go to your Content space. There you should see a 'Document'
       object in the list of available Content Objects. As usual,
       click on it to create the object.

    7. Creating custom views is easy too. Go back to the default
       package. Create a  Page Folder. Tell it to provide views for
       'IDocument'. Create a view and  register it with the local
       Browser Menu Service.


    After a long break, I started working on the Developer's
    Cookbook again by  committing the 'SmileyService' into
    'zopeproducts/demo'. The first chapter on  how to write the
    global version of the service is already online; the local
    implementation recipe will follow soon.


    While I made much less progress than anticipated, we made some
    great progress  this week. I finally got the access I need to
    the box (thanks to Matt  Kromer), so that I will be able to get
    the Web Server ready. I also plan to  install the z3-checkins
    product.  Other than that, I got a lot of valuable  usability
    feedback from Fred and Jim about the bug tracker, which I all
    incorporated in the latest checkins. Finally, Jim and I worked
    on a change  password screen for Zope 3, which ended up being a
    major refactoring and will  be checked by Jim soon. It will
    also provide a basis for general user  preferences.

Zope 3 Release Management

    As you may know, I visited Jim in Fredericksburg last week.
    Instead of having a  mini-sprint with lots of coding going on,
    we purely concentrated on the Zope  3 Project Management side
    and writing up Proposals about some of the new  ideas. Overall,
    we created 5 or 6 proposals, several bug tracker entries and  I
    got a good overview of the outstanding tasks.

    Furthermore we discussed the Roadmap in great detail. Here I
    will only state  the summary. For more details in the future,
    you should see


    Summary: There will be a MS4 release that contains all the
    "geddons" in  progress right now. I hope that we will not need
    any more geddons after MS4,  since we will work towards the
    beta. Even though the release date really  depends on the
    community involvement, I think it is unrealistic to expect
    that release before mid-October 2003. From then on everything
    should be  downhill and Zope 3 can become more open to other
    developers as the core API  stabilizes and rough corners are
    smoothened out. The first beta will be  released once the
    fundamental application components are settled. I also hope
    that some major UI work will become visible before the first
    beta. A wild  guess for a release date would be mid-December
    2003. Beta 2 will represents  further work on the UI and
    concentrating on making Zope 3 a good development  environment
    by removing last quirks. Based on the UI work being done, this
    might be the last beta. If, however, UI work does not start
    before Beta 1, we  will have a Beta 3 that concentrates on UI
    polishing. After that we will gear  towards a 1.0 release.

Call for Information Architects and Graphic Designers

    As stated in the section above, a lot of the upcoming progress
    of Zope 3 will  depend on the improvements to the Web user
    interface. Currently no-one feels  responsible about the GUI
    and you certainly do not want the developers doing this work!
    Do you? So please step forward and help us build a great UI.
    You  do not even need to know Zope 3 or Zope in general. If you
    are interested,  send a mail to [EMAIL PROTECTED] and we will
    get you started.


  Please send Zope 3 news, and newsletter suggestions and requests, to
  [EMAIL PROTECTED], with "Zope 3 newsletter" somewhere in the subject
  line. As you can see above, casual and quick news items are
  acceptable and even desirable.


  The central place to find Zope 3 information is currently

  The Zope 3 mailing list is archived and managed at

  The Zope 3 development IRC channel, #zope3-dev at
  irc.openprojects.net is (strictly) for discussion of Zope 3
  development issues.

  Newsletters are occasionally archived at

Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Reply via email to