Vincent Massol wrote:
In the new rendering code I need to call some code that transforms [[[wiki:][Space.]][Doc]] into a link. I'm proposing to introduce 2 new classes/components in Core:
* DocumentName: Represents a Document's Name. It'll have 3 properties: - String wiki - String space - String page
+1
* DocumentNameFactory: Create a DocumentName from a string representing a Document's name. Transforms [[[wiki:][Space.]][Doc]] into a DocumentName object.
+1
* The DocumentNameFactory would depend on the Execution component so that it can use the current wiki, current space and current document if these are not specified.
+1
* This raises the question as to whether we should continue passing a String representing a document name in our APIs in the future or instead pass a DocumentName. I'm not yet sure what is the best answer to this...
DocumentName whenever possible.
* Other question: In the Document object do we store the DocumentName object or do we store instead only Space and Wiki objects? If it's the latter then we need to fetch them from the DB which takes time. We could also decide to only fetch them when requested with getSpace() and getWiki() (i.e. lazy loading).
* BTW this also raises the question as to whether we want to have a representation for space and wiki or not and instead only use tags, in which case a document name is simply a String like "mypage". But then it should be unique. So it could also be made of a list of identity tags as in: "space=sp1,sp2:wiki:wiki1:language=fr:mypage". Or we could standardize it as "wiki1:sp1,sp2:fr:mypage" and have the DocumentNameFactory transform it into tags. In that case the DocumentName object would be a Map of tags + the document name ("mypage"). I think we need to decide ASAP if we want to keep the strict and hardcoded notion of Wiki>Space>Document>Object>Property or instead go full tags since this changes completely the v2 interfaces and code we're writing.
+0.5 for tags. I think we could emulate current Space concept via hierarchy tags. But we should keep user tags. -- Artem Melentyev