2 Feb
2009
2 Feb
'09
1:48 p.m.
On Mon, Feb 2, 2009 at 1:42 PM, Vincent Massol <vincent(a)massol.net> wrote:
We could add a "silent" option to our XARs (+ having the option at the
import time) making the importer set the "minor" field to true in
imported documents.
This way Recent changes wouldn't display anything after installing the
default xar (they'd be visible after a click on "show minor edits").
On Feb 2, 2009, at 1:13 PM, Jerome Velociter wrote:
+1
Hello devs,
Here's a proposal for a new maven mojo based on the xmldoc-update tool
(http://jira.xwiki.org/jira/browse/XTXMLDOC).
The objective would be to :
1. Sanitize XML docs :
* Force creator, author and contentAuthor to "XWiki.Admin"
* Foce version to 1.1
* Maybe check the language and translation fields (although, there is
less reasons for those to be wrong)
* Force creationDate, contentUpdateDate, date (+ see below)
2. Control the order we want for the doc list
appearing on the "Recent
Changes" UI (on the wiki home page, one of the first thing users
see) on
fresh distributions, by forcing modification dates to desired values
so
that the list reflects what we want to appear here.
There are several approaches to do 2), I thought about the following :
By default, we force all documents to 00:00 on the current day. For
documents we want to appear up in the list, we specify them a priority
in the build configuration, for example on a scale of 1 to 100, 100
being the top priority. When forcing the date with the mojo, we add
X *
N units of time to 00:00, where X is the priority and N is for
example 1
second.
If all the document modification dates span maximum 100 seconds
starting
at 00:00, there's close to zero risk to run a wiki with modification
in
the future (which would make a document modified for real before this
future becomes present not appear on top of the list).
A constraint to keep in mind :
Wiki docs are spread accross applications. I don't think we want to
necessarily release all applications when releasing XE, so this should
ideally happen in XE's wiki module build. The drawback would be that
if
we want to give priority to pages that are in applications, we
reference
files from other modules, which is not clean. The alternative is to
give
priority to documents in the module they are hosted, and release all
applications every time we release XE.
WDYT ?
Note that changing dates will cause a problem in the future when we
have the extension manager since merging an existing installation with
a newer XAR will detect changes for all docs since they've had their
dates changed.
I'm still unsure about this need to control changes. It doesn't sound
natural to me and a bit contrived. So right now I'm -0 but close to -1.
Maybe we should only start changes when the user starts to make
changes in his wiki (would need to decide how we handle imports). If all we're interested in are to point the user
to important places
in the wiki then we could do it differently, using the quick links
panel or by introducing the rating feature and pre-marking some pages
as important and then having a panel or a dashboard place for
displaying top 5 rated pages.