[Zope-dev] Zope 3 Newsletter: Issue 10

Gary Poster gary at zope.com
Fri Sep 5 10:46:52 EDT 2003


WELCOME TO THE ZOPE 3 NEWSLETTER: ISSUE 10 (5 SEPTEMBER 2003)

   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.

GLOSSARY FOR THE UNINITIATED

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

NEWS SNIPPETS:

  - 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!

PHILIPP VON WEITERSHAUSEN:

   ZCMLGeddon

     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.

   i18n

     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
     imports.

     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://username@example.com/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,
     though.

STEPHAN RICHTER:

   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!"
       </script>

     and

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

     A more elaborate example would be:

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

     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.

   Documentation

     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.

   zope3.org

     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

 
http://www.zope3.org:8080/++skin++tracker/tracker/1/%40%40dependencies.html

     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 zope3-dev at zope.org and we will
     get you started.

CONTRIBUTING

   Please send Zope 3 news, and newsletter suggestions and requests, to
   gary at zope.com, with "Zope 3 newsletter" somewhere in the subject
   line. As you can see above, casual and quick news items are
   acceptable and even desirable.

MORE INFORMATION ON ZOPE 3

   The central place to find Zope 3 information is currently
   http://dev.zope.org/Zope3

   The Zope 3 mailing list is archived and managed at
   http://lists.zope.org/mailman/listinfo/zope3-dev

   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
   http://dev.zope.org/Zope3/Zope3Newsletter





More information about the Zope-Dev mailing list