On Tue, Dec 15, 2009 at 20:39, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
On Tue, Dec 15, 2009 at 19:02, Vincent Massol
<vincent(a)massol.net>
wrote:
>
> On Dec 15, 2009, at 6:39 PM, Thomas Mortagne wrote:
>
>> On Tue, Dec 15, 2009 at 15:40, Vincent Massol <vincent(a)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]