Wow, lots of ideas here. I will go for the acts_as_versioned plugin as Andreas suggested. Once that is working we can think about saving incremental changes, different published versions etc.
Tim, why would you like the git option better? For me it seems cleaner to have all your stuff in one place, not the pages in a db and page versions in git. Manuel On Mon, Jan 5, 2009 at 5:52 PM, Adam van den Hoven <[email protected]> wrote: > You should also consider that if you're going to keep a version history that > only one revision (and certainly not necessarily the "current" revision) > should be published. This will allow you make a number of changes to a page > (especially useful if you extend the page preview extension to work with > versions) without affecting the current public version. This would also > allow you to reduce the size of the version history by keeping all the > incremental edits once this version is "published" collapse the version > history down to the published version. This gives you a history that > includes all the published versions and all the incremental changes since > the last published version. > > The core development team may want to consider a modification to the core > status properties which will (a) make it easier to do versioning as I've > mentioned and (b) make things clearer. The change is to break the current > status into 2 two fields. The first would be called "status" and would have > values like "draft", "reviewed", "published". The second field would be > "visibility" and would have values like "visible" and "invisible". Visible > and the three status values map directly to the current status values, and > published + invisible is the same as the current hidden status. This allows > you separate the purpose of a page (RSS, CSS, etc) from its status. I think > this simplifies the meaning of things since whether or not a page is > publicly accessible is completely independent of whether or not that page > appears in navigation. It will also make it easier, I think, to create a > workflow extension. > > My 2 cents . > > Adam > > On 5-Jan-09, at 8:14 AM, Andreas Roedl wrote: > >> Shouldn't be too hard to implement, at least, when you use one of the >> following plugins: >> >> Acts as versioned (see the example code): >> http://wiki.rubyonrails.org/rails/pages/ActsAsVersioned >> >> A Rails plugin that uses Git to version ActiveRecord fields: >> http://github.com/courtenay/acts_like_git/tree/master >> >> >> Andreas >> _______________________________________________ >> Radiant mailing list >> Post: [email protected] >> Search: http://radiantcms.org/mailing-list/search/ >> Site: http://lists.radiantcms.org/mailman/listinfo/radiant > > _______________________________________________ > Radiant mailing list > Post: [email protected] > Search: http://radiantcms.org/mailing-list/search/ > Site: http://lists.radiantcms.org/mailman/listinfo/radiant > _______________________________________________ Radiant mailing list Post: [email protected] Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
