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