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

[Martijn Faassen]

Hey,

Martin Aspeli wrote:
> 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.

Though we can't avoid majik voodoo in Grok entirely. I think we generate 
a class in one or two places...

>>> 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.

Oh, it's been discussed from the very first Grok sprint, so it's 
definitely something we want to do. I know Christian was experimenting 
with mapping Zope 3 schemas to SQLAlchemy, but don't know how far that 
work got along.

> 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.

Ah, cool. I saw Christian talk to Kapil a while back on IRC so it looks 
like he looked into that too.

> 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.

Exactly. That's what Grok should be about.

> 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.

I think this one should be out of scope for a first cut, but something 
like that would of course be very cool.

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

This story should be in the first cut, I think, along with SQLAlchemy 
schema to Zope 3 schema mapping (and patterns for formlib use).

> 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.

Can't we use one of the SQLAlchemy integration packages for Zope 3? 
There's two around. Would neither of them be suitable? I was hoping Grok 
could just use one of them.

Regards,

Martijn