From: Noam W. <nwe...@er...> - 2008-02-27 21:56:00
|
Michael- I think those features would be very useful. In your vision, would these methods be called after the element definition has changed? If so, how will the defunct elements be made available to the callback function (won't thawing the story throw an error if the data doesn't match the new definition?) If not, how will the data be ported to the new fields? Thanks! Noam ----- Original Message ----- From: "Michael Peters" <mp...@pl...> To: "krang-devel" <kra...@li...> Sent: Wednesday, February 27, 2008 4:26 PM Subject: [Krang-devel] Upgrading element libs and dealing with past stories > We seem to have this problem at lot here at $work. We find a better way to > do > something with our elements, or we have a new client need that changes how > we > have elements structured underneath. > > It's really easy to add new elements or new fields to existing compound > elements. But it's really, really hard to remove or change existing stuff. > It's > not too bad if you just want to deal with live stories, but it gets really > ugly > if you want to deal with past versions of stories. > > I'd like to fix this. So here is my proposal. Please let me know if I'm > missing > something you've wanted in the past, etc: > > 1) Add Krang::Story->transform_stories(). It would accept the same > arguments as > Krang::Story->find() with some additions (past_versions flag, callback). > For > each story it finds it would pass it to the callback routine. What it > get's back > it will save to the db without creating a new version or history entry. > Then it > will do the same thing for each past version of that story (if the > past_versions > flag was true). > > 2) Add Krang::Story->transform_stories_xml(). Same as > Krang::Story->transform_stories() above, but instead of passing the story > object > it would pass the XML serialization of that object. Whatever XML is > returned > from the callback would be de-serialized back into a story object and > saved in > the DB (without changing the version, history, etc). This would be nice if > you'd > rather use something like XSLT to do the transformation since it's a > pretty good > standard for transforming hierarchical data. > > Sound good? > > -- > Michael Peters > Plus Three, LP > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Krang-devel mailing list > Kra...@li... > https://lists.sourceforge.net/lists/listinfo/krang-devel > |