On 16 November 2010 10:17, Alex Clark <[email protected]> wrote: > > I'm actually now interested in both approaches. While transmogrifier > gets a bad rap for being "heavy" I think there are times when you do > want to reach for something more than a "one off" script.
For the record, Transmogrifier is really quite lightweight. I think this "bad rap" comes from people who have not really looked at what it is or what it does and make a bunch of assumptions. It *does* require that you spend an hour or so learning its core concepts. I'm not sure that's an unreasonable expectation. If you understand dicts and generators, then I think you're pretty much there. If you want to write your own blueprints, you need to know how to register a utility. In my own experience, once I'd understood those core concepts, writing a migration process using both out-of-the-box Transmogrifier blueprints from various packages and my own custom blueprints for client-specific stuff took a lot less time, was a lot easier to test, and a lot less error prone than custom scripts. I've written my fair share of ad-hoc migrations. Transmogrifier is built on the principle that every migration is different. It is not a one-size-fits-all solution. Rather, it is a nice abstraction that lets you focus on writing the bits that *are* specific to your use case, and reuse well-tested, easy-to-understand components for things like reading from a database, traversing filesystem directories, constructing Plone content, dealing with workflow states, etc - but only when they make sense. Martin _______________________________________________ Product-Developers mailing list [email protected] http://lists.plone.org/mailman/listinfo/product-developers
