7 May
2009
7 May
'09
5:56 p.m.
Anca Paula Luca wrote:
Ludovic Dubost wrote:
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
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 :
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs