列表视图 XML 中的 Managed="0" 是什么意思？答案

【问题标题】：What does Managed="0" in List view XML mean?列表视图 XML 中的 Managed="0" 是什么意思？
【发布时间】：2012-08-09 22:32:44
【问题描述】：

我编写了一个 Data Extender 类和编辑器扩展，当您浏览 CME 中的列表（文件夹和结构组）时，它可以正确地显示一些额外的项目列。我必须注册我的类来处理 GetList、GetListSearch、GetListUserFavorites 和 GetListCheckedOutItems 等命令。

我注意到的是，即使为 CME 中的下拉列表加载了一个说模式列表，代码也会运行（比如在创建新组件时，您会在下拉列表中获得模式列表-下）。因此，即使在这种情况下不需要我的额外数据列，代码仍在执行中，它会减慢速度。

似乎是在这些情况下调用的 GetList 命令。所以，我不能只根据命令跳过处理。因此，我开始查看该类为列表接收的 XML，并且我注意到在为下拉菜单运行代码时，XML 中有一个 Managed="0"。例如：

对于结构组列表：<tcm:ListItems Managed="64" ID="tcm:103-546-4">
对于文件夹列表：<tcm:ListItems Managed="16" ID="tcm:103-411-2">
但对于 Schema 列表：<tcm:ListItems ID="tcm:0-103-1" Managed="0">
对于显示类别关键字值的下拉菜单：<tcm:ListItems Managed="0" ID="tcm:103-506-512">

那么，我可以只使用这个 Managed="0" 作为标志来指示正在处理的列表不会显示我的其他列并且我可以退出处理吗？

【问题讨论】：

感谢弗兰克的清理工作！

标签： tridion

【解决方案1】：

根据以前的经验和 User978511 所说的，Managed 属性指示可以从该列表的上下文中创建的项目类型。

不幸的是，这意味着对于没有足够权限创建项目的任何用户，Managed 属性很可能为 0。例如。检查不允许创建页面或结构组的用户在结构组中的 Managed 是什么。在这种情况下也可能是0，这意味着它对您的情况没有用处。

更新

通过查看columns 参数，您或许可以更好地实现目标：

context.Parameters["columns"]

在我运行的一些测试中，我得到了不同的值，这取决于我获得的是主列表视图的列表、树还是下拉列表。

543
 23
  7

这些值是这些常量的位掩码（来自Constants.js）：

/**
 * Defines the column filter.
 * Used to specify which attributes should be included in XML list data.
 * @enum
 */
Tridion.Constants.ColumnFilter =
{
    ID: 1,
    ID_AND_TITLE: 3,
    DEFAULT: 7,
    EXTENDED: 15,
    ALLOWED_ACTIONS: 16,
    VERSIONS: 32,
    INTERNALS: 64,
    URL: 128,
    XML_NAME: 256,
    CHECK_OUT_USER: 512,
    PUBTITLE_AND_ITEM_PATH: 1024
};

所以从我有限的测试看来，下拉请求DEFAULT 列，而主列表视图和树都有ALLOWED_ACTIONS 在那里。这对我来说很有意义，因为用户可以与树和列表视图中的列表项进行交互，而他们只能在下拉列表中选择它们。因此，检查 columns 参数中是否存在 ALLOWED_ACTIONS 可能是减少数据扩展器添加信息的位置数量的一种方法。

【讨论】：

我将尝试对此进行试验，看看是否会禁用用户的权限，如果这会更改该值。不同的问题。我可以在 Data Extender（可能是 PipelineContext）中使用其他东西来检测正在执行的 GetList 命令的“种类”吗？如果有针对这些情况的其他命令会很方便，这样我们就可以区分正在处理的列表类型。
在允许您的代码检测调用它的确切位置和针对许多此类位置检索完全相同的数据这一事实优化缓存之间有一个很好的平衡。我什至不确定对下拉列表的 GetList 调用是否应该与列表视图的调用不同。或者至少：一旦你在列表中显示了关键词，就不需要调用服务器来获取下拉列表的数据；它只是已经检索到的内容的一个子集。
您可能想查看在 pipelineContext.Parameters["filter"] 中传递到 DataExtender 的过滤器。过滤器中的ItemTypes 似乎也给出了请求上下文的一些指示。
我从 pipelineContext 中查看了过滤器，它为空。我尝试检查 pipelineContext 提供的其他内容。我看到一个“command:type”键，它的类型似乎是“Tridion.Web.UI.Models.TCM54.Lists”，知道它是什么以及它会告诉我什么吗？

【解决方案2】：

遗憾的是，CME 目前无法提供那种粒度级别，让您可以在数据扩展器中判断特定 WCF API 调用来自何处。我们的 WCF API 还不是上下文感知的。未来可能会改变。

信任 Managed="0" 不是一个好主意。原因是模型列表是每个过滤器缓存的客户端。在当前设计中，过滤器具有与 CM 相关的数据，并且与发出请求的上下文无关。通常，客户端用户界面会尽可能重用缓存的模型数据。例如，可以在 CME 仪表板中使用相同的模型列表，并在某些项目视图中放置一个下拉控件，但使用不同的 xml 列表定义：第一个在列表定义中定义的列比后者多。它们基本上是相同数据的不同视图。

因此，您可能想为您的问题想出不同的解决方案。现在......这些附加列背后的数据来自哪里？是 Tridion CM 还是第三方提供商？有时，Web 服务器缓存可能会提供一种可接受的方式来改善响应时间。但这是您应该评估和决定的设计。

【讨论】：

谢谢！我提交了一个增强请求，以便能够告诉 GetList 命令的来源。对于我们的具体实现，所有数据都来自 Tridion CM，因此缓存并不合适。我们添加的列是：修改者、版本、批准状态、锁定者、发布日期。我希望有一天能够做的是让内容作者能够设置偏好以根据需要打开或关闭其他列。关闭它们显然会加快他们在 CME 中的导航速度，打开它可以让他们看到他们需要的其他信息。

【解决方案3】：

Managed 值表示可以在OrganizationItem 中创建哪些项目：

64 表示您可以创建页面
16 表示可以创建组件
10，例如意味着您可以创建文件夹 (2) + 架构 (8)
518 - 文件夹 (2) + 结构组 (4) + 类别 (512)

非组织项目的值为 0。

值取决于项目本身（例如，您不能在文件夹中创建页面），以及您对发布和组织项目的安全设置

【讨论】：

感谢安德烈的解释。但华纳案例中的类别不应该说他可以创建关键字（假设他有足够的权利）吗？
我认为只有当调用它的视图是类别本身时才会发生这种情况，我认为这是当您获得用于创建组件的关键字列表时返回的 XML。在这种情况下，您将无法在那里制作关键字
谢谢大家。这是很有教育意义的。显然这对我想要完成的事情没有帮助。但如果我需要它，很高兴知道它可以用来做什么。

【解决方案4】：

如果您阅读列表的 ID，并且只为类型 2 和 4（分别为文件夹和结构组）的列表执行代码，我认为您将有一个更强大的解决方案。但这对搜索视图等没有帮助。

【讨论】：

这似乎是我见过的最常见的方法之一：找到方法来识别您不想处理的列表和if 那些。即使你不能一次完成所有这些，你也会慢慢地让事情变得更快，每次迭代的风险是可控的。在这与您正在添加的信息的积极缓存策略之间，您通常可以获得合理的性能。当然，没有什么比不向列表中添加自定义列的性能更好的了。因此，您应该始终首先考虑该选项......并且最后考虑。
@FrankvanPuffelen：完全同意。但是，战斗打了又输（现在）。这些众多的附加列被认为是商业目的所必需的。