Vincent, Christophe:
I think I've got a better idea of what he's asking, because (if indeed I
do understand it) it's an issue I've faced before. Many modifications
of a document may pass before a review approves one revision as an
official "version". Just as individual commits do not make a release of
a source tree, individual edits to a document are not approved as
official versions, but instead are packaged into a release with an
independent namespace.
So I think you've got it right from one point of view, but I'd approach
the problem differently:
The XWiki versioning records what it should record, which is "what
changed the last time the document was edited; who did it; when they did
it". That information is important, and it should certainly be kept.
The versioning that Christophe needs says "what changed *since the last
approved version*; who approved *this version*; when they *approved* it;
plus an explanation of the reasons for, and/or a characterization of,
the changes".
In summary, XWiki's versioning records the results of individual
*edits*; Christophe's need is a record of *approved versions*. They are
similar in nature, but not identical; the real discriminant here is that
they the result from different actions: changing the document versus
sealing the final result of all changes since the last version and
giving it an incremented version number.
Thus, my approach would not require changing XWiki's internals at all,
but instead, adding objects to your versioned pages. For those
permitted to "validate" (I'm guessing that this refers to the act of
reviewing and approving) a document, the view template could include a
form that populated an object of a new class (I'll call mine
VersionApprovalClass) which will contain all of the information about
the validated version. The information that can be gained from the
document itself, such as the last author and date, will not be in the
object itself but inferred from the document's current XWiki version
available as $doc.version. Also, if the date of the approval is
required (as distinct from the timestamp of the approved XWiki version),
it should be included as well. That may not be strictly necessary,
since the addition of the object also revs the document, but I don't
think it's a straightforward process to find which revision of a
document added an object.
Of all this information, only the comments field (and possibly the
"official" version number, depending on how it is determined) need to be
entered by the user. Thus, when a validator reviews a document, [s]he
will be view a completed document version, then, if appropriate, will
enter a version comment (and the new version number if it's not
automatically determined) and submit the form. To find an validated
version of a document, a link could be added to the view template to
display document history, in a similar fashion to the XWiki history
template, but instead of listing the document's own history you would
list the validated versions, displaying document information and
offering diffs only among the specific versions that were validated.
To see how to add objects to a document, look at the comments.vm
templates; to create a new XWiki class, use the document
XWiki.XWikiClasses.
brain[sic]
-----Original Message-----
From: Vincent Massol [mailto:vincent@massol.net]
Sent: Tuesday, April 03, 2007 12:08 PM
To: xwiki-users(a)objectweb.org
Subject: Re: [xwiki-users] [Proposal] A system to manually
manage the state of the wiki page (version, redactor,
comment, validation, ...)
Hi Christophe,
Does your email means you're proposing to implement this?
(I'm referring to the "Proposal" in the subject line)
Also you did not describe how to implement what you suggest.
Could you be more specific?
If I understand your email, you're suggesting to decouple
document state from document storage. For example, document's
content could still be managed using XWikiHibernateStorage
but document's states could be managed by, say some custom
tool. Hmm.... I'm not entirely convinced. I think it'll raise
several issues, one of which is distributed transactions.
Another one is performances.
To implement your use case you could also intercept document
save using the XWiki Notification Service and save your own
document state as you want it.
Not sure exactly what you're looking for with your email...
Thanks
-Vincent
On Apr 3, 2007, at 6:42 PM, Christophe Koehl wrote:
Hello the xwiki community,
We use Xwiki for a couple of years now as a tool for
managing our IT
projects.
During the redaction of the main project documents, we have
a strong
need of versionning management - not the xwiki
system, but our own
one.
To be clear, when a wiki page is written some information can be
included in it :
* Document version
* Name of the redactor
* Date of the modification
* Name of validator
* Comment
In fact, the xwiki system contains almost all the components, but
those information are updated each time a modification is
being done,
even when the document is a draft and has not be
validated.
For example, the xwiki version number is automatically incremented
whereas the real document version number is still the same.
So it can very very useful to integrate a system which can
be able to
manage manually the different state of the
document.
Regards
Christophe Koehl
From - Mon
.org/wws