[Grok-dev] Re: Benefits of Grok -- please contribute

Martin Aspeli optilude at gmx.net
Tue May 15 15:35:56 EDT 2007


Martijn Faassen wrote:

> That I think Zope 3 and Grok are less magic is probably partially due to 
> perspective - I'm used to our way of doing things. That said, I do think 
> Zope 3's explicitness and clearcut component and configuration systems 
> help in reducing magic.

It's also interesting to note that most of the majik voodoo in Zope 
(typically, generating classes) happens in the bit that Grok is trying 
to displace - ZCML handlers.

>> 5 What might be considered drawbacks with Grok compared to "competing" 
>> frameworks?
> 
> Relational object mappings have advantages in advanced query 
> construction and also relational databases are more widely understood. 
> Grok doesn't support this yet.

I would strongly advocate some deep thinking around how Grok 
applications may want to interact with SQLAlchemy.

I think I understand the connection management side pretty well.

ore.alchemist has some interesting abstractions in terms of mapping Zope 
schemata to ORM schemata, and thus allowing you to use formlib.

This isn't so much about "you could do it" - there are an infinite 
number of ways you could do it. It's about promoting some patterns, that 
have been properly thought through and are known to work with the other 
patterns people use in Grok.

For example, let's say we had a catalog-like abstraction to search 
metadata using an RDBMS. That'd allow very powerful query logic, even if 
the real objects live in the ZODB.

Or, standard ways of registering traversal logic and views for 
ORM-mapped things.

At the very least, there should be a well-supported (not necessarily in 
the core) way of doing transaction integration. My collective.lead does 
that for Zope 2, and I imagine the Zope 3 version isn't much different 
(if at all?). It's very simple and low-level, though: I think Grok would 
need to support slightly higher level abstractions.

> Grok should be just as easy as the competitors, but offer more reusable 
> components and more flexibility, allowing you to construct great 
> software now that will age well.

Like good wine. :)

Martin



More information about the Grok-dev mailing list