[Grok-dev] can we really do grokcore.component?
Brandon Craig Rhodes
brandon at rhodesmill.org
Tue Mar 18 10:34:52 EDT 2008
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:
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
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
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
More information about the Grok-dev