[Grok-dev] Neanderthal sprint topics

[Brandon Craig Rhodes]

"Leonardo Rochael Almeida" <leorochael at gmail.com> writes:

> Another sugestion: Integration with Storm:
> https://storm.canonical.com/
>
> ... I can think of two straigthforward integration aspects
>
>  * A folderish type that implements the containment API by putting and
> fetching objects from Storm

You might start with the recipe at the bottom of:

   http://grok.zope.org/minitutorials/transient-objects.html

where I investigated the same issue in preparation for hooking Grok to
SQLAlchemy (though I made the tutorial I wound up writing independent
of the back-end from which you are getting objects).

> * An AutoFields variant that scans a model class for Storm fields
> instead of zope schema fields, or alternatively, a grok declaration
> that sets Storm class attributes on a model based on the fields of a
> zope schema.

I am interested in the same thing between SQLAlchemy and Zope 3!  But,
I am not sure that it would wind up sharing any code with a similar
product for Storm.

> In time, a class for Storm stored instances doesn't need any special
> base classes or metaclasses ...  so I think we can freely use Grok
> model classes for them.

I have strenuously avoided using Grok model classes for objects that
aren't persistent in the ZODB, because if they aren't in the ZODB,
then I have a superstition that they should not inherit from
Persistent!

But no one more experienced has ever weighed in on whether I'm correct
in avoiding inheriting temporary objects from grok.Model.  It sure
would be nice to have 'index' be their default view name again!  And
having a traverse() method right on the object would be kind of nice
too, though I'm still puzzled on whether mixing traversal information
in with an object is a good idea.

> The artifact of such a sprint might as well be merely documentation
> on using Grok with Storm instead of actual Storm support in grok.

In my project that's using SQLAlchemy with Grok, the big question
turns out to be neither schemas (I can, for the moment, live with
re-writing each relation as a Zope schema, and I think there are even
advantages to doing so), nor navigation (since I can just mock up
Traversers for the moment while I work on the "Trails" that I proposed
recently).

The big issue, instead, is getting Zope to commit the open database
transaction when a request finishes being processed.  Fortunately
there is for SQLAlchemy a product named "z3c.zalchemy" that did this
for me, so I did not have to write any code.  Maybe your sprint could
focus first on producing a "z3c.zstorm" that does the same thing,
borrowing from the zalchemy code?  I think that's more fundamental a
thing to get working than the other.

Good luck!  I wish I were attending.

-- 
Brandon Craig Rhodes   brandon at rhodesmill.org   http://rhodesmill.org/brandon