[Grok-dev] simple (advanced) tuturial for grok+workflow engine+sqlalchemy?

[Martijn Faassen]

Hey,

Thanks for coming here and asking these questions. Just having people 
coming and and ask these questions is a good sign.

I'm going to give you honest answers, which is a mixed story. The 
overall answers right now are:

* we do have megrok.rdb that integrates grok into SQLAlchemy. I've used 
it successfully in a number of projects and I know of others using it too.

* Unfortunately it lacks a proper release and sufficient documentation. 
I intend to write that documentation and do that release but I cannot 
predict when. Sometime in the next months, faster if helped/prompted.

* We don't have tutorials on how to integrate things like zope.wfmc or 
hurry.workflow into Grok applications.

* For hurry.workflow there is some community knowledge about how to do 
this. Not sure whether we have a tutorial, but someone could sketch 
something down.

* For zope.wfmc I suspect someone will have to do some hard work 
figuring out how it all gets put together before a tutorial can be 
written. I know of no one with the right knowledge. I also don't know 
how actively developed zope.wfmc is, though I do know of at least one 
project (Schooltool) that used it. It was in a limited capacity and I'm 
not sure whether it still does.

Overall:

* The Grok ecosystem isn't as ready out of the box yet as it should be.

* We also have a lot of facilities available (workflow systems, 
SQLAlchemy integration, component programming and things like buildout) 
that I believe help make the Grok ecosystem be a strong contender.

* The Grok ecosystem is definitely moving towards supporting this type 
of use case; I have projects that need this kind of technology myself.

* We'd of course love to have you come in and help us out do some of the 
figuring out on how this is all supposed to work. But we'll understand 
if you decide to look elsewhere.

Some more specific comments:

Alia wrote:
[snip]
> One of these key initial requirements is that the data should be
> stored on a RDBMS (prob. MySQL in this case) so if I am going to
> evaluate grok relative to django/tg2 I would probably want to use
> sqlalchemy as opposed to the ZODB. 

You can definitely make MySQL work with Grok through megrok.rdb; I have 
an app that does just that. megrok.rdb supports both SQLAlchemy use 
cases: generating rdb schemas from python-level descriptions as well as 
reflecting existing schemas into Python.

> Another thing I would like to
> consider (but it is not a requirement at this stage) is to hook in a
> workflow engine like zope.wfmc into the framework (incidentally the
> availability of multiple workflow options seems to be a major plus
> for grok/zope3).

That's definitely an interesting observation. Hooking in hurry.workflow 
is definitely easier and there is some example code lying around 
(Grokstar has a bit of integration code). zope.wfmc will be a bigger 
challenge as I describe above.

> Now in order to make a fair comparison, I would want to at the very
> least use the latest version of grok with sqlalchemy so my first
> question is that is there something out there for grok that is
> relatively stable and workable? 

Yes, megrok.rdb. It is built on zope.sqlalchemy (which integrates Zope's 
transaction mechanism with SQLAlchemy's) and z3c.saconfig (which 
integrates SQLAlchemy with the Zope component architecture).

Look at http://svn.zope.org/grokapps/rdbexample/trunk/ for a basic example.

> The second question I have is: has
> anybody used zope.wfmc or something like it in grok?

People have used with hurry.workflow (and I can help you with that as I 
wrote it :). I haven't heard of anyone using zope.wfmc. hurry.workflow 
is much simpler, but that might also be an advantage.

> The problem is obviously is that I don't have a huge amount of time
> to evaluate or to experiment, and it may be the case that if I can't
> demonstrate some interesting results relatively quickly, I will
> probably be inclined to go with a safe bet like django which would at
> least gain me some kudos for its admin interface.

Understood. I'll note that we're rapidly gaining good support for 
javascript libraries (such as YUI, see hurry.yui for instance), which 
I'm also using in projects. But Django's admin UI still soundly beats us 
in the out of the box experience at this stage.

This will change over time as I'm definitely interesting in building 
high-level UI components for Grok. The pieces have recently fallen into 
place for me.

> In any case, as an aside: my perception of grok/zope3 is that it is a
> very advanced and powerful framework but I am still a confused on how
> to harness all this power. Can I suggest that you include in the
> documentation an advanced tutorial that demonstrates this power. This
> would certainly allow grok to differentiate itself from the
> competition: perhaps something along the lines of what I suggest
> above (-:

We should definitely do something like that. It will take some time and 
effort to get there though. :)

Thanks again for showing us your deliberations too. This will help us 
chart a course for Grok. I'm quite certain that in about half a year 
from now I'd have been able to give you a lot more confident answers, 
but I also realize people can't do much with such assertions and promises!

Regards,

Martijn