ZopeSkel: Time For a Rebirth?

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:

ZopeSkel SUCKS.

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.

I need to know what you think. Please leave a comment, or use the poll below.

This entry was posted in Uncategorized. Bookmark the permalink.

7 Responses to ZopeSkel: Time For a Rebirth?

  1. Kamon Ayeva says:

    I prefer ZopeSkel to AGX.

    ZopeSkel has been improving everyday, and I’ve been using it lately with success to get the job done and also train people on developing for Plone using it. For me, the whole “paste” idea is brilliant, and if well done the templates can be really useful for the community.

  2. Matthew Wilkes says:

    I like ZopeSkel for knocking out boilerplate. I’m very much against using it for creating content, AGX is much better at that.

    Don’t bother about using it to generate types and portlets and the like, just concentrate on making nice templates for buildouts, packages, etc.

    • jjmojojjmojo says:

      Have you tried using ZopeSkel for creating content types lately? We made a lot of progress on that front at the sprint in October. Now it’s on par with what AGX produces (AFAIK anyway… I’m going to do some apples-to-apples comparisons soon and will post about that in detail later).

      Boiler plate is boilerplate, whether it’s for a buildout or a portlet, so if ZopeSkel isn’t doing it well, I say fix ZopeSkel. I think AGX has a different purpose (mostly driving me nuts)

  3. Although I was the one who first suggested it, I think using ZopeSkel to repeatedly generate new content types/portlets is a bit of a red herring. It’s somewhat necessary because AT requires so much boilerplate that no-one can remember, but it is dodgy.

    I think using paster to create skeletons is a very good thing, and ZopeSkel is very important as a way for us to release “best practice” in a way that people can repeat and understand.

    I’d be against trying to build some kind of framework on top of ZopeSkel to make it into an IDE or super-development-tool. That’s a ton of effort, and will probably be very frustrating. Rather, we should focus on the new work going on with AGX2.

    We should also focus on improving the framework so that code generation isn’t required. You won’t need code generation to create a new Dexterity type. ;-)


  4. nouri says:

    Most of what ZopeSkel does (or was intended to do) is well within the scope of PasteScript templates.

    My opinion was always that if you need to create a lot of boilerplate, then something is wrong with the library that you’re using. Instead of making a tool that creates lots of code to take that burden off the developer, you should fix the library that forces you to write a lot of code to do simple things instead.

    The most important argument here is that even if it’s not code the tool generates for you, you’ll still need to understand and maintain it. So I agree with Matthew when he says that ZopeSkel should be used for minimalistic templates.

    This is not to say that your work is very useful to people, and that the need for a lot of boilerplate is the situation today. The more advanced ZopeSkel templates are one way to lessen that problem for the developer *today*, in a way that’s easier than fixing the libraries themselves. But it’s still a stop-gap.

  5. yurj says:

    Why don’t have a unified way to create code? So ZopeSkel and AGX could call the unified way and if someone contribute to ZopeSkel, will contribute also to AGX and viceversa.

    • jjmojojjmojo says:

      @yurj: I haven’t had time to reply to Martin and Daniel yet, but that’s exactly the direction I’m going with this.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s