On Thursday 03 February 2005 03:23, Chris Withers wrote:
> Stephan Richter wrote:
> > Yes, that is true for packages in zope.
> So, if I understand you correctly, I can use all packages, except those
> in zope.app, on their own, without having to rely on anything else, right?
> > However, zope.app was designed as the
> > application server and has thus many dependencies among the packages in
> > zope.app.
> Hmmm, that's a shame, there's a lot of things in
> http://svn.zope.org/Zope3/trunk/src/zope/app/ that look, by name, like I
> might want to use them without using other stuff:
An abstraction of this package could be probably moved to zope.
Some of the package could be surely moved to zope, but caches are local
utilities and as such they depend on zope.app.
I think this package is totally useless outside zope.app, since authentication
is bound to the publisher framework, unless of course your own application
knows how to use the IAuthentication interface.
The reason the API doc tool is so useful is because it is totally custom to
Zope 3's app server. It makes many, many assumptions on how the registration
directives create factories for views and other components (for example).
Except for the some of the interface viewer and the class browser nothing
will apply to another application.
> That said, is it just me or do
> http://svn.zope.org/Zope3/trunk/src/zope/app/ and
The reason there are so many packages is that we wanted to factor out as much
reusable code as possible into a package. The list is too long to write a
comment for each package.
Here is the list from src/zope:
app/ - Zope application server.
hookable/ - A small package that allows functions to be hookable, i.e.
graceful monkey patching.
pagetemplate/ - Zope-independent page template code.
cachedescriptors/ - I have no clue what this does.
i18n/ - I18n and Locale implementation.
proxy/ - Basic object-proxy implementation. Similar to context wrappers.
component/ - The component architecture.
i18nmessageid/ - Message Ids have been separated from i18n, so that some of
the zope packages do not depend on i18n, but still have I18n support.
configuration/ - ZCML and general configuration implementation.
importtool/ - library for the importtool script that determines unused
publisher/ - Basic Publisher framework (like in Zope 2)
dependencytool/ - Library for a tool that checks the dependencies of a
index/ - Zope-independent index implementation; contains several indices.
deprecation/ - Some code to ease marking deprecated code.
schema/ - Schema package.
tal/ - TAL implementation (equiv. to Zope 2)
documenttemplate/ - DTML implementation (equiv. to Zope 2)
security/ - Basic security implementation.
tales/ - TALES implementation (equiv. to Zope 2)
event/ - Redicoulisly simple event implementation (should be in PYthon proper,
interface/ - Interface package.
server/ - The new server code, equiv. to medusa in Zope 2
testing/ - Support for various testing techniques, such as doc file tester.
exceptions/ - Standard Zope exceptions. We could probably move those to other
modulealias/ - Allows one to register a module under a different path. Good
structuredtext/ - Class STX implementation.
thread/ - Threading support for the servers.
fssync/ - FS syncing library. I do not know the state of this.
xmlpickle/ - Creates Pickles in XML format, equyiv. to Zope 2 I think.
> look like there's a LOT of stuff in them?
I don't think so. A lot of the packages are very small.
> How much of it is "real" and how much of it is cruft?
There is not much cruft. We try to clean up regularly. We just decide not to
distribute the packages we do not feel comfortable with yet. Please name the
packages that you think are cruft...
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -