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