On Thu, Dec 17, 2009 at 13:35, Vincent Massol <[email protected]> wrote:
On Dec 15, 2009, at 9:01 PM, Thomas Mortagne wrote:
On Tue, Dec 15, 2009 at 20:39, Thomas Mortagne <[email protected]> wrote:
On Tue, Dec 15, 2009 at 19:02, Vincent Massol <[email protected]> wrote:
On Dec 15, 2009, at 6:39 PM, Thomas Mortagne wrote:
On Tue, Dec 15, 2009 at 15:40, Vincent Massol <[email protected]> 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)
And what does it would mean in the model ? Document(Space.Page) |__ DocumentTranslation(Space.Page.en) |__ DocumentTranslation(Space.Page.fr) |__ Object Document(Space.Page) |__ DocumentTranslation(Space.Page.en) |__ Object |__ DocumentTranslation(Space.Page.fr) |__ Object Document(Space.Page.en) |__ Object Document(Space.Page.fr) |__ Object [...] ?
Notes: - It wouldn't be in the constructor since it's optional (when not specified, the default language would be used).
What about the current language instead ? I makes a lot easier for an application to handle languages without having to take about it.
- 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.
Big +1 for Locale
- 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).
It's a locale so it should be get/setLocale(Locale) IMO
WDYT?
Thanks -Vincent
[snip]
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne