[Grok-dev] Re: Teach me Grok

[David Bain]

+1
It think this post should be reworked for the evaluation section.

On Thu, Apr 10, 2008 at 9:08 AM, Tim Knapp <duffyd at kokorice.org> wrote:

> 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
>
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> http://mail.zope.org/mailman/listinfo/grok-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.zope.org/pipermail/grok-dev/attachments/20080410/6c956e27/attachment-0001.htm