[Grok-dev] Sprint

[Jan-Wijbrand Kolman]

Hi Paul,

Thanks for the kind words!

Like for Leonardo, most of the sprint planning - if anything happens at 
all - we'll be done over this ml. So, perhaps, you might the be able to 
attend after all, you never know! :-)

regards, jw

p.s. Now that I think about it, a non-european sprint would actually be 
very cool of course. Really not sure how feasible it would be for me (or 
for others), but I like the idea at least ;)

On 5/19/14 12:50 PM, Paul Sephton wrote:
> 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