plonewars.com

I’m mentoring Vidar Svansson for the Google summer of code. He’s
going to look at "genesis" again. Genesis is the name we use for a
rewrite-archgenxml-from-scratch effort that hasn’t gotten off the
ground yet. One sprint, in which we selected coral as the underlying
UML library, that’s it. No real work done since.

Vidar’s going to take a fresh look at it from a research
perspective: he’s doing it for his MSc thesis.

The gsoc is supposed to start next week, but Vidar has already
started. Mostly reading up on zope3 and grok, trying to install coral
and going to a code generation conference. I asked him a few days ago
if he planned to be finished before the project started

Coral is a pain to install. It is possible on linux if you use a
pre-made rpm. Compiling on a mac: forget it. There’s no public svn
repository, so you have to use the tgz and figure out the changes
since the last versions yourself. It sounds a bit risky.

At the conference, he discovered some new eclipse-based tool that
looked OK to him, so he’ll try things out with it. He says he’ll be
able to generate code for a simple case in a week or so…

End results that he/we aims for? A combination of actual code and
scientific research. A theory on how to best model a plone web
application. Code that shows it can be done

In the recent weeks, I got quite a number of questions about
archgenxml and plone 3.0. In summary:

• The good news is that archgenxml-generated products still pretty
  much work OK on plone 3.0. Archetypes itself didn’t change that
  much and the majority of what archgenxml does is to feed info to
  archetypes.
• The number one problem on plone 3.0: the workflow. Archgenxml
  generates them the oldfashioned way: workflow files in the
  Extensions directory. That way of working has been deprecated
  with plone 3.0, workflows ought to be handled with genericsetup now:
  in profiles/default/workflow.xml.
• There is a workaround: install the product in plone 2.5, export the
  workflow.xml there and add it by hand to your product. Urgh.

Improving archgenxml has been in the planning for some time. Since
that blog post in september 2006, progress has been slow, but in the
last 2 weeks I’ve again put in quite some effort and I’m again happy
coding along in good old train-driven-development commuter work
The stuff is all done on the svn trunk version. Some highlights of
what’s been done:

• Archgenxml is now something you install with python
  setup.py.
• Archgenxml uses the zope3 component architecture internally to
  handle things. At least, I’ve got a few interfaces, I’m using one
  adapter and one utility. It already makes things clearer. The choice
  for zope3 is a good one, I can tell. See one of the next blog
  posts.
• One horrible hack has been done to be able to import said zope3
  machinery. I posted earlier about setup.py problems. Basically
  depending on zope.interface, zope.component and the rest of the
  stack almost guarantees that you mess up your python’s site packages
  with versions that are incompatible with other zopes (like, your
  running instances…) that you’re running with that python. You’d
  have to isolate bloody everything with workingenv to get this
  working. So start up archgenxml and the hack will introduce itself
  and tell you how to handle it
• All the new code I wrote has doctests. And I try to add doctests for
  existing code that I copy/paste to new files. So hopefully this
  means that the quality will slowly rise.
• A completely empty genericsetup profile is generated and installed
  by the quickinstaller. Anything you put in there is in mortal danger
  as it’ll probably get plowed under once I start adding genericsetup
  files with archgenxml.

Well, there’s the current status! Ongoing work.