在过去的几周里,我不禁停止思考CMS的架构我很快就要开发了。首先,我想回答你可能会问我的第一个问题。
问: 您是否在StackOverflow上阅读了类似的问题?
A:是的,我有。不幸的是,我不得不提出要求。
问: 为什么要编码另一个 CMS ???
答:嗯,这是一个很长的答案。简而言之:它必须是闭源的,它必须满足我的需求(它不是100%的CMS,它是一个更加微妙的主题 - 用它开发的任何项目都将介于60-70之间%CMS,其余的将是该项目特定需求的自定义代码)
交易工具:
面向开发人员
由于它不是纯粹的100%CMS,它 以开发人员为导向 - 易于维护,易于开发(更像是在企业级框架上开发时的感觉)< / p>
面向用户/编辑
在处理像这样的项目时,任何程序员都可能发现自己走错了方向,而不是认为使用这个CMS作为编辑工作的人实际上并不是一个非常技术性的人。这是冲突发生的部分 - 如果它不易使用,但又足够强大,你将面临很多问题需要处理。
i18n &amp;的 L10
我几乎可以肯定,编写开发人员和面向用户的东西将是一项艰巨的任务,如果我不能实现这一点,我想更加重视开发人员而不是编辑器。我知道忽略软件的实际用户并不是一件好事,但这个CMS必须快速开发。
让我思考的第一个建筑设计如下: 我定义了一个通用对象。用户/管理员进入管理区域并定义他需要的数据对象。很容易。
对象page
(例如)有一个title
字段,一个body
字段和一个slug
。它只是由用户定义,现在他可以根据这个“数据结构”创建内容。看起来很整洁,但我仍然没有解决这个架构的一些问题。
dataTypes
表,objects
表并通过objectProperties
表将它们链接到多个表吗? objects
表中? dataType
属性并将其添加到对象中? 今天我发现自己正在考虑这种可能性。在yaml
或ini
文件中定义对象的数据结构然后搭建它的数据库表,模型和CRUD是非常巧妙的。还要提到它与其他“数据结构”对象的关系,以获得正确的CRUD实现(例如,考虑page
数据结构和category
数据结构。
不幸的是,这让我也想到了几个可能的问题。
我仍然对如何处理这个主题以及选择什么样的架构感到困惑。在这个时刻,两者在发展方面都非常具有挑战性。 我的问题很简单。
答案 0 :(得分:2)
只是一些一般性的建议,如果你真的想管理自由格式的内容那么我会远离关系数据库来存储你的数据并使用XML解决方案。关系数据库对于纯粹面向内容的东西有太多的结构。想想主页......你的信息显示如下:欢迎通知,关于我们,我们是谁。这并不能很好地映射到表/表集合,尤其是当您开始添加/删除其中一些项目时。具有已定义结构的东西(如堆栈溢出)确实可以很好地映射到关系数据库。
查看Day CMS,Apache Sling,Java Content Repository以获取一些想法。
http://www.day.com/day/en.html
http://sling.apache.org/site/index.html
http://en.wikipedia.org/wiki/Content_repository_API_for_Java
答案 1 :(得分:1)
从我的观点来看,更多选择总是一个问题。在涉及复杂系统时,用户通常都是无知的。因此,我坚持使用面向开发人员的解决方案。开发人员将决定可以显示哪种内容。我可以选择允许某种“开放”内容 - 对于高级用户来说,允许使用复杂的CSS / HTML / JS。诸如照片库,用户配置文件等复杂内容不应由BFU设计。
总而言之 - 主要功能 - 创建可以在结构中的任何位置删除的页面(应该非常灵活)。如果他们想要用户配置文件,您可以创建一种新类型的页面。但在一天结束时,BFU可以用足够的时间做任何事情。这取决于价格/时间尺度。如果他们可以支付并快速需要它们,他们将使您创建一个新的用户配置文件页面类型,taht将很容易填写。如果他们有点穷人,他们会选择使用普通页面自己设置并且所见即所得:D