On 5-Jan-09, at 9:09 AM, Manuel Meurer wrote:

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.

Probably wise ;)

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.

I wondered that too. It also revisions specific fields NOT the whole record so you can't really go back in time unless you know all the fields that need to be revisioned... and that is tough to do when you add extensions to the mix.

Manuel

On Mon, Jan 5, 2009 at 5:52 PM, Adam van den Hoven
<adam.vandenho...@gmail.com> 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:   Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site:   http://lists.radiantcms.org/mailman/listinfo/radiant

_______________________________________________
Radiant mailing list
Post:   Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site:   http://lists.radiantcms.org/mailman/listinfo/radiant

_______________________________________________
Radiant mailing list
Post:   Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site:   http://lists.radiantcms.org/mailman/listinfo/radiant

_______________________________________________
Radiant mailing list
Post:   Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site:   http://lists.radiantcms.org/mailman/listinfo/radiant

Reply via email to