[Grok-dev] Re: Teach me Grok

[Sebastian Ware]

couldn't this post be added to the "evaluate" section of the website?

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