Hi,
Here's what I'm thinking of each pros and cons:
[link picker compound]
- stored as child node under document variant node. in hst, you can access those through #getLinkedBean*()
- pros: maybe more natural from model perspective because a link itself exists in its own form, so perhaps there is a good use case in the future with the link node itself?
- cons: when a document contains a lot of compound nodes, it could cause performance issue when reading the document and more memory consumption in internal caching because jcr caching is basically based on caching per node bundle. Having many child nodes means more separate cache items, also resulting in multiple hits on the backend.
[docbase]
- stored as string property. in hst, you can access those through #getBeanByUUID() from each uuid value
- pros: more performant and more lightweight because every compound data is stored in the same document variant node.
- cons: application code should handle the uuid by itself even if hst provided a good utility to convert it to bean, conceptually speaking, not based on model structure.
Regards,
Woonsan