This is awesome. There is now a published book about Grok!
Thu Feb 11 2010 12:04 ME GROK BOOK:
Zope
This is awesome. There is now a published book about Grok!
Thu Feb 11 2010 12:04 ME GROK BOOK:
This week a bunch of us (myself, Christian Theune, Wolfgang Schnerring, Brandon Rhodes, Jan-Wijbrand Kolman and Sylvain Viollon) have been sprinting in my house at the "Grok Cave sprint". We've been working on cleaning up Zope 3's dependency structure, which in places is very hairy. This meant that you could often pull in one fairly innocent looking Zope 3 package and as a result pull in almost all of them. This makes it difficult to reuse packages and upgrade code. Loosely coupled code and all that.
(6) Thu Jan 29 2009 21:18 Cleaning up Zope 3's dependencies:
I've been following with interest a number of posts that talk about creating a simple REST-based web application that persists the number of plays various songs have had. Here's the history:
(6) Sat Jan 10 2009 14:29 Grok's songlist application:
[More]
The ZODB is a powerful object database for Python objects. It's very mature - it's been around for more than a decade. It is transactional, has advanced features like clustering (ZEO), blob support, and yes, it can be used independently from Zope. Zope 2, Zope 3 and Grok all use the ZODB as its default data storage, and it's seen a lot of battle testing.
(5) Fri Jun 20 2008 15:12 A misconception about the ZODB:
I continue yesterday's status update with some more topics. Lots of stuff is going on in the Grok world!
Tue Jun 03 2008 14:19 Grok Status Update Part 2:
My friend Lennart's blog entry Zope 3 rocks and rolls is fascinating, not least as it has one of the most misleading titles I've ever seen. Reading that title, you'd be surprised Lennart talks mostly about a series of difficulties encountered with Zope 3 and decision to switch to Plone for a project instead.
(6) Sat Apr 19 2008 16:07 Grok takes Zope 3 the rest of the way:
Grok needs a great relational database integration story. Grok already has a great database story: by default, we use an object database: the ZODB. The ZODB is great as you can just store normal Python objects. You can persist complicated nested structures easily. But this entry isn't about the ZODB. Relational databases are also great. You can query tables every which way very easily. You can manage your data in a RDMS, a familiar system for many, and integrate with existing RDMS that already exist in many places.
(15) Tue Apr 08 2008 11:27 SQLAlchemy with Grok:
This blog entry on picking web frameworks is quite interesting. It doesn't give a lot of detail, and it acknowledges this, but it does show the struggles someone goes through trying to pick the right framework for the job (and one that fits his mind). Wyatt Baldwin considered, among other frameworks, Zope, and had the following to say:
(11) Sat Apr 05 2008 15:57 No, you are smart enough for Zope:
I was having a hard time with the Pylons docs, and so I ended
screwing around with Grok (which actually looks fairly interesting)
and even took a look at the Zope 3 site. I’m sure Zope is really
awesome or whatever, but it might as well suck. Every time I look at
that site, I’m just like “WTF! This shit has been around for like
five years!” Anyway, I might just not be smart enough for Zope.
[More]
Some years ago, in 2004, I came up with the following quote to promote the Five project, which was the first step towards the inclusion of Zope 3 technologies in Zope 2. Zope 3 technologies are now heavily used in Zope 2 projects, and Zope 3 code has been part of Zope 2 for a while now, but back then we were just at the start of this process. The quote itself was creatively adapted from the first season intro of Babylon 5, a 90s scifi TV show: Zope 3, and Grok in the last few months have been switching to a brave new eggified world of installation. The idea is that you compose your Zope application from a large amount of smaller packages, each providing their own components. I've sometimes described this Zope as an integrated megaframework. Zope is an integrated framework where packages follow common coding conventions, and the component architecture defines a way for packages to work with each other. Grok tries to step up by aiming for an integrated feel for developers. At the same time, Zope is a megaframework, allowing you to swap in best of breed components as they come available. Don't like zope.formlib? Swap in z3c.form for your form generation needs instead. Zope is a web framework that comes equipped with powerful, apparently
secret, features. Some of the things Zope has had for literally years
other web frameworks are only evolving today. And in other cases, Zope
comes equipped with features that other web framework communities are
currently only dreaming about. Yesterday I returned from "Grok Sprint Zwei", the second grok sprint, hosted by Philipp von Weitershausen in Dresden, Germany (and partially at Gocept for the warming up). Grok is a project to make Zope 3 safe, easy and fun for cavemen and other hominids like ourselves. Zope 3 of course is the powerful and flexible framework for the construction of web applications. See here for my initial introduction of the Zope Grok project. I will use this blog entry to talk talk a bit about my holiday in Germany a few weeks ago. I went to a mini sprint at Gocept, in Halle. I had a great time! (yes, I am a geek) This sprint showed that good sprints aren't necessarily the ones with many people participating; we just had 4 sprinters (and less much of the time), and this was one of the most productive sprints I've been at for years. I left the sprint energized and excited. Thanks to Gocept for organizing this, it was awesome! Jean-Marc Orliaguet is rewriting CPSSkins again, this time in Java, as Nuxeo is switching their CPS platform from Python and Zope to the Java language . The reasons for this switch are detailed in the FAQ. I'm not going to debate them here. In my last article I talked about the problems that occur on the
borderland between content and software, but didn't give enough
examples. I figured I'd add some more text about this very important
topic. Paul Everitt writes: Last summer the Five project pulled Zope 3's i18n architecture into the Zope 2 world, thanks to work done by Philipp von Weitershausen, Lennart Regebro and others (please forgive me if I forget someone!). At the Plone conference 2005 I gave a lightning talk about tramline,
a lightweight up and download accelator for web applications. Now at
last I've found some time to put the source code online. This is
not a proper release yet, but it's there for interested people to take a look at it. Thank you Phillip Eby for giving credit where's credit's due in
your comment on this article. Since various people were curious to see especially the little query
language we wrote on top of the Zope 3 catalog, I've just put up the
generic libraries we developed for documentlibrary project online,
at least in svn in the Zope 3 base at codespeak, here: Yesterday I managed to build something in just a few hours in Zope 3 that I wouldn't have been able to build so easily in Zope 2. What
I've built is an extended query system for the Zope 3 catalogs. The ClearSilver templating language does not have a very pleasant syntax for people familiar with the TAL notation of Zope Page Templates. That's not to say ClearSilver's syntax is awful; it's deliberately simple, and I'm sure one could get used to it pretty quickly. Still, I started wondering what ClearSilver syntax would look like if it were more like TAL. Let's call such a theoretical TAL-like ClearSilver "Clarity". Perhaps this is a bit confusing, as it's the same name as the ClearSilver integration package I talked about before, but it's a nice name. :) I've just checked in a new package into the Zope 3 base subversion repository called Clarity. What it does is integrate ClearSilver templating into Zope 3 (trunk, though I expect Zope X3.0 or even Five support should be easy enough). It's all still rough, but initial tests show ClearSilver templates can be quite a bit faster than ZPT, and they have other possible benefits. In my simplistic experiments I got transaction rates about 2 to 5 times higher than you can reach with ZPT, testing this with the 'siege' utility. Ian Bicking just posted an insightful analysis of what makes Ruby on Rails work. What struck me most was the following: Jim Fulton, today, on the Zope-3 dev list: In this article, I will identify problems with the Zope release
strategy, attribute blame, propose solutions, and offer some hope for
the future.
(6) Tue Apr 01 2008 17:25 Explicit is better than implicit, and what it means for Grok:
(10) Thu Nov 15 2007 23:56 At the Dawn of the Fourth Age of Zope:
(5) Wed Sep 26 2007 14:53 the challenges of version management in an eggified world:
(20) Mon Sep 10 2007 15:24 Well-kept secrets of Zope:
(8) Tue Jan 09 2007 14:04 Grok Sprint Zwei: the Ascent of Man:
(19) Thu Nov 09 2006 23:21 Grok: or what I did on my holiday:
(24) Sun Sep 24 2006 16:54 Jean-Marc's implications:
(3) Thu Dec 15 2005 22:39 Empowering the power users:
(7) Thu Dec 15 2005 13:34 The borderland between content and software:
In the early days of Zope, you could design content "TTW" (through
the web). You could answer questions about structure and suddenly,
you had new kinds of content -- YOUR content -- that could be added
to folders in the system. No programmers were involved, no special
login permissions on the server, no database schemas to update.
[More]
(1) Fri Dec 02 2005 19:36 Five-based i18n in Silva checked in (PTS Delenda Est):
(8) Fri Nov 11 2005 16:41 Tramline source code now available:
Sat Oct 01 2005 13:31 Credit where credit's due:
Fri Sep 09 2005 18:33 hurry library in the Zope 3 base:
(1) Wed Jul 13 2005 12:08 extended catalog queries in Zope 3:
(3) Sat Apr 16 2005 00:27 the Clarity Template Language:
(2) Fri Apr 15 2005 20:38 Clarity, ClearSilver integration for Zope 3:
(11) Wed Apr 06 2005 20:35 What Zope can learn from Ruby on Rails:
[More]
(2) Fri Mar 18 2005 14:56 How to delay a Zope release:
Now that that the decision has been made to include Zope 3
in Zope 2.8, I'd really prefer that Zope 2.8 use X3.1 code,
not X3.0 code. In general, having code shared by Zope 2 and
Zope 3 will complicate deprecation, probably increasing the
length of time we must keep backward-compatibility code.
I'd like to try to keep the Zope 3 code used in Zope 2 and
the Zope 3 code used in Zope 3 in sync as much as possible.
[More]
(10) Thu Mar 17 2005 15:56 Fixing the Zope release process:
[Main] 
Unless otherwise noted, all content licensed by Martijn Faassen
under a Creative Commons License.