[xwiki-devs] [Proposal] Introduce relative references for XWikiDocument's parent ref and XObject's XClass ref
Hi, Discussing with Thomas today we think we need to use relative refs in XWikiDocument for storing the Parent reference and in XObject (BaseCollection to be precise) to store the XClass reference. The rationales are: * the copy wiki use case: Imagine that you've set a relative parent reference in the UI, you'll want that the copied document retains the relativity * have the same behavior as relative links in document contents. * we had this feature and lost it during the reference refactoring in XE 2.2. Regarding the implementation the idea is to: * store relative reference using the EntityReference class and to introduce a RelativeStringEntityReferenceResolver class. * modify the XWikiDocument's javadoc to deprecate setDocumentReference and all setXXX that change the reference since XWikiDocument should be immutable re its reference (the storage impl today doesn't support a XWikiDocument that has its reference that is modified). Let me know if you see a problem. I'm starting to implement this. Thanks -Vincent
On 03/05/2010 04:18 PM, Vincent Massol wrote:
Hi,
Discussing with Thomas today we think we need to use relative refs in XWikiDocument for storing the Parent reference and in XObject (BaseCollection to be precise) to store the XClass reference.
The rationales are: * the copy wiki use case: Imagine that you've set a relative parent reference in the UI, you'll want that the copied document retains the relativity * have the same behavior as relative links in document contents. * we had this feature and lost it during the reference refactoring in XE 2.2.
Regarding the implementation the idea is to: * store relative reference using the EntityReference class and to introduce a RelativeStringEntityReferenceResolver class.
+1
* modify the XWikiDocument's javadoc to deprecate setDocumentReference and all setXXX that change the reference since XWikiDocument should be immutable re its reference (the storage impl today doesn't support a XWikiDocument that has its reference that is modified).
+1. Too bad, deprecating a method so recently introduced...
Let me know if you see a problem. I'm starting to implement this.
Thanks -Vincent
-- Sergiu Dumitriu http://purl.org/net/sergiu/
On Fri, Mar 5, 2010 at 19:30, Sergiu Dumitriu <[email protected]> wrote:
On 03/05/2010 04:18 PM, Vincent Massol wrote:
Hi,
Discussing with Thomas today we think we need to use relative refs in XWikiDocument for storing the Parent reference and in XObject (BaseCollection to be precise) to store the XClass reference.
The rationales are: * the copy wiki use case: Imagine that you've set a relative parent reference in the UI, you'll want that the copied document retains the relativity * have the same behavior as relative links in document contents. * we had this feature and lost it during the reference refactoring in XE 2.2.
Regarding the implementation the idea is to: * store relative reference using the EntityReference class and to introduce a RelativeStringEntityReferenceResolver class.
+1
* modify the XWikiDocument's javadoc to deprecate setDocumentReference and all setXXX that change the reference since XWikiDocument should be immutable re its reference (the storage impl today doesn't support a XWikiDocument that has its reference that is modified).
+1. Too bad, deprecating a method so recently introduced...
Let me know if you see a problem. I'm starting to implement this.
Well, I think the problem goes beyond what you had mentioned, and I suggest or would like to ensure that relative references will be extended to these case as well: - Document has a TreeMap of vectors to collect their objects by XClass (XWikiDocument#xObjects). Currently, this map is a dictionary of absolute reference that is not cloned properly between 2 wikis. - Document has reference to template, currently unused, but these are not properly cloned either - Object has a reference back to their document, these are not clone properly when object are clone during document cloning All these are blocker issue for at least proper functioning of XEM 2.2.2. All these reference(s) are currently persisted without reference to their database which makes storage inconsistent with implementation. I also suggest that these issue be immediately mentioned in JIRA until they are fixed, and linked altogether as a blocker issue for proper functioning of template wiki cloning in XEM to prevent any disappointment for those that are currently migrating. I really hope that we can get rid of these issues very quickly. Aside of that, I just wonder why the relative nature of most references were not been notice earlier, since humans and the old string references are relative by nature. It is also currently not so easy to resolve/serialize a reference relatively to another reference chosen arbitrary, which seems to me the general case of the existing Default and Current reference resolver/serializer. Is context switching really a solid and good way to use the current serializer/resolver to solve that ? I am not convince and I had already written a dedicated resolver in my own application. I imagine that my use case is not unique in XWiki application development. Denis -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
participants (3)
-
Denis Gervalle -
Sergiu Dumitriu -
Vincent Massol