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