[Grok-dev] Re: Grok ORM with Storm
Christian Klinger
cklinger at novareto.de
Thu Jan 24 03:37:53 EST 2008
Hi,
thanks for your suggestions. I will start to work on these on
this weekend. But i think i need some help. I ´ve no
idea howto SMASH ZCML for an instance. I will look into other
megrok.* and the martian packages to see how these things work.
If i don´t get things to work, i will ask here again.
Christian
> Hey,
>
> This is some feedback; note that I have no actual experience using Storm
> yet so I might be wrong about some things.
>
> In general we try to use a combination of grokkable base classes and
> grok directives on those classes to set meta information.
>
> Christian Klinger wrote:
> [snip]
>>
>> 1. SMASH ZCML
>> --------------
>>
>> In the package zope.storm it´s necesarry to define a store in zcml.
>> I think we can SMASH this zcml-slug.
>>
>> <store name="contact" uri="sqlite:/tmp/contact.db"/>
>
> Yes, I imagine we can turn this into something like:
>
> class MyStore(megrok.storm.Store):
> grok.name('contact')
> grok.uri('sqlite:/tmp/contact.db')
>
> This would introduce a new grok.uri directive. I don't know whether this
> would have a lot of other uses. Perhaps
> megrok.storm.connectionid('sqlite:/tmp/contact.db') instead.
>
>> 2. Make the grok config in our grok.Model easier:
>> -------------------------------------------------
>>
>> This is the example Model of the Howto [2]:
>>
>> class Contact(grok.Model, Storm):
>> grok.implements(IContact)
>> __storm_table__ = "Contacts"
>>
>> id = Int(primary=True)
>> name = Unicode()
>> city = Unicode()
>>
>> Maybe we can do something like megrok.storm.StormTable('Contacts')
>> instead of __storm_table__ = Contacts.
>
> I think we might want to avoid subclassing grok.Model directly. Instead
> we'd need a way for the system to recognize models which are *not*
> subclasses of grok.Model as models. Then we could do:
>
> This looks like a directive, so:
>
> class Contact(megrok.storm.Model):
> grok.implements(IContact)
> megrok.storm.table('Contacts')
>
> id = Int(primary=True)
> name = Unicode()
> city = Unicode()
>
> Alternatively we could even import Storm directly from Storm and write a
> grokker for them. It could recognize the megrok.storm.table() annotation
> and then stuff it in as __storm_table__.
>
>> 3. The container config:
>> ------------------------
>>
>> This is the config of the Container in the Howto [2]:
>>
>> class contacts(StormContainer, grok.Application, grok.Container):
>> """ this application inherits from StormContainer too """
>> def __init__(self):
>> super(contacts, self).__init__()
>> self.setClassName('contacts.contact.Contact')
>> self.setStoreUtilityName('contact')
>>
>> Maybe it´s possible to say megrok.storm.setClassName('xxx') and
>> megrok.storm.setStoreUtiltiyName('xxx')
>
> I think grok.Container shouldn't be a mix-in here. Again we should have
> a system that can recognize grok.Container as a kind of model.
>
> what about this?
>
> from contacts.contact import Contact
>
> class Contacts(megrok.storm.Container):
> megrok.storm.content(Contact) # or content_class, perhaps?
>
> I don't know what setStoreUtilityName() does exactly, but we could use a
> similar directive:
>
> megrok.storm.storage('contact')
>
> where 'contact' is the utility name. Why does the storm container need
> to know the storage but the storm model does not?
>
> I think these can be set before the __init__() is called on the
> class-level, right? Or is there any reason for thesse settings to be
> dynamic?
>
>> So i think i have to work on megrok.storm package which includes
>> these simplifications.
>
> Great!
>
>> Please give me some feedback.
>
> There you are. I tried to give some feedback to make the storm stuff
> more grok-like. Hopefully I'm not saying impossible things.
>
>>
>> [1]http://stormcontainer.googlecode.com/svn/trunk/src/stormcontainer/
>> [2]http://plone.grok.quintagroup.com/documentation/how-to/grok-orm-with-storm
>>
>
> You didn't publish the second link. I published it for you, I hope you
> don't mind.
>
> Regards,
>
> Martijn
More information about the Grok-dev
mailing list