Hey Jeff,

Jeff Shell wrote:
On 3/16/06, Martijn Faassen <[EMAIL PROTECTED]> wrote:
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 different story.

Frankly it sucks that you can't use my TTW UI for user management. Note that it's not just a UI. I'm talking about UI plus implementation, catalog install, groups support, hooks into authentication systems, etc. The point is that ideally I'd like to be able to reuse all that stuff as one bundle.

Customization is fine, but I want customization, not:

* everybody writing their own.

* everybody having to copy large amounts of code or templates and modifying it in order to make it do what they like.

Anyway, as a lower point of ambition, I want to at least be able to
extract that code from the Document Library and use it in other
applications I write. Whether you will find it useful is besides the point - it's not the be and end-all, but it's certainly better than having no way to do it at all.

Note that this is not a hypothetical scenario. I *did* extract the code for user management from the Document Library so that it could be used in another Zope 3 project, not even one of my own. I was not happy with the amount of work it entailed, and now two codebases will use diverging copies of that code. I'm looking for patterns to prevent this from happening.

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.

Whatever the common codebase is going to be, it better offer some patterns for how to install bundles of functionality. Perhaps this is a coding problem, perhaps it's a documentation problem, it's probably all combined, but it'd better be centrally communicated somehow. I do not want a situation where my app and your app just can't exchange code as they both built their own frameworks for installing extensions. Zope 3 is supposed to be on a mission to make this happen less.

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

Did I talk about having it be in Python or not? Let's not have that discussion here too... I don't care much where it is right now. I'm just saying that I want to be able to specify ordering in a *declarative* way. I don't want it to be in a bunch of if statements if you mean that, as that'd sounds rather brittle.

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 whole thing.

As long as it's declarative and clearly documented and everybody starts using it and it actually allows me to share my user management code, I'm fine with that too.:)


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

Reply via email to