[Grok-dev] Re: Developer scenario

[Martin Aspeli]

David Niergarth wrote:
> Hi,
> 
> I'm a Zope 2 developer considering a move to grok or Zope 3. Our
> application is not typical, it seems, and I'm wondering if anyone on
> this list would comment on whether the scenario I describe below
> seems like a reasonable migration candidate for grok.
> 
> ==== Our application is currently in Zope 2.7. All of our content is
> kept in Postgres. We're really only using the ZODB to organize our
> code. The code objects are limited to Page Templates, Python Scripts,
> ZSQL Methods, JavaScript, and Folders. We have one Zope Product,
> which our Python Scripts (in Zope) use to access Python library code
> (outside Zope) that communicates with Postgres. The ZSQL methods in
> Zope are used mostly by Page Templates for populating list boxes,
> etc.; anything heavy (searching, sorting, updating) is run through
> the library code (via the Zope Product). We have no other content in
> the ZODB.
> 
> A typical folder within the Zope 2 ZMI for our app will contain a
> Page Template, several supporting Python Scripts and ZSQL methods,
> and one or more subfolders, which in turn contain Page Templates,
> Python Scripts, and more subfolders. ====
> 
> So given that structure, is grok appropriate? Is it overkill? Is it
> more focused on managing content objects in the ZODB?

I would argue that your structure is not appropriate. :)

Grok is about developing things on the filesystem; most modern Zope 2 
development (e.g. Plone) and to my knowledge all serious Zope 3 
development follows that pattern as well. The ZODB is not a great place 
to manage code. It is a great place to manage content and persistent, 
hierarchical, semi-structured data.

If you don't need that, then Grok's patterns could help you, but it 
doesn't really have a strongly formulated RDBMS story yet. You may 
indeed find that it's easier to look at something like Pylons or Django 
or TurboGears, which are much more centreed around RDBMS's.

> I've started by dumping a site to the file system with FSDump. From
> the grok tutorial, it looks like our Python scripts would become
> methods on the relevant Model or View class. Our library code could
> be accessed directly. But, ...
> 
> * For our current nested structure (folders within folders), could
> the subfolders become submodules or would we need to flatten things
> out? Our Python Scripts rely on acquisition to locate other scripts
> and ZSQL Methods (e.g., context.another_script_in_same_folder();
> context.tools.some_shared_script(), where tools is a folder one or
> more levels up). Would nested submodules allow most of the calls in
> Scripts to stay the same?

No. You cannot acquire things like that, from one module to another. 
Arguably, there are better ways of achieving this kind of generality, 
using the Component Architecture. You'd need to learn a bit more about 
utilities and adapters before you could make that call, though.

> * Is there a way to handle ZSQL? (I've not been able to find any
> examples.)

I don't think so ...

> * Is the psycopg2 database adapter accessible from within grok?

... and probably not, if it's a zope 2 thing. However, if you need to 
talk to relational databases, SQLAlchemy is a really great library. It's 
not Zope specific (which is a good thing!), but there are some Zope 3 
integration packages in svn.zope.org.

Take a look at http://sqlalchemy.org - the tutorial will give you a very 
good idea of how it works.

It sounds to me like you wouldn't be "migrating" your application if you 
moved it to Zope 3 or Grok - you're rather be re-writing it. You may 
find that the added flexibility, manageability, testability (did anyone 
ever write a unit test for an in-ZODB python script?) and power of Zope 
3, maybe with Grok to pull it all together, would pay off.

Martin