Hi,
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
* DocumentNameFactory: Create a DocumentName from a string
representing a Document's name. Transforms [[[wiki:][Space.]][Doc]]
into a DocumentName object.
* 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.
* 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...
* 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.
Let me know what you think.
Thanks
-Vincent
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
