sys:base
определяется в systemModel.xml
следующим образом (последняя версия HEAD показана здесь):
<type name="sys:base">
<title>Base</title>
<mandatory-aspects>
<aspect>sys:referenceable</aspect>
<aspect>sys:localized</aspect>
</mandatory-aspects>
</type>
Просмотрите systemModel
, чтобы узнать о двух аспектах, которые являются обязательными для такого типа. cm:content
косвенно наследуется от sys:base
, как вы можете видеть в contentModel.xml
, проходящем через cm:object
, который накладывает некоторые ограничения и индексирует сказочный порошок.
В contentModel
вы также можете увидеть, что cm:folder
предоставляет новую ассоциацию с именем cm:contains
, которая предназначена для sys:base
объектов. Это означает, что в пределах cm:folder
(и подтипов) вы можете хранить каждый тип в ветви иерархии, начинающейся с sys:base
, включая cm:object
и cm:content
.
Этого должно быть уже достаточно, чтобы показать вам, как:
- для создания контейнеров, допускающих определенные дочерние типы
- нет большой разницы между
cm:content
и sys:base
, когда дело доходит до хранения таких типов в cm:folder
- типы находятся в иерархии наследования, и поэтому вы выбираете, какой тип наследовать, в зависимости от его свойств и отношений с другими объектами в хранилище
- если вы хотите, вы можете наследовать от
sys:base
вместо cm:content
или cm:object
, но тогда вы пропустите все функции, представленные этими более высокоуровневыми типами
Я не понимаю, почему типы контента должны меняться или влиять на способ доступа пользователей к контенту, особенно если у вас есть свои собственные страницы для показа контента пользователям.
В качестве примечания также usr:user
наследуется от sys:base
, как вы можете видеть в userModel.xml