thank you for your help.
1. sounds easier to implement. But I have problems to understand the Terms and Conceptuality.
Maybe your «custom-documents» are close to my «cumbersome solution»?
My solution is a custom DocumentType:
Would this correspondent to your custom-document?
This created data-set (as document) I can choose somewhere else with my nodeType «Collector».
The bigBIG draw-back of this approach: tree-flooding with a lot of small data-junks.
For ReferenceEditor I have to store one record in one DataContainerPage. Otherwise Editor's can't select each record for its own with an easy to understand solution (not with copy/paste identifier or something similar).
I tried to wrap the pieces as content in ONE ContentContainer named e.G. «DATA» in root-level (first document of website). But then I can't choose the data-records/elements with ReferenceEditor. (See in Part ReferenceEditorFeeding.)
Your 1. Approach could be the solution for ....
...but, unfortunately I can't transform your words in code.
Maybe you cold gave me a small piece of code for better understanding of the 1. solution?
- Is it possible with your 1. Approach to grasp the data-records with something "easy to understand" like inspector's ReferenceEditor?
Would be great! (also to try your solution, even if this would not be selectable with ReferenceEditor)
- Did someone know a fusion-solution to feed the ReferenceEditor with an Array within «readable-label <–> nodeIdentifier» pairs)?
(Label from nodeType property «dataRecordLabel» in children-«record(s)-nodeTypes within «DATA»-Wrapper-page)
With this "ArrayFeeding" of ReferenceEditor, it would be easy to select the desired record and also to use this one-WrapperDocument in the tree.