CMS通用架构

发布于 2024-08-26 22:51:13 字数 220 浏览 6 评论 0原文

我知道这是一个奇怪的问题,但我想知道是否有任何文档/博客文章可以解释网站内容管理系统的架构?更具体地说,我有兴趣了解更多有关“小部件”如何实现的信息。

我不记得我见过的系统是哪一个,但在“页面布局视图”中,它能够允许最终用户从列表中选择一个小部件(缩略图库、联系表单等) ,然后将其拖放到页面的自定义区域。

我知道这不是直接的编程问题,但请我寻求有关此问题的建议/反馈。

谢谢!

I know this is a weird question to ask, but I would like to know if there is any documentation/blog-article out there that explains the architecture of a Website content management system? More particularly, I am interested to learn more about how "widgets" are implemented.

I can't remember which system it was that I've seen tis one, but in the "Page Layout view" it had the ability to allow the end user to select a widget (thumbnail gallery, contact form, etc) from a list, and drag and drop it onto custom areas of the page.

I know that this is not directly a programming question, but please could I seek advice/feedback on this.

Thanks!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

云仙小弟 2024-09-02 22:51:13

我不认为存在任何特定的 CMS 架构,而是有很多。您所说的小部件可能类似于基于组件的视图层。这个想法是使用组件创建视图,可以配置和重用。这就是 asp.net 使用的 afaik。另一方面,许多 MVC 框架不使用组件,因为 MVC 的本质就是拥有视图,而视图的粒度更粗。通过比较 Web 应用程序和 GUI 应用程序,可以轻松发现差异。大多数 MVC Web 应用程序使用某种模板引擎来创建最多带有某种部分的视图 - 模板嵌入。相比之下,GUI 框架向您提供“小部件”,您可以用它们来组成视图层。
组件的优点在于可重用性,但也存在刚性和与后端(它们的行为)的一些耦合。

I don't think that any particular CMS architecture exists, there are many. What you call widgets might be something like a component-based view layer. The idea is to create view using component, which can be configured and reused. That is what asp.net uses afaik. On the other hand, many MVC frameworks don't use components, because it is nature of MVC to have views, which are somewhat more coarse grained. The difference can be spotted easily and best compared between web aplications and GUI applications. Most MVC web applications use some sort of templateing engine to create views with at most some sort of partials - template embedding. In contrast, GUI frameworks present you "widgets" which are components of which you can compose your view layer.
The advantage of components lays in reusability, but rigidness and some coupling to the backend (their behaviour) is present.

ι不睡觉的鱼゛ 2024-09-02 22:51:13

CMS 的架构(一般而言)可以说与任何其他类型的 Web 应用程序没有什么不同;你会发现对架构影响最大的是功能性和非功能性需求:灵活性还是性能?本地安装还是托管?是否多租户?等等

(包括图表 - http://www.morphological.geek.nz/Architecture /default.aspx) 是我为我的 CMS/Web 应用程序框架所做的:

  • 隔离不同的职责领域,以确保需要时的凝聚力/隔离。
  • 通过干净的接口抽象出数据访问实现。
  • 分离的内容、页面、页面布局和“皮肤”(外观和感觉)。
  • 设计 API 时考虑到外部第三方的使用。
  • 尽可能重用现有功能(AntiXSS 库、MS Ent Libs、用户/角色成员资格提供程序)。

我的框架的目标市场是在本地安装和运行,或者通过 FTP 传输到共享托管环境中的 ISP(您无法完全控制平台)。

我首先追求灵活性(但试图牢记性能);我不打算将其用作多租户系统。

The architecture for a CMS (in general) is arguably no different to any other sort of web application; you will find that the biggest influences on the architecture will be the functional and non-functional requirements: flexibility or performance? local install or hosted? Multi-tenancey or not? etc.

This (diagram included - http://www.morphological.geek.nz/Architecture/default.aspx) is what i've done for my CMS / web-application framework:

  • Isolated different areas of responsibility to ensure cohesiveness / segregation where required.
  • Abstracted out the data access implementation, via a clean interface.
  • Seperated Content, Pages, Page-Layout and 'Skins' (Look and Feel).
  • Designed the API's with external third party use in mind.
  • Re-used existing capabilities where I can (AntiXSS library, MS Ent Libs, User / Role Membership provider).

The target market for my framework is to be installed and run locally or FTP'd onto a ISP in a shared hosting envrionment (where you don't have full control over the platform).

I've gone for flexibility first (but tried to keep performance in mind); and I'm not intending to use it as a multi-tenant system.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文