[Grok-dev] Sprint

Paul Sephton prsephton at gmail.com
Mon May 19 12:50:36 CEST 2014


Hi all,

Since I am located far from anywhere really I would not be able to attend a
sprint, but that does not stop me from liking the idea of a bit of strategy
planning.

I have personally being using grok for quite a while, since it appeals to
my obsession on component driven frameworks and Python.  While it seems
most people have migrated to Pyramid or Django, there is little appeal for
me there. Grok and megrok.rdb + sqlalchemy suit me just fine.

Having said that, I have found myself wondering recently what exactly it is
that keeps me using the framework. Is it the conciseness? The flexibility
provided by the zope component framework? The zpt/chameleon templating
language? The speed? Zodb? Certainly there are other frameworks that mix
these factors. Zpt has even been ported to php!

When all is said and done, probably the only thing I dont like about zope
itself is the zcml side, which grok completely does away with. The rest is
extremely well thought out, extensible and rock solid. Whats there not to
like?

Well, the learning curve for one thing. The component framework is
sufficiently different from the typical mvc mindset that people are blasted
with a feeling of unfamiliarity and uncertainty which does not easily
dissipate. The documents only help to a point. Tasks such as adding your
own formlib widget are easy enough, but hard to learn how to do. The
flexibility gets in the way. Because it is flexible it is also inherently
complex.

The other problem around grok, is change management. It is hard to change
the project significantly without introducing incompatibilities.  Some
upgrades in the past, particularly the Fanstatic update was a nightmare for
existing large projects.

Then there's the name. Have you noticed how popular the name "grok" has
become out there? Searching for stuff about grok has become ridiculous. It
used to be fine, but now searches give all sorts of bad results. Django is
way better off despite sharing a name with a movie. I am just pointing this
out, and have not a clue what may be done about it.

Ultimately grok has one important claim to fame. No other framework is
quite as good at mixing declarative style directly in Python code, and once
one cottons onto the use of inheritance for view classes and models, and
the way views may be common to many models, the amount of source needed for
quite complex tasks can be amazingly small.

Thanks for developing this gem, and for continuing to maintain it even
though activity has declined,

Paul Sephton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.zope.org/pipermail/grok-dev/attachments/20140519/87434248/attachment.html>


More information about the Grok-dev mailing list