On 3/16/06, Martijn Faassen <[EMAIL PROTECTED]> wrote:
> Jeff Shell wrote:
> > 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.
Then you write a third batch of Python code that further tweaks,
removes, or adds to what the combination of the first two do.
This is only kindof setup. ZCML, again, is registering very very very
core things. Like in Formulator's initialization code: set up the
registries, register the core fields. That doesn't stamp out a form.
When I build a Knowledge Base site, I'm going to need X and Y and Z in
order to use it. I'm going to need each of those to be configured
according to how I designed the knowledge base. Python gives me the
best option for automating that, because it is (in a way) a kind of
business logic: I'm indexing on these fields, I'm building Extent
catalogs on these, uh, extents, I'm setting up groups and roles for
user management according to these requirements.
> 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 don't want your TTW UI for user management. No offense to your TTW
UI for user management, but the chances of it meeting my requirements
for style, presentation, ease of use, look and feel are not high. If
you have tools that make it pretty easy, I'd probably love to use
them. But I'm going to be customizing it to my application anyways.
Now - this is for applications whose user management may be turned
over to the customer, or is expected to run within the user interface
of my custom application. If I were using a more generic data
management interface for administration (ZMI, etc), it might be a
> > 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.
Maybe. But I don't even know what the common codebase is going to be
or wants to be these days. This is also a chance for someone to offer
a "here today" alternative for others to install and use.
> [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.
Why not keep a lot of that declaration in Python? It has amazing conditionals.
> > 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).
That may be workable. But I'd also be happy with using just one
directive (preferably adapter, subscriber, or utility) that would
point to a single object that would do the complicated stuff for the
Zope3-dev mailing list