Web应用程序与Drupal的集成

我们希望构建一个特定于我们域的Web应用程序,但也包括此应用程序中的论坛,博客等.还需要一些与Twitter和Facebook的集成点.还将有一个桌面应用程序连接到我们的Web应用程序,用于上载数据和下载配置和报告.

问题是,我们可以将Drupal扩展为托管常规模块和Web应用程序吗？(将有桌面应用程序上传的业务实体及其属性和日常数据)或者Drupal可以与外部应用程序集成吗？例如,用户和角色需要在两者之间保持一致和一致.我们可能还希望Web应用程序中的数据可以在Drupal中搜索.

我知道这有点模糊,但我不能透露更多.我对内容管理很陌生,我只是想知道是否有人建立了这种应用程序.

我试着改写你写的东西,只是为了让你检查我的问题是对的.您基本上需要创建一个Web应用程序:

实现Drupal的一些标准功能

有一些自定义功能应该"融入"Drupal一个(相同的用户,相同的权限等...)

能够从桌面应用程序上载/下载内容(或数据).

如果我找对你,简短的回答是:是的,你可以用Drupal做到这一点.

现在有了广泛的内容: - Drupal拥有数千个模块,所以我希望您只需安装正确组合的现成模块即可获得所需的大部分内容. - 当然,任何自定义功能都可以很容易地以模块的形式实现(这些天很标准).- 与桌面应用程序的交互通常通过Web服务实现,而不是直接查询数据库.Drupal本身带有一个xmlrpc服务器和客户端,但是你可以通过几个contrib模块扩展到SOAP - 如果你愿意的话.

一些额外的想法:

如果您选择使用Drupal,并且从头开始,那么您必须了解您,您的团队需要花费一些时间和精力来了解Drupal的工作原理.虽然 - 与Palantir不同 - 我坚持使用Drupal,但我同意她/他的事实,Drupal会立即变得复杂复杂.这是你需要付出的权衡,以便拥有一个平台 - 放心 - 非常灵活,极易插拔且坚如磐石(否则它不会被用来重新设计白宫,Drupal也不会我认为连续第二年获得"最佳PHP CMS"奖.

好消息是:那里有一些优秀的书籍,我当然会推荐"Pro Drupal Development",以便对系统进行深入全面的解释.请务必获得第2版,因为第一版涉及现已过时的5 seres.那说......

至少在我看来,关于Drupal的一个非常好的事情是,你可能需要对现有功能进行的大多数调整都可以通过从自定义模块中连接到原始代码来实现.这个IMO是Drupal的最大优势:你永远不必触及其他开发人员的代码来实现你的目标,这意味着 - 例如 - 你将能够保持你的核心和contrib模块最新,而不会破坏任何您可能已经完成的自定义.

Drupal很重.与其他CMS相比,它从服务器中吸收了大量的处理能力和RAM,并且 - 除非你要拥有一个非常小的站点 - 我建议将它与nginx一起部署,而不是Apache.

由于良好的缓存机制和"限制"机制,Drupal可以很好地扩展.听起来很奇怪,Drupal在大型交通网站上的扩展非常好,因此流量的大幅增加并不一定意味着资源使用量的大幅增加.

Drupal网站上开箱即用的用户体验很差.目前正在进行大量工作(此处和此处(视频)),但在D7发布之前将无法进行改进[很快,但是您将不得不等待移植模块],因此,如果您网站的管理员不属于技术类型,建议您分配一些时间来创建管理主题.

在一天结束时,我的建议是:如果您的网站将变得大/复杂/具有复杂的业务逻辑和许多功能,那么Drupal可能是一个很好的候选者.如果您的网站是标准功能加上一些自定义位的小型网站,可能Wordpress/Joomla可以更好地满足您的需求[不是因为它们"不那么强大",而是因为Drupal的优势在这种情况下不会被使用,而Wordpress/Joomla更简单的架构可能代表这种情况下的优势]

其他选项肯定会是像CakePHP或Django这样的框架,但我认为,IMO是一种完全不同的方法.

简短回答: Drupal很适合构建类似的东西,特别是如果你愿意将你的app/logic集成到Drupal中作为一套自定义模块.另一方面,将Drupal集成到外部应用程序中也可以完成,但会给你带来更多的摩擦,因为Drupals架构本身就是一个独立的框架.

更长的答案:与Palantirs相比,我有相反的观点/经验.在两个相当复杂/"有进取"的项目的背景下,我几乎完全与Drupal一起工作了一年(经过几年'在'侧面'使用较小的东西).虽然我同意它强加一些严格的规则(但不是限制!),我认为这是一个优势,因为这些规则提供了明确的指导并提供了如何做事的成熟方法.Palantir提到的三个部分就是很好的例子:

菜单系统 - 提供结构良好且有效的调度机制,易于使用您自己的东西进行扩展,同时为调整/操作现有/默认路径提供了极大的灵活性.(请注意,Drupal中的"菜单系统"表示管理URL空间的整个主题,而不仅仅是通常与术语相关联的"可见"菜单的子集)

Forms API - Web表单的声明性方法,具有精心设计的处理工作流程和大量内置安全功能,否则您必须自己处理.还具有高度可扩展性,可根据需要调整/扩展现有表单的直接选项,为任何字段或整个表单,多步骤表单,基于javascript的表单调整等添加新的验证规则.

翻译系统 - 这非常复杂,仅仅因为国际化很难实现.但它是内置的,再次给出了如何做事以便以通用方式工作的明确指导(尽管存在一些问题,相当一些贡献的模块没有按照它们的方式使用/支持它).

我可以提供更多关于我喜欢"规则"的部分的例子,但这个帖子已经很久了,我仍然需要弥补一些缺点;)

所以总结一下积极的部分 - 如果我在哪里给出你发布的粗略规格,我会说'没问题'和Drupal一起去,相信它会成为定制零件的坚实基础,同时提供所有'标准'像论坛,博客,推特/ Facebook集成和许多其他已经存在的解决方案形式(即使这些可能需要一些适应/调整).

缺点:一如既往,存在缺陷,其中一些是实质性的,具体取决于要求/情况.

学习曲线 - Drupal非常复杂,"grokking"它的概念需要时间.正如Palantir所暗示的那样,"玩它一周"肯定会给你一种普遍的感觉/广泛的印象,但它绝不足以让我们对它的优点和缺点进行认真的判断,因为那些只会在编码时出现在/为它.因此,如果您已经熟悉已建立的Web开发框架,那么这可能是一个问题.如果你必须学习一个,这应该不是一个问题.

数据库限制 - 从Drupal 6开始,数据库支持仅使用MySQL或PostgreSQL,使用Drupal特定的"抽象层"(显然不是一个;)
Drupal 7将转移到PDO,它应该(最终)结束这个可疑状态.

测试/阶段/生产迁移 - Drupals的"开箱即用"部分灵活性是由于管理后端中可配置的许多内容,这意味着许多重要的配置设置都存储在数据库中.这使得在几个实例之间迁移数据和/或配置非常困难/乏味,一旦您离开(早期)开发阶段,您可以完成转储/恢复操作(参见例如此问题和答案)

这些是我的主要内容,但你可能会发现更多:)