On Mon, Feb 2, 2009 at 1:48 PM, Jean-Vincent Drean <[email protected]> wrote: > 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").
+1 for not showing any Recent Changing in a fresh XE. But I don't think forcing import as minor edit is right. > >> 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 > -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
