On 1/5/06, Andreas Hartmann <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > With the move to JCR, structuring content by workflow state will add > > complexity to the repository without adding any value. I expect the > > structure to be Content/Document/Version. Workflow state is just a > > property. Document has CurrentLiveVersion and CurrentEditVersion > > properties. Versions have Created, LastEdited, and LastPublished and > > other properties for Workflow. Publishing is just changing the > > CurrentLiveVersion. > <quote person="Felix Roethenbacher"> > How is versioning of different areas handled? I think of a live > area which I can easily revert if something bad happend during > publishing. Same applies to the authoring area. I can't see > how it's accomplished to get a snapshot of both > live and authoring area with a certain time stamp. > </quote> > I also suggested the approach you're mentioning, but I share Felix' > concerns. It has to be possible to restore a certain state from the > history of the live area.
First, it should be even more rare when "something bad happens during publishing", since publishing changes a property rather than copying files, but just change the Document's CurrentLiveVersion to a different version (basically publishing an older version, possibly bypassing the history functions.) Restoration/Rollback has many options with this approach. 1. OS Backups 2. Documents have history of live versions. Publish the one that was live on the desired date. - There could also be a history of "edit" versions. Even if we do not store the "edit" history, it could be recreated from the history information stored in the Versions. There will be several Views of versions of a Document: Live history, Edit History, By CreationDate, even Threaded Views that shows the relationships: each Version is the parent or child of the Version it was based. For most Documents, the thread is linear, but this could be useful for a Document that often is replaced from older Versions, like the "Next Holiday" page. This year's "Easter" version could be based on last year's "Easter" version rather than the current page. This View would make the forking obvious. 3. To rollback the entire (or a section of a) publication, Publish all documents based on the live date. This must decide what to do if the previous version was deleted: should it use the next older or newer document (and log the issue)? Also, what if approval was revoked for a Version? Are we rolling back for historical purposes, or should the workflow rules be obeyed for production? I can design the RollbackAll function, but I cannot think why it would be used. 4. Snapshots of "live" and/or "authoring" can be created easily with the new "Process Multiple Documents" framework. CreateSnapshot() creates a new repository with just the desired Documents. Or exports them as XML files. Or whatever. Removing the concept of Workflow Areas makes the structure much more flexible. It should also be more stable. Isn't that why we are moving to JCR? solprovider --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
