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

[Martin Aspeli]

Luciano Ramalho wrote:
> Grok is Zope 3, so it leverages the ZODB. This has *very* important
> consequences for an evaluator.
> 
> On 5/13/07, Martin Aspeli <optilude at gmx.net> wrote:
>> o Ease of learning and speed of development
> 
> ZODB helps *a lot* here
> 
>> o Low risk of getting tied in, in terms of decent integration with other
>> packages
> 
> ZODB is a real drag here.
> 
>> o Ability to migrate to other platforms later,
> 
> Again, use of the ZODB does not help at all.
> 
> Don't get me wrong. I am addicted to programming persistent objects on
> the ZODB, and I think Zope 3 with Grok offers the best way of doing
> it. In Zope 2 it was too hard to persist your own objects in way that
> played well with the rest of the framework; Archetypes made it easier,
> but at a very high price in terms of black magic.
> 
> But as we consider how to "sell" Grok, the fact that we have the ZODB
> is a double-edged knife.

Yes, this is true.

> Ideally, it should be simple to start any project on the ZODB and
> later switch to a relational dababase back-end, with as little pain as
> possible.

I think that counts more for marketing than it does for practical 
benefits. What I *do* think counts a lot, however, is the ability to 
practically talk to RDBMS where they make sense.

I think RDBMSs and OODBMSs like the ZODB are good at different things, 
and serve different purposes. For example, people who build a CMS on 
MySQL alone are, imho, mad. Even Alfresco, the biggest CMS I know of 
that could claim such a stack, seems to store most of the objects in the 
filesystem, with metadata and locations tied into MySQL.

What I'd like to see, are well-established patterns and one, single, 
chosen, sensible integration with SQLAlchemy (SA). SA rocks. It's really 
nice to work with. It gives almost ZODB-like persistence, and a nice 
query interface.

See http://optilude.wordpress.com/2007/05/02/im-sorry-i-may-have-nih/ 
for a pattern I feel works, and some discussion of the alternatives.

Using formlib, and a bit of Grok magic, it should be possible to see 
RDBMS CRUD-like operations that are not too complex.

However, I'd caution against the imaginary goal of making the ZODB and 
an RDBMS entirely interchangeable. You'll either end up with a poor 
lowest common denominator, or a mess, or both, for a use case that I 
suspect no-one really has.

Now, if Grok gave developers the ability to make this choice 
intelligently, where one was not a poor cousin of the other and both 
could co-exist, between SA and ZODB persistence, *that* would be awesome. :)

>> It's different - e.g., aspect orientation (adapters) and persistence (no
>> RDBMS).
> 
> I like this very much. I believe most web programmers are not really
> happy using the tools they have, so these key differences should be
> emphasized.

Precisely. Also, try to compare this with JSF, which to a certain extent 
is also component-oriented. You may weep, though.

Martin