Hey Jeff,
Jeff Shell wrote:
On 3/16/06, Martijn Faassen <[EMAIL PROTECTED]> wrote:
[snip]
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.
[snip]
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.
[snip]
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.
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.
[snip]
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.:)
Regards,
Martijn
_______________________________________________
Zope3-dev mailing list
[email protected]
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
