[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