Forum OpenACS Q&A: Response to Article on ACS x Zope

Collapse
Posted by Don Baccus on
There are some complexities in the core architecture and I sympathize with Fazil's wrestling with the workflow package.

Part of the problem is the lack of good examples of code effectively using the various core tools.  This is largely because the existing packages were ported by aD into the 4.x framework while the framework was being constructed.  They faced cart-before-the-horse and learning curve issues.

I'm currently working on part of a new dotLRN package that makes use of workflow in what I think is an interesting way.  Workflow drives all event and registration creation and administration actions and once you understand how all the pieces work, it's very simple to use.

But it took me a while to figure out just how workflow could simplify, rather than complexify, my code.

As examples like this, more examples making effective use of the service contract model (such as the dotLRN portals system), workflow, the content repository, and the like are published  and made available I think they'll make excellent learning tools for newcomers.

Even better would be a simple example package tying together the concepts in a more trivial way, but that requires we find someone with time on their hands to do this.

The current exercises with workflow and service-contract based developement show us a few things.  Neophytos needs to write a service contract editor much like the workflow editor (but simpler because contracts are simpler).  It's on his list for "round two".  Workflow needs some enhancements, including the central UI (one advantage of a "workflow-centric" package is that the user can visit a central "task todo" page as well as the package-specific pages to do work.  Tasks appear in both places as though by magic!  Really!)

And the new portals package should make writing portlets very easy.  In the dotLRN package I'm working on we're experimenting with writing a single pagelet to serve as portlet and package index page, rather than follow the typical "write it twice" paradigm we've seen in the past.

Good examples and good documentation will make the toolkit more approachable.  The learning curve will certainly be higher than with OpenACS 3, there's no doubt of this.

But when you learn the tools, you'll be able to cobble stuff together *much* faster than in OpenACS 3.  That's the trade-off.  For a one-off written by someone who never expects to write another website and wants to keep life as simple as possible, OpenACS 3 may always be more appropriate.  But for those who expect to be implementing a lot of complex websites the tools we've inherited, along with our enhancements and the addition of new tools like service contract are a real win.