我想使用基于资产的架构开发一个有趣/个人的CMS，而不是基于页面（为什么，这个问题的目的），但我找不到关于这个主题的很多信息。所有我发现的几乎没有刮擦表面（我很有可能用错误的术语搜索）。
基于资产的CMS存储信息 作为称为资产的文本块。这些 然后个人资产与之相关 彼此自动构建 页。
这种系统的（dis /）优势是什么？
基于资产的架构的主要原则是什么？
什么应该而且不应该是'资产'？我在哪里可以阅读更多内容？
答案 0 :(得分：4)
在离开我的评论后决定尝试回答：）
如果您对“资产”的定义是沿着“节点”（例如Drupal）或文档（例如MongoDB或CouchDB中的JSON样式文档），那么这里有一些信息：< / p>
我将在这篇文章中使用术语“节点”。我认为它最接近“资产”并且更常用。这也可能是一个非常抽象的答案，但希望它至少会让你思考并指出正确的方向。
基于节点的架构，可以描述为神经网络模式和面向对象编程之间的交叉。关键是“节点”是数据点，节点可以以某种方式相互连接。
某些体系结构将节点视为面向对象的类，其中您具有可以继承父节点的各种特征的不同类节点 - 每种类型的节点都继承其父节点的基本属性 - “Essay”节点可能会继承“Text-Document”节点的属性，该节点继承基本节点的属性。 Drupal很好地实现了这个继承模型，虽然它没有像Facebook的GraphAPI / Open Graph Protocol那样强调节点之间的连接。
这种基于节点的体系结构模式也可以在任何层面实现，并且存在于自然界中 - 想想社会或生态系统中的社交圈;）在软件工程层面，它可以采取数据库的形式，例如MongoDB如何简单地拥有数据节点（在这种情况下称为文档）。这些文档可以引用其他文档，但是，像Drupal一样，Mongo并不强调连接性。具有讽刺意味的是，与基于文档的数据库相反的MySQL之类的关系型数据库实际上更强调连通性，但这是另一天的讨论。我上面提到的Facebook的GraphAPI是在Web-API级别实现的。开放式图形协议对其进行整形。再一次，像Drupal这样的东西是在前端实现的（当然，它的后端实现了较低级别的节点模式）。
最后，基于节点的体系结构比传统的基于文档/页面的CMS体系结构更灵活，但这也意味着在开发人员方面需要完成更多的编程和配置。基于节点的系统最终将更加相互连接，其组件将彼此集成到更深层次，但由于这种深层次的连接，它也更容易被破坏 - 它不会分离到单个模块。就个人而言，我看到一个巨大的趋势，人们开始变得更“基于节点”，而不是“基于内容”，因为人们开始与更像应用程序的网站互动，而不像90年代那样与电子杂志互动。此外，节点模式非常适合日益重视用户贡献和社交浏览，因为将人及其帐户/配置文件添加到网站会大大增加复杂性。
我知道你说的是“资产”，所以我也会说资产更多地强调节点模式的数据方面，而“节点”则更强调数据之间的连接。
但是为了进一步阅读，我建议您阅读我提到的软件的架构。您还可以查看node.js，JSON和基于文档的数据库，以及GraphAPI，因为它们似乎非常适合基于资产/节点的架构。我确信维基百科也对这些模式有一些好处。
答案 1 :(得分：0)
您可以使用CakePHP框架快速扩展它。它使用MVC模式，它提供了可以插入布局的类元素，可以根据页面，用户，月相等加载你想要的任何内容。
<page>
<element calls methodX>
<element calls methodY>
<Default Content relies on Controller Action(view/edit/add/custom)>
<element calls methodZ>
</page>
答案 2 :(得分：0)
我认为您可能正在描述由内容存储库备份的CMS。
存储库本身由Apache Jackrabbit基于JSR 170实现：
API应该是一种标准的，独立于实现的方式，可以在内容存储库中的粒度级别上双向访问内容。内容存储库是一种高级信息管理系统，是传统数据存储库的超集。内容存储库实现“内容服务”，例如：基于作者的版本控制，全文本搜索，细粒度访问控制，内容分类和内容事件监视。正是这些“内容服务”将内容存储库与数据存储库区分开来。
对于在内容库上工作的CMS，请查看Nuxeo。