[Grok-dev] How to use auto-forms to quickly handle nested objects

[Steve Schmechel]

--- On Sun, 3/22/09, Santiago Videla <santiago.videla at gmail.com> wrote:
> 
> I can't tell you too much about auto-forms, but maybe I
> can help you with
> the relationships issues.

Auto-forms (or at least really fast templating) of a hierarchical object model would be the key to creating a rapid, web-based prototype of this type of application.

I am not really having a problem with modeling the relationships or storing the object data in the ZODB, but with doing it in a way that it is easy to publish the contents to the web (the "ope" in "zope" :-)

> 
> I'm working on a project with PostgreSQL instead of
> ZODB because I need an
> easy way to handle that kind of relationships,1-N, N-N,
> delete objects with
> cascade or restrict conditions, and all the stuff that
> PostgreSQL can do.

This is exactly the type of stuff I do at work everyday (using MS SqlServer and C#).  One of the attractions for me of Zope/Grok, is that an Object Database should handle this sort of "nested data" easier than an RDB and without any configuration.

Think about deleting an application instance using the Grok Admin UI.  No cascade delete required - all of the content is gone!  Or the whole thing could can undeleted in one operation.  (Yes, you can accomplish this in an RDB, but you must intentional design it that way and live with the additional complexity.)

There are other reasons I might pick a RDB for a back-end data store, but this is not one of them.

> 
> I'm using megrok.rdb[1] and it's working very well
> by now.

For someone who is already a Zope developer megrok.rdb is a great tool.

As a Zope/Grok newbie, if I needed an RDB for my application from the start, I would probably be more attracted to solution like TurboGears or Rails.  TurboGears uses the same SqlAlchemy as megrok.rdb, but it is a "main actor" in their code stack rather than an add-on and they have a lot of tools around it to simplify working with and RDB within a project.

The other reasons I like Zope3/Grok is for its scalability and code quality.  If I outgrew an RDB-based TurboGears project, I would probably upscale by rewriting in a dotNet or Java framework - probably not Zope.

That's why I think it is important that the entry level development in Grok is easy.  If I am doing a quick prototype in Grok and later I need to upscale and integrate it with other applications, having a way to move forward rather than "trash and rewrite" is a big plus.

I my work environment, the "Zope" name and its capabilities carries little weight by itself.  It is mostly an unknown.  It needs to deliver some advantage up-front in order to get its foot in the door. 

That advantage would come from being a rapid, agile, test-driven development environment where it is easy to produce working code for the customer to evaluate early in the development cycle.

Then, it's capabilities and code quality will allow it to remain a contender when integrating and extending the application.

Sorry for going beyond the topic, but I would love to someday replace all the wizard-generated, Visual Studio code cruft that speeds our development today, with a well designed component architecture.  To do that, Grok needs create a basic set of web forms faster than the Visual Studio Designer and it's data binding wizards.

I think that it is possible for Grok to do that.