[xwiki-devs] [Proposal] New tool to sanitize XE wiki XML docs and force dates to control XE distribution initial "Recent Changes" list order
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 ? Jerome.
On Mon, Feb 2, 2009 at 1:13 PM, Jerome Velociter <[email protected]> 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.
-1 for apply priority in application modules, it's a XE need and not application need so it should be done at XE level. Anyway having the right documents in the Recent Changes by forcing their dates at build time it not cleaner that referencing pages from XE dependencies in XE...
WDYT ?
Jerome.
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
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). 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. Thanks -Vincent
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.
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
Jean-Vincent Drean 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").
Sounds better indeed. With a message in the spirit of "There are no recent changes yet, when you'll start editing pages you'll see your modification appear here". +1 for this.
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
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)
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). FYIW it actually would be possible. If we release early in the morning from Paris and somebody from a time zone more west (say San Francisco) downloads and starts editing right away :P
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 ?
Jerome.
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (4)
-
Jean-Vincent Drean -
Jerome Velociter -
Thomas Mortagne -
Vincent Massol