十二月 2014

Drupal 真的难?

Tags: 

每隔一段时间,在Drupal相关的论坛、QQ群、Twitter什么的上面就会看到"Drupal好难"、“学习曲线陡峭”、“Drupal Sucks”等类似的车轱辘话,以及那副倒霉的乱葬岗图。

Drupal 真的这么难?

Drupal作为一个框架和平台的混合体,在项目实施上,的确有些不错的优点。但是单就复杂度来说,不管是框架上,例如大行其道的SSH,远古时代的MFC;还是平台上,例如SAP、WebSphere之流,我的感觉是,Drupal的复杂度还并不突出,甚至颇有不如。

为什么难声一片?

核心方向摇摆不定

个人浅见,根本原因在于Drupal的核心颇有些摇摆不定。Drupal 7 时曾明确提出了Content Management Framework的概念。

而在Drupal 8的发育过程中,多数时间夸夸其谈的题目主要在数字化体验、移动支持等功能层面的内容,以及Views入~~常~~核的“可喜”变化 —— 很明显,社区对于framework并不买账。

开发者的Twig

Tags: 

本章讲述的是Twig的API,而不是Twig的模板语言。这些内容会对为应用实现模板接口的工作很有帮助,对模板的制作工作就没什么意义了。

基础

Twig的中心对象为environment(是Twig_Environment类的实例)。这个类的实例用于存储配置和扩展,并用来从文件系统或者其他位置载入模板。

绝大多数应用需要在应用初始化的时候,创建一个Twig_Environment对象,然后用它来加载模板。在有些案例中,会有多个环境同时并存,用来处理不同的配置。

下面举个简单例子,配置Twig来为应用载入模板:

模板设计者的Twig

Tags: 

本文描述了模板引擎中涉及到的语法和语义,对Twig模板的设计会很有帮助。

概要

模板是一个简单的文本文件。它能够生成任何文本格式(HTML, XML, CSV, LaTeX等)。他没有固定的扩展名,htmlxml都没关系。

模板中包含变量表达式在模板被处理时会被替换为真实的值,tags则对模板的逻辑进行控制。

下面用一个小例子展示一些基础内容,当然,后面会做进一步的深入。

简介

Tags: 

Twig是一个高效、安全并可扩展的PHP模板引擎。

如果你具有Smarty, Django或者Jinja这养的基于文本的模板语言的经验,那么你对Twig会感觉一见如故。在遵循PHP理念的基础之上,提供了具备强大功能的模板环境,不论是对开发者还是设计者来说,这一引擎都具有良好的可用性。

关键特性:

  • 快速:Twig把模板编译成为优化后的PHP代码。相对普通PHP代码来说,其额外开销非常轻微。
  • 安全:Twig会使用一个沙箱模式来运行不信任的模板代码。这使得Twig可以在用户可以修改模板设计的应用中工作良好。
  • 弹性:Twig试用了弹性的词法和语法分析器。开发者可以定义自己的标记和过滤,并创建自己的DSL。

需求

Twig需要的最小运行环境为PHP 5.2.4

安装

推荐使用Composer安装Twig:

对话

A: 据说你们Drupal只能连一个数据库?

B: 框架自用的一般只连一个,读写分离什么的也会做些切换,至于外部数据库,那就随意了。

A: 我这有个需要界面的需求,你看让你的人直接PHP连上我们这边Oracle数据库,一起做了吧。

B: 那不行,我可不想给你编译环境去,PHP的OCI我记得可是臭名昭著。

A: 那你觉得应该怎么办?

B: 简单,你们做服务,PHP做界面。

A: 很小的东西,不用这么麻烦吧?

B: 我不想两组应用挂同一个数据库,更不想两组人挂在同一个数据库上,一定会出乱子的。

A: 那我写个服务,让你们发表发CRUD操作,我给你执行吧?这样以后操作也方便。

B: 烟囱可是大忌,用Java不就是要实现业务逻辑的么?你也说了东西小啊?

A: 我知道你要求高,不过项目这么紧,需求这么小,就不用这么严格了吧?

B: 完美是做不到的,但是总不能让小弟们从来不想一下什么是完美吧。

Drupal Services模块入门教程

Services模块为Drupal站点提供了实现Web服务的能力。

Services很流行,可以同REST, XMLRPC, JSON以及SOAP协同工作。

然而,在上星期的一次培训中,当被问到Services的问题时,我意识到,问题产生的原因在于——这个模块几乎没有清晰的可用的文档。

所以我决定写一篇Services模块的入门教程。

下面就是利用Services为Drupal站点建立REST API的五个步骤:

1. 安装

基础的REST API需要三个模块的支持: