Jeff Shell wrote:
On 3/15/06, Martijn Faassen <[EMAIL PROTECTED]> wrote:

Jim Fulton wrote:

- We don't have a good way for installing collections of local
components that work together.  For our projects, we've used the
generation machinery to automate this, but that only works if you
want to install things in the root folder.

Right. So far what we've done is some setup code to:

* create utilities in the application's site object

* create indexes in the catalog we just set up.

* create some content objects that come with the application into the
site object (typically folder-like things that will contain the actual
content the user creates)

Especially for the first two cases using custom Python code feels wrong.
It'd be better if there was some framework this custom Python code could
be registered with. I'm not thinking about the registration stack stuff,
but at least some way to register "Hey, this code wants to install stuff
into a site" somewhere, so that in my application I can use that. What
it's doing is a bit like a factory, but it's different in that:


I think I understand what you're saying. I run this pattern a lot
myself. To date, I've used the event handler approach to catch when my
site is added. But also, to date, I've stuffed a lot of the setup code
into a single function called by the event handler.

I don't think there's anything wrong with "custom Python" code to set
this up. It's programmatic, isn't it? A lot of it may be repetitive,
and if that's the case, functions/methods can help. Are we all just so
used to writing big long blocks of code in Zope 2 Python Scripts that
we've forgotten we can do this?

Writing Python code for setup is very handy, but we've also seen where it went wrong in Zope 2. Writing Python code for setup therefore worries me. What's the Zope 3 idea on this? It used to be simple: we had ZCML for such things. But when I started using Zope 3 ZCML turned out to be insufficient from the start for this activity, so I used Python code (with an event hooked up to the site add event, too). And now, ZCML is not going to be used for some of this anymore, so I become less certain.

Where I think "just using Python code" starts going wrong (potentially) is when I want to combine my setup Python code with your setup Python code to build a larger application.

I'd like there to be common patterns so there's at least a reasonable chance that you can plug my TTW UI for user management into your application without having to rewrite large parts of either. I'd also like this pattern to be there when I'm *writing* my larger application, so I say, 'okay, this is all for TTW user management' then, and then more easily extract it later.

I'm trying to abstract some common Bottlerocket patterns out into new
base framework/library for my company to use, and this is actually one
of them. I was trying to come up with something last night for just
this issue. Basically, I thought of writing a couple of interfaces
that would do something *like* zope.app.generations, but instead of
being a 'database opened' event response, used to automatically patch
persistent data with the expectations of code, these things would work
on a 'site added' event. What I didn't spend any time thinking about
was whether to have future upgrades go through this tool, or through
generations.

This may be in the direction of a solution. I haven't studied generations in detail, myself. Anyway, any such solution needs to be in the common codebase, otherwise we're going to end up with a lot of custom ones.

[snip design ideas]

* Using an adapter to bind the configurator to the site allows the
  'framework' to handle when and how the configuration gets run for
  a particular site / added object, but doesn't worry about what it
  does.
* Use the wonders of object oriented technology to provide a base
  class with helpful methods for the common configuration chores.
* Use this same wonder to allow common sites to share common tasks
  for establishing local utilities.
* Still have the power to be as programmatic as needed, which can
  ensure that the utilities are established in a proper order and
  deal with specific situations regarding their establishment. Or
  just to handle dealing with very repetitive situations in an
  easier fashion.

I think ordering may become important eventually. I.e. I can only install my Foo thing into a site if Baz is already installed. I'd think I'd like to be able to express such ordering in some declarative way.

Maybe something like that is what Jim's talking about in regards to assemblies?

ZCML really can't handle this. Not unless the ZCML in question was
basically a pointer to a callable object, at which point you've got an
event handler all over again. I'm looking at my code to set up the
authentication utility for some of our sites. Very specific rules
about what plugins are needed (users, groups, http credentials) and
things in those plugins (default groups). There's no way I'd want to
automate that in anything BUT Python. (Plus, in its current form, this
code can also be used by a view that responds to there being no auth
system setup).

I agree that just using ZCML obviously won't cut it. But perhaps some ZCML can at least help organizing the whole (pointing to the Python code to do the complicated stuff for each bit).

Regards,

Martijn

_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to