Hi there,
I am searching for a simple solution to manage data records in a central place of Neos. For example, an address, product-descriptions or -prices, which can be used as data in various places, but can still be changed / maintained at a central location.
The data records have to be create-able and maintainable by editors (manageable in the backend -> not in settings.yaml)!
I’ve worked out a cumbersome solution by myself. Unfortunately, it is not very practically.
Does anyone know a simple and crisp solution?
Is there anything for this challenge in Neos (out of the box)?
Use custom-documents that represent your data … recommended in 90% of the use cases
Use custom Flow-Domain Objects and create a backend module
Quite often the first option is a good way. It enables out of the box to reference the managed items from your other nodes and with flow-query you can easily access the properties of those items. A problem that occurs in that case is that you sometimes end-up with dozens of nodes on a single level in the navigate component which is good not ui-wise but can be mitigated by clustering the items in a structure of collection nodes. An important benefit of this approach is that you automatically have the same dimensions as your site.
To help editors you can consider the following constraints:
Allow the itemCollection only on root level and inside other itemCollections
Allow itemDocuments only inside of itemCollections
If the document approach is not feasible writing a custom domain model and a backend module is not really difficult. You can look at the neos-backend modules for examples. On the rendering side you will have to create extra code to reference those items or to read them in your site but it is all well solvable.
Regards Martin
PS: There are other approaches that combine domain-models and cr-nodes or that store cr-nodes outside of your site but check out the other two ways first.
sounds easier to implement. But I have problems to understand the Terms and Conceptuality.
Maybe your «custom-documents» are close to my «cumbersome solution»?
####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)
ReferenceEditor Feeding:
####- 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.
Yes, the thing i called “Custom Document” is indeed a “Custom DocumentType” as you correctly understood. Sorry for beeing not really specific here.
The things i see from your example code is that you manage companies and some records for each company. Additional you want to reference the companies in your seite.
That would lead me to something like this: BEWARE OF UNTESTED AND INCOMPLETE CODE
# a collection of companies that can contain either more collections or companies
# by creating this collections you can cluster the records to avoid spamming the
# node tree on a single level too much
'Vendor.Site:Document.CompanyCollection':
superTypes:
'TYPO3.Neos:Document': true
constraints:
childNodes:
nodeTypes:
# the following line is overwriting a rule that is inherited from neos
'TYPO3.Neos:Document': false
'Vendor.Site:Document.CompanyCollection': true
'Vendor.Site:Document.Company': true
# company records that can be linked in your site
'Vendor.Site:Document.Company':
# the following line specifies how the label in the sidebar and select boxes is rendered
label: "${String.cropAtWord(q(node).property('name') + ' ' + q(node).property('legalForm') , 100, '...')}"
superTypes:
'TYPO3.Neos:Document': true
childNodes:
records:
type: 'TYPO3.Neos.ContentCollection'
constraints:
nodeTypes:
'Vendor.Site:Content.CompanyRecord': true
'*': false
properties:
...
# a data record for a company
'Vendor.Site:Content.CompanyRecord':
superTypes:
'TYPO3.Neos:Content': true
properties:
...
Please note that this will only work if you have to reference the single company and not one of their records.
with an easy to understand solution (not with copy/paste identifier or something similar).
