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