[Grok-dev] Re: Day #1 of the Grok Sprint
faassen at startifact.com
Tue Mar 18 10:55:04 EDT 2008
Thanks for this report, I was very curious how it was going. How'd your
talk at PyCon go, by the way?
Brandon Craig Rhodes wrote:
[other web frameworks popularity at PyCon]
There's a geographical thing too: there were a couple of dozen people
sprinting on Zope 3-related stuff (Grok, Schooltool, Zope 3) at
EuroPython last year (at a conference with a much smaller attendance),
and 0 TurboGears and 0 Django people sprinting as far as I know. Plone
used to be very visible at EuroPython, but much less so in recent years
(due to it having its own conference, I imagine).
> Anyway, yesterday I and Robert Marianski created "grokcore.component"
> and got it mostly whittled down to a working subset of Grok.
I saw the checkins. Hear me cheer from the distance. I was happy to see
you worked with Robert; I very much enjoyed working with him at the snow
> We have
> not yet tackled what on earth do to with the interfaces.py file (we
> suppose that some sort of inheritance hierarchy will now have to exist
> between the various grokcore interfaces and the main Grok interfaces),
Why can't you import those defined in grokcore.component.interfaces into
> Brad Allen, Reed O'Brien, and Peter Bengtsson all worked on
> documentation, doing excellent work reviewing and improving the main
> Grok tutorial. They also asked some interesting questions - about,
> for example, whether one can really move from Grok into taking full
> advantage of Zope 3 without rewriting an application. I think there
> might be a need for a long tutorial document that takes a basic Grok
> app, then shows how one would pull in the most advanced features of
> Zope 3 without having to rewrite it.
Yes, it's a good question. The answer is "yes", but it is not obvious of
course. One of the problems is that there *is* no "Zope 3" to take
advantage of, there are just a lot of packages that you can take
advantage of. Learning how to use the functionality in such a package is
a different challenge per package (as with any library). There are of
course some commonalities (interfaces, component architecture, etc).
> I'm hoping to finish up my grokcore.component work today (I'll
> probably need help releasing it as an egg if I make it that far), and
> after looking at the very high number of Django people, I'm seeing
> that people who are generally not like me - I chose Grok because the
> underlying framework uses, in my opinion, the most powerful yet
> tractable OO abstractions (adapters, etc).
My hope is that the power will pay off in the long run. I have the
feeling that the base of Zope 3 hasn't been matched by the other
frameworks yet, and that they won't get there in a hurry either (it took
us years in the Zope community).
> But most people want to
> make pretty and useful web apps for customers quickly. And right now,
> our tutorial doesn't show anything pretty. I wonder how hard it would
> be for the tutorial to get the student very quickly to a small web app
> with, say, a date field with a little pull-down calendar, or a text
> selection box that pops up autocompletions dynamically?
Good point. I don't know whether this should belong in our main tutorial
- it will be hard to explain. Perhaps there is room for another tutorial
which is geared at pretty things.
Note that in part our dynamic story may be based on KSS, and its
integration isn't fully baked yet.
More information about the Grok-dev