[Grok-dev] Re: Benefits of Grok -- please contribute
optilude at gmx.net
Mon May 14 15:12:54 EDT 2007
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
> 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
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
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
> 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
Precisely. Also, try to compare this with JSF, which to a certain extent
is also component-oriented. You may weep, though.
More information about the Grok-dev