On 11/16/10 8:29 AM, Martin Aspeli wrote:
> 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.


Whether or not it's reasonable to expect people to grasp the concepts 
depends (almost) entirely on who you are talking to IMHO.

On this list we're talking to add-on package developers, so yeah I'd 
expect c.transmogrifier to be digestible here; just as I'd expect 
funnelweb to be digestible on plone-users (although unfortunately I 
think funnelweb needs a KGS, I can't install it in Plone 4: 
http://dpaste.com/275914/ or Plone 3: http://dpaste.com/275982/)


>
> 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.


Yes! These last two paragraphs are the attractive bits. For my part, I'm 
still struggling with the "basics" (perhaps because I tend to 
over-analyze them.):


- How do I install it? 
http://pypi.python.org/pypi/collective.transmogrifier/1.2 says "see 
docs/INSTALL.txt" which I'd only have if I installed it ;-) (Want me to 
fix this?)


- What does it do once I install it (i.e. do I have to start Plone? Or 
will there be a bin/transmogrifier? etc.)



AFAICT, transmogrifier does nothing without some ZCML to load an 
example.cfg. I tried just now to load an example.cfg via zcml-additional 
and/or site-zcml in my plone.recipe.zope2instance section with no 
success (got various ZCML "undefined" errors). Next stop would be to 
create a package, in which I could have more control, via name space 
level configure.zcml file).




So yeah. Maybe c.transmogrifier could grow a bin/transmogrifier script 
that could execute example.cfgs ?




Alex




>
> Martin


-- 
Alex Clark · http://aclark.net
Author — Plone 3.3 Site Administration · http://aclark.net/admin

_______________________________________________
Product-Developers mailing list
[email protected]
http://lists.plone.org/mailman/listinfo/product-developers

Reply via email to