Hey,
Michael Kerrin wrote:
[snip]
Now into future. I want to split this up into a core Zope3 WebDAV
implementation, which will handle registering the different WebDAV methods,
their implementation, declaring properties, exception handing which I could
call z3c.webdav. This module / egg on it own will be pretty useless, as it
doesn't know about any of the content or services in Zope3. Then I want for
each content type and services in Zope its own egg so to speak, for example
z3c.webdav.zopeappfolder, z3c.webdav.zopeappfile, z3c.webdav.zopefile,
z3c.webdav.zopelocking. A lot of these extra eggs will be small and easy to
write, and as more content types are supported by Zope3 I would like more
webdav modules to be written for them.
You can almost do this, but now quite, as z3c.webdav is not a namespace
package in this plan (see below).
An other two options I can think of, instead of the naming convention above:
1. create a webdav namespace, webdaz (WebDAv for Zope), which would contain
webdaz.core, webdaz.zopefile, webdaz.zopelocking etc
It's nice that it's more flat. I think it's too easy to mistype 'webdaz'
for 'webdav', so -1 on this one from me. zwebdav would in fact have my
preference if you want to go this way.
2. Name the core webdav implementation z3c.webdav and then create eggs that
are named like zope.file.webdav (for zope.file), zope.app.file.webdav,
z3c.extfile.webdav, zope.locking.webdav etc. but which are separate from the
underlying module.
This won't work, as these packages themselves are not a namespace
package. As far as I'm aware, you can only create independently
installable eggs for subpackages of namespace packages (i.e. packages
without any code).
Does any one have any experience with this type of problem or does any one
of a preference to which one they like best. Or is there other options that I
have missed that is worth considering, in order for me to move this forward.
Another option is to create a zwebdav or z3c.webdav package, and then
put a special namespace package in there meant for the extensions:
zwebdav - core zope 3 webdav support
zwebdav.ext - pure namespace package
zwebdav.ext.zopefile, zwebdav.ext.zopelocking, etc.
ToscaWidgets is an example of a package that does this. It has a
toscawidgets core, and then extensions are shipped as subpackages of the
toscawidgets.widgets namespace package.
Yet another option would be to have a core package, and then extension
package in another namespace altogether:
zwebdav - core webdav support
zwebdavext.zopelocking, zwebdavext.zopefile - extensions
Grok does this. It has 'grok' as the core, and extensions are shipped as
'megrok.five' and so on.
Incidentally, we are thinking about splitting up grok into multiple
packages too. A difference with what you're talking about is that the
grok package will remain the same, but will start importing some of what
it needs from other packages which can be used independently.
For that, we intend to do something like this:
grok - package end users see, and depends on
groklib (name still being pondered) - core grokker implementation
grokcore.component - basic component architecture support for grok
grokcore.formlib - formlib support for grok
etc. The grokcore packages would have dependencies on groklib as well as
various Zope 3 packages (such as zope.component). Some of them may also
build on each other. groklib wouldn't have any dependencies (or almost
none). grok would depend on everything. Not very relevant to your
problem, but thought I'd show yet another example of package
organization. :)
Regards,
Martijn
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
