[BlueBream] working with Grok
mbaiju at zeomega.com
Fri Jan 22 20:52:01 EST 2010
On Fri, Jan 22, 2010 at 7:50 PM, Martijn Faassen <faassen at startifact.com> wrote:
> Hi there,
> On Fri, Jan 22, 2010 at 2:29 AM, Baiju M <mbaiju at zeomega.com> wrote:
>> On Fri, Jan 22, 2010 at 3:45 AM, Martijn Faassen <faassen at startifact.com> wrote:
>>> I just subscribed to the BlueBream list as I think Grok has a lot in
>>> common with BlueBream.
>> Welcome to BlueBream's list :)
>>> Very glad to see this effort, and hopefully we
>>> can find many ways to share code, resources and work.
>> We have some fundamental difference in handling configuration
>> (declarative vs imperative) But, I believe we can work together
>> as Grok & BlueBream use ZTK.
> Both Grok's martian and ZCML are in my opinion declarative methods of
> configuration. The underlying effect is a zope.configuration
> configuration action in both cases. Grok just gets the configuration
> from another place.
> It would be nice to add "imperative" configuration APIs to the ZTK. In
> fact the API goes beyond configuration. You'd have stuff like:
> register_view/unregister view
> i.e. besides registration there should also be an API to look up the object.
> This would be a native API for the fundamental concepts in the ZTK
> instead of only low-level component registrations.
> We could then build both the ZCML directive implementation as well as
> Grok's configuration system on top of this new imperative API. We
> could also modify things like the publisher to use the new lookup APIs
> (in fact this implies the view lookup API belongs in the publisher).
> * it's a lot of work, requiring a lot of careful thought. It should
> also go into the right place; we don't want a mega-package for this
> API I think.
> * we've had attempts at this in the past which failed (zapi, ztapi).
> These didn't add much while gratuitously making configuration harder.
> We've had to struggle to remove them.
> It's possible this would become easier if we rewrote the whole
> publishing infrastructure entirely, replacing the old one. That's
> risky and difficult in other ways, of course. :)
Thanks for sharing your thoughts.
More information about the bluebream