On Dec 15, 2009, at 9:01 PM, Thomas Mortagne wrote: > On Tue, Dec 15, 2009 at 20:39, Thomas Mortagne > <thomas.morta...@xwiki.com> wrote: >> On Tue, Dec 15, 2009 at 19:02, Vincent Massol <vinc...@massol.net> >> wrote: >>> >>> On Dec 15, 2009, at 6:39 PM, Thomas Mortagne wrote: >>> >>>> On Tue, Dec 15, 2009 at 15:40, Vincent Massol <vinc...@massol.net> >>>> wrote: >>>>> Hi, >>>>> >>>>> I'd like to propose a refactoring for >>>>> org.xwiki.model.DocumentName/ >>>>> AttachmentName. >>>>> >>>>> There are currently 2 problems with the current implementation: >>>>> - DocumentName doesn't support nested spaces (we need that for the >>>>> future) >>>>> - We need to generalize the concept of resource names so that we >>>>> can >>>>> use the generic concept in the Model in some APIs >>>>> >>>>> Thus I'd like to propose: >>>>> >>>>> enum ResourceType >>>>> - WIKI, DOCUMENT, SPACE, ATTACHMENT > > Side note: what about the language part ? We need to starting thinking > of it, it mainly depends of how we see it in the new model. Is it part > of the model between documents and objects nodes or is it at the same > level than objects as direct children of the document ?
It's a difficult question. I have thought quite a lot about it this morning (even changing my mind) and my latest opinion is that we should have the language part of the reference/path/name. One thing that convinced me is that I'd like that all our model APIs are compatible with the JCR specification and in JCR the language would be a Node and thus would appear in the path. OTOH the version wouldn't appear in the path in JCR since versions are handled for all versionable Nodes and is thus a cross-cutting concern. I suggest we do the same. I don't think we should go as far as having a ResourceName for the Language though so I'd like to propose: DocumentName - get/setLocale(Locale locale) Notes: - It wouldn't be in the constructor since it's optional (when not specified, the default language would be used). - Also note the use of Locale which IMO is much better than using a String (since for example "fr" can be for France, for Canada, for Belgium, etc). In our backward-compatible implementation we'd use only the language part probably since that's what's currently supported. - I'm hesitating between get/setLocale(Locale) and get/ setLanguage(Locale) but the pb is Locale.getLanguage() will be misleading vs get/setLanguage()(the same term "language" is used to represent different things). WDYT? Thanks -Vincent [snip] _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
