[Grok-dev] Re: Teach me Grok

[Tim Knapp]

On Thu, 2008-04-10 at 15:21 +0200, Sebastian Ware wrote:
> couldn't this post be added to the "evaluate" section of the website?

+1 Great post Martijn!

-Tim

> 
> Mvh Sebastian
> 
> 10 apr 2008 kl. 15.06 skrev Martijn Faassen:
> 
> > Hey Johathan,
> >
> > Welcome!
> >
> > Jonathan Ellis wrote:
> >> Okay, that's a big subject. :)  Let me narrow it down to something  
> >> hopefully more manageable:
> >> * Grok offers a lot of building blocks for your web application. *
> >> Grok is informed by a lot of hard-earned wisdom.
> >> What are some specifics?  What does Grok give me that, say, django  
> >> does not?
> >
> > Big question still! Grok is an integrated megaframework. That is, it
> > features replaceable best-of-breed components (megaframework) while
> > still aims to give you an integrated feel (the parts tend to follow
> > style guidelines and make use of the component architecture).
> >
> > On to your question on what Grok gives you that Django doesn't. I'm  
> > not
> > sure whether Django can add a view to a content object defined in an
> > altogether different package. Grok is built around patterns that let  
> > you
> > do this - the component architecture. Extensibility and evolvability
> > through views and adapters and event handlers. In longer-term or  
> > larger
> > applications such a general way to extend and evolve and application
> > becomes quite important.
> >
> > Concerning components, I believe we have a lot to pick from. We can
> > still do a lot better in presenting the components that are  
> > available in
> > the Zope 3 world, and I don't promise that all these components are
> > equally mature, equally integrated in Grok (there's no need for this
> > except to make life easier, though), or that they are easy to adopt,  
> > but
> > I'll give you a grab bag list of some of the things here:
> >
> > * manage part-of-page views, per context object, per view, per area on
> > page, per skin (viewlets)
> >
> > * manage vocabularies (for drop-down lists, say)
> >
> > * display HTML tables
> >
> > * auto-generate forms from schemas, with a wide selection of widgets
> >
> > * integrate with ORMs (Storm, SQLAlchemy)
> >
> > * authentication (basic auth, session auth, pluggable infrastructure  
> > on
> > where to get users, etc)
> >
> > * authorization: users, groups, per-user/group per-object permissions
> > and roles
> >
> > * REST, JSON, XMLRPC, WebDAV
> >
> > * i18n, localization of things like date/time, country names, etc
> >
> > * locking and freezing objects
> >
> > * sending, queuing mail
> >
> > * workflow
> >
> > * XML-export and import of schema-driven content
> >
> > * making objects appear in multiple places at once in the traversal
> > hierarchy, including generating correct urls for them and the urls of
> > sub-objects (zc.shortcut)
> >
> > * versioning objects in a version control system (zc.vault)
> >
> > * object indexing and search (grok.Indexes makes this easier)
> >
> > * lucene, xapian indexing integration
> >
> > * relation indexing (zc.relation)
> >
> > * caching, support for protocols like ICP (zc.icp)
> >
> > * unit testing, doc testing, fake browser doc testing, driving  
> > selenium
> > from browser doc testing, driving a real browser from browser doc  
> > testing
> >
> > These components are are typically packaged as eggs, are doctested
> > (frequently extensively so), and define explicit APIs (using
> > interfaces). They use the component architecture for extensibility
> > points. They share a uniform extensibility mechanism.
> >
> > What we're trying to do with Grok is to mine this pool of components  
> > to
> > try to make their initial use easier. That doesn't mean that you can't
> > use them out of the box anyway without efforts on our part - Zope 3  
> > and Grok are compatible. But with Grok, we consider the existence of  
> > a component the half-way-point; now that it's there, we should make  
> > it *easy*.
> >
> >> My impression is that in the past couple years the rest of the world
> >> has rapidly caught up to zope3; is that incorrect?
> >
> > I think it's a mix. On the one hand, the rest of the world has been
> > doing all sorts of things (like MVC and automatic form generation)  
> > that
> > Zope 3 has been doing for a while, and also of course things that  
> > Zope 3
> > didn't do yet (ORM is an example, though we had early pioneering in  
> > that
> > area with things like ZPatterns, back in '00 or so).
> >
> > On the other hand, the rest of the world doesn't use object  
> > databases (which some people still see as "future magic", though it  
> > obviously also has drawbacks), or advanced permission-based  
> > security, and is behind on the curve in catching up on extensible,  
> > buildout systems. I also have a suspicion (that I cannot prove) that  
> > the use of an object database makes the combination of content- 
> > components and configuration-components into new higher-level  
> > frameworks and applications more easy than is perhaps the case with  
> > relational database backed system.
> >
> > I think Zope's strongest area is the component architecture, which
> > provides a uniform system for extensibility. We've seen a vast  
> > explosion
> > of components over the last few years - evidence that the
> > component-driven approach is working. You can look at the index page  
> > of
> > svn.zope.org to get an impression (and there are also quite a few
> > components maintained elsewhere, such as in the Plone collective).
> >
> > Again though, this is a sucky presentation of what's there, and of
> > course some of these components will be better maintained and more
> > useful than others.
> >
> >> Question 2, to people who came to zope via grok instead of the  
> >> other way around: how quickly did you find you had to learn about  
> >> zope3
> >> gory details?  I.e., how leaky of an abstraction layer is Grok?
> >
> > Grok isn't an abstraction layer over Zope 3. It's therefore very  
> > leaky.
> > :) Technically, it's an alternative configuration layer, replacing  
> > ZCML.
> > It replaces ZCML pretty effectively, and I'd say there's not much that
> > leaks there - we only use ZCML to trigger the whole grokking process,
> > typically.
> >
> > Philosophically, Grok is an approach towards Zope 3 that makes it more
> > agile in use and more easy to learn. We try to reuse existing  
> > components, putting them together for 90% of the use cases, where
> > straight Zope 3 just offers a giant roll-your-own toolbox. We add  
> > convenience features. We try to create simple documentation. When I  
> > read about the TurboGears 2 effort, I figured it was trying to do  
> > with Pylons what Grok is trying to do with Zope 3. This is a big  
> > continuing effort.
> >
> > If you are going to do hard stuff, you are going to have to try to
> > understand the various Zope 3 components you want to do hard stuff  
> > with. Gory details galore there. I believe that this is inescapable.  
> > What we *do* try is push the boundaries of what is actually hard.  
> > Zope 3 components do this by offering new features and building  
> > abstraction layers. With Grok we add easier assembly, and pre- 
> > assembly.
> >
> > Regards,
> >
> > Martijn
> >
> > _______________________________________________
> > Grok-dev mailing list
> > Grok-dev at zope.org
> > http://mail.zope.org/mailman/listinfo/grok-dev
> 
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> http://mail.zope.org/mailman/listinfo/grok-dev