If you’re skimming this, I’d like to direct your attention to the poll below
I’ve been using ZopeSkel and advocating it’s use for over a year now. I’ve participated in a major sprint on it, I’ve taught it to friends and colleagues, and I’ve come to a conclusion:
OK, so it doesn’t really suck. IMHO, it sucks a lot less than ArchGenXML. It’s still an essential part of my development tool kit, and I can’t see doing Plone development without it.
I’m giving a talk about ZopeSkel at the Plone Symposium East next month. I’m going to be advocating ZopeSkel over AGX for content type creation. It will surely be epic.
Back to the suckage: ZopeSkel is not without its flaws. It’s inherent architecture isn’t quite right. ZopeSkel took a somewhat specific tool (PasteScript) and abused it to do something outside the realm of the tools purpose. This is bad!
I hit upon some of the shortcomings of ZopeSkel in the Sprint Reportout I posted last year. Over the past few months I’ve been pondering those shortcomings and think it’s time for a major change.
So here are the major issues:
- ZopeSkel is out of PasteScript’s scope
- ZopeSkel is impossible to test accurately
- ZopeSkel interactive sessions are not easily reproducable
- ZopeSkel can’t respond to user input
- ZopeSkel’s documentation varies from overly adequate to non-existent
- ZopeSkel’s development is severely fragmented.
- People complain about ZopeSkel not having a graphical user interface
That said, ZopeSkel is still extremely useful and intuitive, it just needs some work by a few dedicated individuals. Ultimately, I’d like to see the product position itself as the defacto code generation tool in the Plone universe.
So here’s what I think needs to be done:
We need to re-write zopeskel from the ground up. I like the use of cheetah templates and context-aware commands. I’d like to see a robust framework for collecting information from the developer, saving it into an INI file (or something else, maybe YAML) and providing a framework where the user interface is decoupled from the data collection and template execution.
There’s even an opportunity here for an integration point with AGX.
It’s ambitious, yes, but I think it’s well within the realm of possibility.
Now we get to the reason why I’m posting this: I’m seriously contemplating sprinting on this at Penn State next month.
Due to funding problems I’m paying my own way to the symposium. I don’t want to plan a sprint and stay 2 extra nights if nobody is going to sprint with me. I’m also open to the idea of taking on a sponsor if someone wants to put up some money to see this work progress.