[Zope-dev] refactoring site functionality

[Martijn Faassen]

Chris McDonough wrote:
> On 6/4/09 11:59 AM, Martijn Faassen wrote:
[snip]
>> I don't think it's complicated. It's nice to install an object somewhere
>> that stores data and has a UI and also be able to register it as a local
>> utility. If you were to have mutable global configuration, you'd need
>> some way to expose it to the UI and content-space too.
> 
> This is true.  OTOH, I've never really been keen on the idea that the CA API 
> should be bent around the idea that you're going to often want to find a 
> persistent registry.  It seems just as reasonable to:
> 
> - put a persistent object someplace (with its own UI) that isn't registered as
>    a CA utility.
> 
> - find it via the location API when you need it in your code.

By location API, you mean something like mycurrentapp()['foo']['bar']?

> - *Pass* it to global utilities (or adapters) when you need to vary behavior
>    based on location.

Doesn't this make you have to scatter a lot of location-getting and 
context-passing code throughout your codebase? I guess it depends on how 
your codebase is factored.

But say you have a utility that sends email, and can be configured with 
the email address to send it to somewhere in a config screen, you could 
have 10 places in your code that need to get the configured email 
address and then pass it to the utility. Now that's probably easy enough 
to encapsulate in a function, but:

* but if you have your configuration right there in the local utility it 
comes pre-encapsulated. Now you got two bits, one that knows how to send 
email and one that is being configured. This separation into bits may be 
right in some cases, but it seems overkill in many.

* you're going to have to pass your current application context in each 
time you want to send email. That's avoided with a utility lookup (as 
this is implicit).

So, I'm having trouble seeing the benefits to this alternative approach, 
could you explain?

Regards,

Martijn