[Grok-dev] Re: Day #1 of the Grok Sprint

[Martijn Faassen]

Hey,

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 
sprint.

> 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 
grok.interfaces?

[snip]
> 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.

Regards,

Martijn