[xwiki-devs] [PROPOSAL] Always store document names as fully qualified names
Hi devs, The real full qualified name of a document is wiki:Space.Page. I think we sould always use only this form for technical purposes like storing in database or old API which does not support DocumentName. pros: - don't need to take care of the context, the information is always right. - if everything is stored in only one form it's way easier to compare things and do requests cons: - old code which does not support this document name form will fail. This could hardly be a good arguments since this form is a officially valid document name but i can't see anything else. Among others, the last use case which make me send this proposal is http://jira.xwiki.org/jira/browse/XWIKI-3754. IMO getLinkedPages return and the link table should only contains fully qualified links, especially since theses lists are supposed to contains uniques documents and we need to know the 3 parts of the document name to make sure of that . Note that a document could contain a link to a document in another wiki or even a link to the same document but written in its full form so a code which support only local form is wrong anyway. WDYT ? Here is my +1. The pros are basically the same that make us introduce DocumentName to not manipulate String anymore in code. -- Thomas Mortagne
On May 6, 2009, at 12:34 PM, Thomas Mortagne wrote:
Hi devs,
The real full qualified name of a document is wiki:Space.Page. I think we sould always use only this form for technical purposes like storing in database or old API which does not support DocumentName.
pros: - don't need to take care of the context, the information is always right. - if everything is stored in only one form it's way easier to compare things and do requests
cons: - old code which does not support this document name form will fail. This could hardly be a good arguments since this form is a officially valid document name but i can't see anything else.
Among others, the last use case which make me send this proposal is http://jira.xwiki.org/jira/browse/XWIKI-3754. IMO getLinkedPages return and the link table should only contains fully qualified links, especially since theses lists are supposed to contains uniques documents and we need to know the 3 parts of the document name to make sure of that . Note that a document could contain a link to a document in another wiki or even a link to the same document but written in its full form so a code which support only local form is wrong anyway.
WDYT ?
Here is my +1. The pros are basically the same that make us introduce DocumentName to not manipulate String anymore in code.
+1 to do this in 2.0 time frame since 1.9 is going to be in RC mode tomorrow. Thanks -Vincent
Thomas Mortagne wrote:
Hi devs,
The real full qualified name of a document is wiki:Space.Page. I think we sould always use only this form for technical purposes like storing in database or old API which does not support DocumentName.
pros: - don't need to take care of the context, the information is always right. - if everything is stored in only one form it's way easier to compare things and do requests
cons: - old code which does not support this document name form will fail. This could hardly be a good arguments since this form is a officially valid document name but i can't see anything else.
Among others, the last use case which make me send this proposal is http://jira.xwiki.org/jira/browse/XWIKI-3754. IMO getLinkedPages return and the link table should only contains fully qualified links, especially since theses lists are supposed to contains uniques documents and we need to know the 3 parts of the document name to make sure of that . Note that a document could contain a link to a document in another wiki or even a link to the same document but written in its full form so a code which support only local form is wrong anyway.
WDYT ?
+1, 1.9 looks like a good place to break the old behaviour. although for a single wiki (non-multiwiki environment) this full form will always be a little too much, since the wiki prefix is redundant. Also, I think the doc.fullName should be consistent with this (ftm it seems to return Space.Page). Happy coding, Anca
Here is my +1. The pros are basically the same that make us introduce DocumentName to not manipulate String anymore in code.
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
I'm -1 on this. This is like saying we should put the fully qualified name when - linking to an anchor in your page - linking to a page in the same space We should always store information as "relative". If a document is in the same wiki then you should not specify the wiki. If it is in the same space you should not specify the space. Imaging you want to export/import a wiki that was in a farm in a database names 'wiki1' and you import the pages in a farm where the database is names 'wiki2'. Then your import process will have to run conversions, or you wiki will be fully broken. I'm for generalizing "relative" storage if there are places where we hard code the wiki name or the space name. Ludovic Thomas Mortagne a écrit :
Hi devs,
The real full qualified name of a document is wiki:Space.Page. I think we sould always use only this form for technical purposes like storing in database or old API which does not support DocumentName.
pros: - don't need to take care of the context, the information is always right. - if everything is stored in only one form it's way easier to compare things and do requests
cons: - old code which does not support this document name form will fail. This could hardly be a good arguments since this form is a officially valid document name but i can't see anything else.
Among others, the last use case which make me send this proposal is http://jira.xwiki.org/jira/browse/XWIKI-3754. IMO getLinkedPages return and the link table should only contains fully qualified links, especially since theses lists are supposed to contains uniques documents and we need to know the 3 parts of the document name to make sure of that . Note that a document could contain a link to a document in another wiki or even a link to the same document but written in its full form so a code which support only local form is wrong anyway.
WDYT ?
Here is my +1. The pros are basically the same that make us introduce DocumentName to not manipulate String anymore in code.
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
Ludovic Dubost wrote:
I'm -1 on this.
This is like saying we should put the fully qualified name when
- linking to an anchor in your page - linking to a page in the same space
We should always store information as "relative". If a document is in the same wiki then you should not specify the wiki. If it is in the same space you should not specify the space.
Imaging you want to export/import a wiki that was in a farm in a database names 'wiki1' and you import the pages in a farm where the database is names 'wiki2'. Then your import process will have to run conversions, or you wiki will be fully broken.
I think the proposal was to use the fully qualified name _for technical aspects_. In pages (and anything that involves user) we should accept all kind of links, and yes, relative should be the default (therefore export / import would work). This is almost the same issue with links to pages in the same space, whose relativity can become problematic on documents copy. The only problem I see now, in this light, is if you wanted to dump the database wiki1 and create a new one (wiki2) from the dump, in which case any backlinks stored as wiki1:space.page will fail. It is indeed a redundancy issue, I'm having second thoughts about the idea...
I'm for generalizing "relative" storage if there are places where we hard code the wiki name or the space name.
Ludovic
Thomas Mortagne a écrit :
Hi devs,
The real full qualified name of a document is wiki:Space.Page. I think we sould always use only this form for technical purposes like storing in database or old API which does not support DocumentName.
pros: - don't need to take care of the context, the information is always right. - if everything is stored in only one form it's way easier to compare things and do requests
cons: - old code which does not support this document name form will fail. This could hardly be a good arguments since this form is a officially valid document name but i can't see anything else.
Among others, the last use case which make me send this proposal is http://jira.xwiki.org/jira/browse/XWIKI-3754. IMO getLinkedPages return and the link table should only contains fully qualified links, especially since theses lists are supposed to contains uniques documents and we need to know the 3 parts of the document name to make sure of that . Note that a document could contain a link to a document in another wiki or even a link to the same document but written in its full form so a code which support only local form is wrong anyway.
WDYT ?
Here is my +1. The pros are basically the same that make us introduce DocumentName to not manipulate String anymore in code.
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Anca Paula Luca wrote:
Ludovic Dubost wrote:
I'm -1 on this.
This is like saying we should put the fully qualified name when
- linking to an anchor in your page - linking to a page in the same space
We should always store information as "relative". If a document is in the same wiki then you should not specify the wiki. If it is in the same space you should not specify the space.
Imaging you want to export/import a wiki that was in a farm in a database names 'wiki1' and you import the pages in a farm where the database is names 'wiki2'. Then your import process will have to run conversions, or you wiki will be fully broken.
I think the proposal was to use the fully qualified name _for technical aspects_.
Shouldn't we wait to introduce a document ID that isn't related to the location of the document? Moving a document shouldn't change it's ID and having the same document in multiple locations should be possible. Thanks, Marius
In pages (and anything that involves user) we should accept all kind of links, and yes, relative should be the default (therefore export / import would work).
This is almost the same issue with links to pages in the same space, whose relativity can become problematic on documents copy.
The only problem I see now, in this light, is if you wanted to dump the database wiki1 and create a new one (wiki2) from the dump, in which case any backlinks stored as wiki1:space.page will fail. It is indeed a redundancy issue, I'm having second thoughts about the idea...
I'm for generalizing "relative" storage if there are places where we hard code the wiki name or the space name.
Ludovic
Thomas Mortagne a écrit :
Hi devs,
The real full qualified name of a document is wiki:Space.Page. I think we sould always use only this form for technical purposes like storing in database or old API which does not support DocumentName.
pros: - don't need to take care of the context, the information is always right. - if everything is stored in only one form it's way easier to compare things and do requests
cons: - old code which does not support this document name form will fail. This could hardly be a good arguments since this form is a officially valid document name but i can't see anything else.
Among others, the last use case which make me send this proposal is http://jira.xwiki.org/jira/browse/XWIKI-3754. IMO getLinkedPages return and the link table should only contains fully qualified links, especially since theses lists are supposed to contains uniques documents and we need to know the 3 parts of the document name to make sure of that . Note that a document could contain a link to a document in another wiki or even a link to the same document but written in its full form so a code which support only local form is wrong anyway.
WDYT ?
Here is my +1. The pros are basically the same that make us introduce DocumentName to not manipulate String anymore in code.
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Wed, May 6, 2009 at 17:09, Ludovic Dubost <[email protected]> wrote:
I'm -1 on this.
This is like saying we should put the fully qualified name when
- linking to an anchor in your page - linking to a page in the same space
This example as nothing to do with what i suggest since this is user input and not technical generated datas. I'm speaking about internal generated datas, datas you don't find in the export, the link table is not exported etc...
We should always store information as "relative". If a document is in the same wiki then you should not specify the wiki. If it is in the same space you should not specify the space.
Imaging you want to export/import a wiki that was in a farm in a database names 'wiki1' and you import the pages in a farm where the database is names 'wiki2'. Then your import process will have to run conversions, or you wiki will be fully broken.
I'm for generalizing "relative" storage if there are places where we hard code the wiki name or the space name.
Ludovic
Thomas Mortagne a écrit :
Hi devs,
The real full qualified name of a document is wiki:Space.Page. I think we sould always use only this form for technical purposes like storing in database or old API which does not support DocumentName.
pros: - don't need to take care of the context, the information is always right. - if everything is stored in only one form it's way easier to compare things and do requests
cons: - old code which does not support this document name form will fail. This could hardly be a good arguments since this form is a officially valid document name but i can't see anything else.
Among others, the last use case which make me send this proposal is http://jira.xwiki.org/jira/browse/XWIKI-3754. IMO getLinkedPages return and the link table should only contains fully qualified links, especially since theses lists are supposed to contains uniques documents and we need to know the 3 parts of the document name to make sure of that . Note that a document could contain a link to a document in another wiki or even a link to the same document but written in its full form so a code which support only local form is wrong anyway.
WDYT ?
Here is my +1. The pros are basically the same that make us introduce DocumentName to not manipulate String anymore in code.
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
Thomas Mortagne a écrit :
On Wed, May 6, 2009 at 17:09, Ludovic Dubost <[email protected]> wrote:
I'm -1 on this.
This is like saying we should put the fully qualified name when
- linking to an anchor in your page - linking to a page in the same space
This example as nothing to do with what i suggest since this is user input and not technical generated datas. I'm speaking about internal generated datas, datas you don't find in the export, the link table is not exported etc...
I tend to think that what I say is true for any data. As Anca points out a mysql backup of the backlinks data with absolute links would not work if you recover it under another db name. Ludovic
We should always store information as "relative". If a document is in the same wiki then you should not specify the wiki. If it is in the same space you should not specify the space.
Imaging you want to export/import a wiki that was in a farm in a database names 'wiki1' and you import the pages in a farm where the database is names 'wiki2'. Then your import process will have to run conversions, or you wiki will be fully broken.
I'm for generalizing "relative" storage if there are places where we hard code the wiki name or the space name.
Ludovic
Thomas Mortagne a écrit :
Hi devs,
The real full qualified name of a document is wiki:Space.Page. I think we sould always use only this form for technical purposes like storing in database or old API which does not support DocumentName.
pros: - don't need to take care of the context, the information is always right. - if everything is stored in only one form it's way easier to compare things and do requests
cons: - old code which does not support this document name form will fail. This could hardly be a good arguments since this form is a officially valid document name but i can't see anything else.
Among others, the last use case which make me send this proposal is http://jira.xwiki.org/jira/browse/XWIKI-3754. IMO getLinkedPages return and the link table should only contains fully qualified links, especially since theses lists are supposed to contains uniques documents and we need to know the 3 parts of the document name to make sure of that . Note that a document could contain a link to a document in another wiki or even a link to the same document but written in its full form so a code which support only local form is wrong anyway.
WDYT ?
Here is my +1. The pros are basically the same that make us introduce DocumentName to not manipulate String anymore in code.
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
Hi, On Wed, May 6, 2009 at 6:31 PM, Ludovic Dubost <[email protected]> wrote:
Thomas Mortagne a écrit :
On Wed, May 6, 2009 at 17:09, Ludovic Dubost <[email protected]> wrote:
I'm -1 on this.
This is like saying we should put the fully qualified name when
- linking to an anchor in your page - linking to a page in the same space
This example as nothing to do with what i suggest since this is user input and not technical generated datas. I'm speaking about internal generated datas, datas you don't find in the export, the link table is not exported etc...
I tend to think that what I say is true for any data. As Anca points out a mysql backup of the backlinks data with absolute links would not work if you recover it under another db name.
There's maybe something I don't understand here, but isn't it better to have more data and run a filter to remove unnecessary data in specific cases if needed (such as the MySQL backup scenario decribed above) than to have too little data and to get stuck when trying to identify which wiki a given page belongs to? Would writing such a filter be complex? That is, it's easier to have too much data and to filter out the noise than the other way round, isn't it? Guillaume
Ludovic
We should always store information as "relative". If a document is in the same wiki then you should not specify the wiki. If it is in the same space you should not specify the space.
Imaging you want to export/import a wiki that was in a farm in a database names 'wiki1' and you import the pages in a farm where the database is names 'wiki2'. Then your import process will have to run conversions, or you wiki will be fully broken.
I'm for generalizing "relative" storage if there are places where we hard code the wiki name or the space name.
Ludovic
Thomas Mortagne a écrit :
Hi devs,
The real full qualified name of a document is wiki:Space.Page. I think we sould always use only this form for technical purposes like storing in database or old API which does not support DocumentName.
pros: - don't need to take care of the context, the information is always
right.
- if everything is stored in only one form it's way easier to compare things and do requests
cons: - old code which does not support this document name form will fail. This could hardly be a good arguments since this form is a officially valid document name but i can't see anything else.
Among others, the last use case which make me send this proposal is http://jira.xwiki.org/jira/browse/XWIKI-3754. IMO getLinkedPages return and the link table should only contains fully qualified links, especially since theses lists are supposed to contains uniques documents and we need to know the 3 parts of the document name to make sure of that . Note that a document could contain a link to a document in another wiki or even a link to the same document but written in its full form so a code which support only local form is wrong anyway.
WDYT ?
Here is my +1. The pros are basically the same that make us introduce DocumentName to not manipulate String anymore in code.
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://guillaumelerouge.com/
Guillaume Lerouge wrote:
Hi,
On Wed, May 6, 2009 at 6:31 PM, Ludovic Dubost <[email protected]> wrote:
Thomas Mortagne a écrit :
On Wed, May 6, 2009 at 17:09, Ludovic Dubost <[email protected]> wrote:
I'm -1 on this.
This is like saying we should put the fully qualified name when
- linking to an anchor in your page - linking to a page in the same space
This example as nothing to do with what i suggest since this is user input and not technical generated datas. I'm speaking about internal generated datas, datas you don't find in the export, the link table is not exported etc...
I tend to think that what I say is true for any data. As Anca points out a mysql backup of the backlinks data with absolute links would not work if you recover it under another db name.
There's maybe something I don't understand here, but isn't it better to have more data and run a filter to remove unnecessary data in specific cases if needed (such as the MySQL backup scenario decribed above) than to have too little data and to get stuck when trying to identify which wiki a given page belongs to? Would writing such a filter be complex?
That is, it's easier to have too much data and to filter out the noise than the other way round, isn't it?
Too less data is bad because, well, you don't have the data. Too much data is also wrong because, when it gets redundant (as it would be the case here), updating can become a pain, cause inconsistencies, bring you back to the first situation when you didn't have data (but this time only because it doesn't match and you don't know what's the real data). By default, redundancy is to be avoided, unless you know exactly what you're doing and it really improves performance. Anca
Guillaume
Ludovic
We should always store information as "relative". If a document is in the same wiki then you should not specify the wiki. If it is in the same space you should not specify the space.
Imaging you want to export/import a wiki that was in a farm in a database names 'wiki1' and you import the pages in a farm where the database is names 'wiki2'. Then your import process will have to run conversions, or you wiki will be fully broken.
I'm for generalizing "relative" storage if there are places where we hard code the wiki name or the space name.
Ludovic
Thomas Mortagne a écrit :
Hi devs,
The real full qualified name of a document is wiki:Space.Page. I think we sould always use only this form for technical purposes like storing in database or old API which does not support DocumentName.
pros: - don't need to take care of the context, the information is always right. - if everything is stored in only one form it's way easier to compare things and do requests
cons: - old code which does not support this document name form will fail. This could hardly be a good arguments since this form is a officially valid document name but i can't see anything else.
Among others, the last use case which make me send this proposal is http://jira.xwiki.org/jira/browse/XWIKI-3754. IMO getLinkedPages return and the link table should only contains fully qualified links, especially since theses lists are supposed to contains uniques documents and we need to know the 3 parts of the document name to make sure of that . Note that a document could contain a link to a document in another wiki or even a link to the same document but written in its full form so a code which support only local form is wrong anyway.
WDYT ?
Here is my +1. The pros are basically the same that make us introduce DocumentName to not manipulate String anymore in code.
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Anca Paula Luca a écrit :
Guillaume Lerouge wrote:
Hi,
On Wed, May 6, 2009 at 6:31 PM, Ludovic Dubost <[email protected]> wrote:
Thomas Mortagne a écrit :
On Wed, May 6, 2009 at 17:09, Ludovic Dubost <[email protected]> wrote:
I'm -1 on this.
This is like saying we should put the fully qualified name when
- linking to an anchor in your page - linking to a page in the same space
This example as nothing to do with what i suggest since this is user input and not technical generated datas. I'm speaking about internal generated datas, datas you don't find in the export, the link table is not exported etc...
I tend to think that what I say is true for any data. As Anca points out a mysql backup of the backlinks data with absolute links would not work if you recover it under another db name.
There's maybe something I don't understand here, but isn't it better to have more data and run a filter to remove unnecessary data in specific cases if needed (such as the MySQL backup scenario decribed above) than to have too little data and to get stuck when trying to identify which wiki a given page belongs to? Would writing such a filter be complex?
Whatever has to treat data if you import/export is going to be a pain.
In this specific case we would also need a migration since previously stored backlinks data was NOT including the wiki name. And code based on the fact that it's not there will fail.
That is, it's easier to have too much data and to filter out the noise than the other way round, isn't it?
Too less data is bad because, well, you don't have the data. Too much data is also wrong because, when it gets redundant (as it would be the case here), updating can become a pain, cause inconsistencies, bring you back to the first situation when you didn't have data (but this time only because it doesn't match and you don't know what's the real data). By default, redundancy is to be avoided, unless you know exactly what you're doing and it really improves performance.
exactly. We already know in which wiki we are. No need to repeat it everywhere. If you do you'll have to run script to modify it if you change the wiki name.
Anca
Guillaume
Ludovic
We should always store information as "relative". If a document is in the same wiki then you should not specify the wiki. If it is in the same space you should not specify the space.
Imaging you want to export/import a wiki that was in a farm in a database names 'wiki1' and you import the pages in a farm where the database is names 'wiki2'. Then your import process will have to run conversions, or you wiki will be fully broken.
I'm for generalizing "relative" storage if there are places where we hard code the wiki name or the space name.
Ludovic
Thomas Mortagne a écrit :
Hi devs,
The real full qualified name of a document is wiki:Space.Page. I think we sould always use only this form for technical purposes like storing in database or old API which does not support DocumentName.
pros: - don't need to take care of the context, the information is always
right.
- if everything is stored in only one form it's way easier to compare things and do requests
cons: - old code which does not support this document name form will fail. This could hardly be a good arguments since this form is a officially valid document name but i can't see anything else.
Among others, the last use case which make me send this proposal is http://jira.xwiki.org/jira/browse/XWIKI-3754. IMO getLinkedPages return and the link table should only contains fully qualified links, especially since theses lists are supposed to contains uniques documents and we need to know the 3 parts of the document name to make sure of that . Note that a document could contain a link to a document in another wiki or even a link to the same document but written in its full form so a code which support only local form is wrong anyway.
WDYT ?
Here is my +1. The pros are basically the same that make us introduce DocumentName to not manipulate String anymore in code.
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
Hi, I'm just getting started with xwiki development and could use a little guidance. The docs talk about components and 'plugins'. It would appear that 'components' are replacing plugins? For my application I need to have a servlet interface for external access as well as a macro for special rendering within the wiki. Also, the component DevGuide - http://platform.xwiki.org/xwiki/bin/view/DevGuide/WritingComponents says that the dev team is working on a new VelocityBridge technique but the 'plugin' example seems a lot easier. Should I be using the component example or the plugin example? Can someone point me to an example of a 'component' or 'plugin' that might do something similar for learning purposes? Thanks, Glenn
Guillaume Lerouge wrote:
Hi,
On Wed, May 6, 2009 at 6:31 PM, Ludovic Dubost <[email protected]> wrote:
Thomas Mortagne a écrit :
On Wed, May 6, 2009 at 17:09, Ludovic Dubost <[email protected]> wrote:
I'm -1 on this.
This is like saying we should put the fully qualified name when
- linking to an anchor in your page - linking to a page in the same space
This example as nothing to do with what i suggest since this is user input and not technical generated datas. I'm speaking about internal generated datas, datas you don't find in the export, the link table is not exported etc...
I tend to think that what I say is true for any data. As Anca points out a mysql backup of the backlinks data with absolute links would not work if you recover it under another db name.
There's maybe something I don't understand here, but isn't it better to have more data and run a filter to remove unnecessary data in specific cases if needed (such as the MySQL backup scenario decribed above) than to have too little data and to get stuck when trying to identify which wiki a given page belongs to? Would writing such a filter be complex?
That is, it's easier to have too much data and to filter out the noise than the other way round, isn't it?
Having the wiki and space name doesn't necessarily mean you have more data *but* in fact it locks you to a specific context. Relative paths are useful because you can change the context and still have your thing working. When I link to a page in the same space I don't care at all what's the space or wiki name. They can change as long as both pages remain in the same space. Thus I'm -0. Thanks, Marius
Guillaume
Ludovic
We should always store information as "relative". If a document is in the same wiki then you should not specify the wiki. If it is in the same space you should not specify the space.
Imaging you want to export/import a wiki that was in a farm in a database names 'wiki1' and you import the pages in a farm where the database is names 'wiki2'. Then your import process will have to run conversions, or you wiki will be fully broken.
I'm for generalizing "relative" storage if there are places where we hard code the wiki name or the space name.
Ludovic
Thomas Mortagne a écrit :
Hi devs,
The real full qualified name of a document is wiki:Space.Page. I think we sould always use only this form for technical purposes like storing in database or old API which does not support DocumentName.
pros: - don't need to take care of the context, the information is always right. - if everything is stored in only one form it's way easier to compare things and do requests
cons: - old code which does not support this document name form will fail. This could hardly be a good arguments since this form is a officially valid document name but i can't see anything else.
Among others, the last use case which make me send this proposal is http://jira.xwiki.org/jira/browse/XWIKI-3754. IMO getLinkedPages return and the link table should only contains fully qualified links, especially since theses lists are supposed to contains uniques documents and we need to know the 3 parts of the document name to make sure of that . Note that a document could contain a link to a document in another wiki or even a link to the same document but written in its full form so a code which support only local form is wrong anyway.
WDYT ?
Here is my +1. The pros are basically the same that make us introduce DocumentName to not manipulate String anymore in code.
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On May 6, 2009, at 6:31 PM, Ludovic Dubost wrote:
Thomas Mortagne a écrit :
On Wed, May 6, 2009 at 17:09, Ludovic Dubost <[email protected]> wrote:
I'm -1 on this.
This is like saying we should put the fully qualified name when
- linking to an anchor in your page - linking to a page in the same space
This example as nothing to do with what i suggest since this is user input and not technical generated datas. I'm speaking about internal generated datas, datas you don't find in the export, the link table is not exported etc...
I tend to think that what I say is true for any data. As Anca points out a mysql backup of the backlinks data with absolute links would not work if you recover it under another db name.
Note: If you create links to other wikis and these other wikis change their name in the database you'll have the same problem (i.e. you'll need to run some script to modify the link names). -Vincent
We should always store information as "relative". If a document is in the same wiki then you should not specify the wiki. If it is in the same space you should not specify the space.
Imaging you want to export/import a wiki that was in a farm in a database names 'wiki1' and you import the pages in a farm where the database is names 'wiki2'. Then your import process will have to run conversions, or you wiki will be fully broken.
I'm for generalizing "relative" storage if there are places where we hard code the wiki name or the space name.
Ludovic
Thomas Mortagne a écrit :
Hi devs,
The real full qualified name of a document is wiki:Space.Page. I think we sould always use only this form for technical purposes like storing in database or old API which does not support DocumentName.
pros: - don't need to take care of the context, the information is always right. - if everything is stored in only one form it's way easier to compare things and do requests
cons: - old code which does not support this document name form will fail. This could hardly be a good arguments since this form is a officially valid document name but i can't see anything else.
Among others, the last use case which make me send this proposal is http://jira.xwiki.org/jira/browse/XWIKI-3754. IMO getLinkedPages return and the link table should only contains fully qualified links, especially since theses lists are supposed to contains uniques documents and we need to know the 3 parts of the document name to make sure of that . Note that a document could contain a link to a document in another wiki or even a link to the same document but written in its full form so a code which support only local form is wrong anyway.
WDYT ?
Here is my +1. The pros are basically the same that make us introduce DocumentName to not manipulate String anymore in code.
-- Thomas Mortagne
participants (7)
-
Anca Paula Luca -
glenn_engel＠agilent.com -
Guillaume Lerouge -
Ludovic Dubost -
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol