entity | 伪架构师

使用Deploy和Features导出Entities

Thu, 13 Aug 2015 23:48:21 +0800

Deploy Module可以把任何支持UUID的Entity导出到Features中。这个功能在创建安装范本或演示时非常有用，或者用于处理一些既非配置，也非内容的对象。

使用Deploy导出内容：

安装Deploy和Features。如果不需要使用Deploy进行Drupal站点之间的内容同步，知识想要导出到Features的话，就无需关心Service Module的安装了。
进入admin/structure/deploy/plans/add建立一个新的部署计划。
选择聚合方式，参考Deploy基础用法，来获取关于将内容加入部署计划的不同方法。
选择Fetch only，因为我们不需要部署处理，也不需要服务节点，而且没有选择这个选项的话，部署计划也不会出现在Features界面中。
进入admin/structure/features/create菜单。
在Deployment(deploy_pnas)中，为新建的部署计划选择组件。
在UUID Entities(uuid_entities)中，会发现一个和部署计划同名的组件，选择之。
注意，上文提到的选择，不会自动提供对内容类型、字段、模块等依赖关系的处理。所以要清楚导出内容的外部依赖。如果只是导出内容到相似或相同的站点，或者利用其他的Features来解决依赖关系，最好只导出部署计划以及相关的Entity组件。

需要导出的内容需要支持UUID。Entity UUID项目为非核心Entity提供了支持。要给Commerce Entity提供UUID支持，可移步到Commerce UUID。

变通做法：

UUID Features Integration模块提供了一种简单的导出内容到Features的方式，不过她主要支持的是核心Entity。使用Deploy，只要有UUID支持的Entity都是可导出的。如果你只是想要导出核心Entity，那么这种无需更多配置的方式可能更简单。

entity_metadata_wrapper极简说明

Wed, 05 Aug 2015 10:32:19 +0800

你熟悉entity_metadata_wrapper么？如果不熟悉，那么赶快补课吧。

Entity Metadata Wrapper(实体元数据封装)，在模块开发过程中对Field的操作来说，是最正确，也是最简单的方式。没错，在CCK年代，我们对Node中Field的操作熟练无比，不过现在看来，那些代码真的很邋遢。

##干净的代码！

以前是：

<?php
$first_name = '';
if (!empty($node->field_first_name)) {
  $name = $node->field_first_name[LANGUAGE_NONE][0]['value'];
}
?>

现在可以把它浓缩成这样：

<?php
$node_wrapper = entity_metadata_wrapper('node', $node);
$first_name = $node_wrapper->field_first_name->value();
?>

entity_metadata_wrapper这个好长的单词有点点吓人，不过他的确让代码干净了。如果要处理一个实体引用字段，或者文件字段，只要这样子：

<?php
$image = $node_wrapper->field_image->value();
?>

引用字段在这里已经载入成为了对象，而不只是一个FID了。

##实体引用的处理：比干净还干净！

假设你有两种Node类型：员工和部门。员工Node中有一个指向部门的实体引用字段，部门Node又一个叫做field_dept_phone的字段保存了部门的电话号码（为了行文方便，我们假设部门字段是必填的）。

如果拿到一个员工Node，如何取到电话号码呢？

高难度动作：

<?php
$phone = '';
$department = node_load($employee->field_employee_dept[LANGUAGE_NONE][0]
['target_id']);
if ($department && !empty($department->field_dept_phone[LANGUAGE_NONE][0]
['value'])) {
  $phone = $department->field_dept_phone[LANGUAGE_NONE][0]['value'];
}
?>

Wrapper的办法：

<?php
$wrapper = entity_metadata_wrapper('node', $employee);
$phone = $wrapper->field_employee_dept->field_dept_phone->value();
?>

##然后？

嗯，这个帖子并不是想做一个完整的entity metadata wrapper教学。如果上面的描述吸引了你，请花15分钟来完成下面的事情：

下载Entity API。
阅读Entity metadata wrappers。
你的生活质量代码质量同步上升。。

使用定制Entity的时机和动机

Wed, 05 Aug 2015 10:32:19 +0800

##介绍

Drupal 7开始出现了Entity，这一改进大大的提高了Drupal模块的数据建模能力。在这之前，Drupal是一个为文章设计的数据结构，我们的方案和数据建模只能在这个基础上修修补补。

然而，在我们已经习惯于利用内容类型和字段解决所有的数据模型问题的情况下，向Entity迁移也的确不是一个轻而易举的事情。

##Entity需要一些时间和经验

如果你没有很多时间，也没有直接面对Entity API的经验，而手上的项目又逼近Deadline，那么这不是一个开始Entity的好时机，Entity的学习曲线也是颇为陡峭的。

利用 Entity construction kit(ECK)可能可以简化这一学习过程，这个模块提供了一个Entity的管理界面，尽管如此，要获得Entity的好处，还是需要一些开发工作的。ECK支持Features，能够把一个自定义Entity导出成为代码化配置，并且封装成为一个现成的模块形式。

尽管受限于实际情况，你可能不能立即投入Entity的怀抱之中，不过尽早投入时间来学习Entity还是值得的。

##Entity是什么

如果你想要建模的对象是某种类型，具体的内容可以通过一个唯一的URL来访问和查看，那么这几乎一定应该用Node而不是Entity来完成，例如一种新的文章类型。

另一个极端是，如果你面对的对象是纯粹的数据，他可能在展现之前首先要进行一些处理，或者仅作为页面的一部分而出现。一个例子就是Web版的接机大屏幕中显示的出港进港数据。

但是实际情况是，多数问题都不会是这种极端情况，可以借助在其他的框架下的经验来判断，是否使用定制Entity。

一些参考指标：

相对来说，存活期越短的东西越可能用定制Entity。（真心不懂，原文：Relatively short lived things are more likely to be custom entities than long-lived things (which may have a web presence)）
包含用于获取其他数据或者内容的元数据，比如一个用于获取存储在云服务上的视频的元数据，用定制Entity实现可能比较好。
不可见数据，例如从第三方API获取的一些数据，这些数据可能被其他的代码使用，但是通常是不会在同一个请求中立即使用，这种状况也是比较适合使用自定义Entity。
仅作为其他显示的一部分的内容也建议使用自定义Entity。

##性能和确定性

如果你拥有一个大型的复杂的站点，这一站点有很多不同事物需要被建模，如果全部使用Node实现，这导致一个后果：即使没有需要，Node相关的Hook也会影响所有这些内容。这也会导致对Node的管理工作臃肿复杂。

另外，Node的版本化特性也消耗了更多的性能。

甚至有些模型连Field都不需要，他们的属性仅使用Entity属性就能完成，无需数据库JOIN就能完成工作。（讽刺的是，起初，我们想要所有东西都能Field，现在，我们又发现，有时需要干掉Field）。

所以有时对Entity的合理使用能够让站点变得简洁，并提供更大的性能潜力。

##迎接即将到来的Drupal 8

貌似Drupal 8还要很长时间才能面世，然而该来的总会来，未雨绸缪是必要的。使用Drupal 7核心以及Entity API模块中的API，具有大量的例子和线上资源，也能让你有个较好的升级基础。

##其他Entity模块的助力

有大量的模块使用Entity API提供服务，使用Entity就让你可以通过Entity API使用其他模块的功能，例如可以利用Entity cache模块实现缓存。

##继续作恶？

可能你已经认识到，你现在的站点上的数据模型丑恶如斯，那么是时候从技术债中拯救你自己以及你的继任者了。一个Entity的反模式：分类词是核心成员之一，能够挂接Field，又具有管理页面，这种种优势导致他被过度使用，甚至在根本同分类无关的场景之中也牵强使用分类词。

这种情况在从Drupal 6中升级过来的Drupal 7站点中尤其常见。