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 thata) 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://[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,
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 seehttp://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 [EMAIL PROTECTED] and we will
get you started.CONTRIBUTING
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.
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
_______________________________________________
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
