[Zope3-dev] Re: Coarse-grained reuse.

[Martijn Faassen]

Hey Jeff,

Jeff Shell wrote:
> On 3/16/06, Martijn Faassen <faassen at infrae.com> 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