8 Mar
2010
8 Mar
'10
10:43 p.m.
On Fri, Mar 5, 2010 at 19:30, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
On 03/05/2010 04:18 PM, Vincent Massol wrote:
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
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.