Teach me Grok

[Jonathan Ellis-5]

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?  My impression is that in the past couple years the rest of
the world has rapidly caught up to zope3; is that incorrect?

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?

thanks,

-Jonathan
_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

[Sebastian Ware]

I am no hard core developer, but I will give you my view anyway.

10 apr 2008 kl. 02.01 skrev Jonathan Ellis:

> 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?

Zodb is excellent for storing randomly and semi-structured data. The  
value of this is easily underestimated if you are used to only working  
with RDBs.

The plugability of the component architecture is really solid. This  
touches every corner of the framework.

All the components of the framework are well documented on a code  
level. If you don't mind reading the doc tests, you'll be jocking  
cutting edge stuff as well as those parts that are covered by higher  
level documentation. (Even I manage to read that stuff at times...)

> My impression is that in the past couple years the rest of
> the world has rapidly caught up to zope3; is that incorrect?

I would say it is the other way around. Zope 3 has (through Grok and  
other improvements) caught up with the rest of the world in terms of  
usability.

I doubt any framework will catch up with Zope 3 by incremental  
improvements. It requires a total rewrite (in the same way as Zope 3  
is a rewrite of Zope 2). Zope 3 is a component based framework from  
the origin, the others are not.

Where Grok/Zope3 might be lacking is in the get-your-admin-interface-
for-free department and out-of-the-box UI-goodies. The prior is not a  
biggie for me, but the latter is a bit of a bummer. UI-elements will  
tend to be unpolished = you have to polish them yourself.

Grok/Zope3 is also a different mindset. Once you nail it, the code is  
compact and efficient, but it can be a mind twister.

>
>
> 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?
>

I learnt Grok first (coming from Zope 2 TTW-development...). My  
impression is that the abstraction layer is very solid. If you look at  
the Grok code it is often quite trivial but the effects in terms of  
increased usability are great.

Another factor is that you could at any time refactor the application  
to be a vanilla Zope 3 app, although the general consensus on this  
list is that you really shouldn't have to.

mvh Sebastian
_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

[Martijn Faassen-2]

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@...
http://mail.zope.org/mailman/listinfo/grok-dev

[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@...
> http://mail.zope.org/mailman/listinfo/grok-dev

_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

[duffyd]

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@...
> > http://mail.zope.org/mailman/listinfo/grok-dev
>
> _______________________________________________
> Grok-dev mailing list
> Grok-dev@...
> http://mail.zope.org/mailman/listinfo/grok-dev

_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

[David Bain-5]

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

On Thu, Apr 10, 2008 at 9:08 AM, Tim Knapp <duffyd@...> 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@...
> > http://mail.zope.org/mailman/listinfo/grok-dev
>
> _______________________________________________
> Grok-dev mailing list
> Grok-dev@...
> http://mail.zope.org/mailman/listinfo/grok-dev

_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

[Godefroid Chapelle]

Martijn Faassen wrote:

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

* ajax (kss.core - also provided with Plone 3)

Hopefully, when leaving Grokkerdam, megrok.kss will be in such a state
that Martijn wont forget to mention it ;-)


--
Godefroid Chapelle (aka __gotcha) http://bubblenet.be

_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

[Martijn Faassen-2]

Sebastian Ware wrote:
> couldn't this post be added to the "evaluate" section of the website?

Yeah, I should do this. It'll take a while to clean up though. Please
someone remind me in the future - or make a launchpad issue, or start
the work yourself, or something. :)

Regards,

Martijn

_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev