On Mon, Feb 2, 2009 at 1:42 PM, Vincent Massol <[email protected]> wrote:
>
> On Feb 2, 2009, at 1:13 PM, Jerome Velociter wrote:
>
>> 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)
>

+1

>
>> 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).

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").

> 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.
>
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs

Reply via email to