[Grok-dev] megrok.rdb updated

[Santiago Videla]

Hi Martijn

I'm trying your last updates on this, nice work. :)

I can't figured out how to use it to develop some real app. With "real" I
mean, bigger for example. And with bigger I mean, different modules or
packages that defines the models (rdb.Models) and the grokApp will make use
of them

I was thinking to have something like:

myProject.clients/
     myProject/
         clients/
             models.py  ###  Clients models (rdb.Model)
             ....
src/
     ProjectExmple/
            app.py ### use Client models
            ....

is this possible? hints?

maybe I'm wrong, and this is not the best way to organize my project,
advices are welcome :P

Regards

On Wed, Jun 25, 2008 at 9:46 AM, Martijn Faassen <faassen at startifact.com>
wrote:

> Hi there,
>
> I've started updating megrok.rdb, using the recent work done on
> zope.sqlalchemy, z3c.saconfig, and my now somewhat greater understanding of
> SQLAlchemy.
>
> As a result, megrok.rdb has moved to a top-level directory in svn and now
> actually has a README.txt which is also a doctest:
>
> http://svn.zope.org/megrok.rdb/trunk/src/megrok/rdb/README.txt
>
> I also updated the rdbexample to make use of the new code, though it's
> rather hard to play with it as it has the horrible text-only screens instead
> of proper page templates:
>
> http://svn.zope.org/grokapps/rdbexample/trunk
>
> There is a lot that remains to be done.
>
> * The directives need to become a lot stricter; right now it's too easy to
> do something wrong and get an obscure error. We need more validation, better
> default behavior, etc.
>
> * It turns out that using auto-generated primary keys as a container key
> doesn't look possible: this primary key is not assigned yet by the database
> by the time the container can be used. This means containers need an
> important re-think as this destroys the only sensible default behavior I can
> think of right now. This is a big problem and we need some way around it -
> there often is no other column in a database table that can function as a
> key.
>
> * it would be nice if we could have a default behavior for metadata, so
> that the rdb.metadata directive can be omitted entirely. Note that the
> rdb.metadata directive may not work properly yet on a module level; at least
> I haven't tested it yet.
>
> * More work needs to be done in making database setup easier. While
> z3c.saconfig helps a lot, it's still setting up quite a bit to get the basic
> case working. I hope we'll eventually see a grokui.rdb which allows people
> to set up a database utility and connection parameters through the grok
> admin screens.
>
> * actually automatically creating the tables in the database from the
> metadata is something we need some infrastructure for too. Right now in
> rdbexample I do this upon first traversal into the application. We could do
> it upon application add time perhaps, and also perhaps present a UI in
> grokui.rdb to let people refresh the database tables.
>
> * I haven't even touched the part that generates a Zope 3 schema from
> database schemas; this code is nice to generate forms. This requires some
> more study of the various alternatives around, and SQLAlchemy itself (last
> time we looked at it we weren't able to retrieve the order of definition for
> columns in a table, which is rather important to show a nice form).
>
> Regards,
>
> Martijn
>
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> http://mail.zope.org/mailman/listinfo/grok-dev
>



-- 
Santiago Videla
www.revolucionesweb.com.ar
http://www.linkedin.com/in/svidela

Sigue la mata dando de que hablar siempre abajo y a la izquierda donde el
pensamiento que se hace corazón resplandece con la palabra sencilla y
humilde que l at s tod at s somos.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.zope.org/pipermail/grok-dev/attachments/20080708/502cc4f1/attachment-0001.html