[Grok-dev] can we really do grokcore.component?

[Brandon Craig Rhodes]

The few hours that I spent yesterday delving through Grok's code to
understand what would need to be pulled out to make grokcore.component
were very informative, but I'm now wondering if they can produce
anything useful.  You see, I imagine writing applications that aren't
web-based, but in which the Zope adapter registry would be a very
useful design pattern.  And instead of writing an adapter and then
having to say:

    providesAdapter(MyAdapter)

for each one of them, it sure would be fun to just write them as
inheriting from grok.Adapter and have them auto-discovered.

Therefore, I imagined something along the lines of:

    from grokcore.component import Adapter

    class MyAdapter(Adapter):
        grok.adapts(MyObject)
        grok.provides(IMyInterface)
        ...

You can, of course, immediately see the problem.  I want to use the
same "grok.this()", "grok.that()" format for grokcore.component
directives that I use in Grok itself, so that code is easy to move
between the real Grok framework and grokcore.component applications.
But, of course, as a matter of pure syntax, the import statement above
simply doesn't create a "grok" object off of which the "adapts" and
"provides" directives can hang.

And this is a serious issue, if "grok" itself is to use the
"grokcore.component" pieces, because the directive has to "know" its
own name.  Check out some of the code in "directive.py" and you'll
see things like this:

    title = SingleTextDirective('grok.title', ClassDirectiveContext())

If we define directives in "grokcore.component" that we then use in
"grok" itself, they'll either advertise the wrong name when used from
one place or the other.  Since presumably we would prefer things to
work best for users of the full framework in this case, people using
"grokcore.component" would see the wrong name.

There are several approaches possible from here:

  - People using "grokcore.component" can just put up with having to
    say things like "grokcore.component.adapt()" and then having to
    rewrite this to "grok.adapt()" if they move the same code into a
    web framework later.

  - The "grok" module can become a magic module that gets assembled
    out of whatever "grokcore" pieces you have available.  That would
    be my favorite approach - so that whatever "grokcore" pieces you
    depended on would appear under "grok.*".  The web framework would
    then simply pull in all of grokcore.

  - The directives in "grokcore.component" can be an entirely separate
    set the directives from the ones in "grok", but do the same things.

  - We could decide that "grokcore.component" isn't going to be very
    possible after all, and I could turn my attention to making some
    sexy Grok tutorials that create really capable and flashy
    KSS-empowered Web-2.0 applications, stopping along the way to
    write in whatever capabilities Grok needs to achieve the
    flashiness. :-)

Give me your ideas, even quick ones, so that I can use the remaining
time of the sprint as best as possible.  Thanks!

-- 
Brandon Craig Rhodes   brandon at rhodesmill.org   http://rhodesmill.org/brandon