在处理ORM对象时，有没有一种方法可以全局地将top属性应用于cfdump/writeDump？

在处理嵌套ORM关系时，使用or可能会迅速导致

java.lang.OutOfMemoryError

错误，因为CF试图解析嵌套对象中的关系并转储过多的对象

使用

top

属性可以避免这种情况，例如：

---

一直记着写这篇文章是一件很痛苦的事情——有没有办法配置CF，使其在处理ORM对象时不会降低太多级别？

似乎没有任何管理员设置。（）

一个不完美的解决方案是通过将

{cfusion}/wwwroot/WEB-INF/cftags/dump.cfm

重命名为（例如）

origdump.cfm

然后创建一个新的

dump.cfm

文件来创建cfdump标记的包装器，该文件包含：

<cfif isObject(attributes.var) AND NOT StructKeyExists(attributes,'top')>
    <cfset attributes.top = 3 />
</cfif>

<cforigdump attributecollection=#attributes# />

<cfexit method="exitTag" />

幸运的是，writeDump函数将调用此包装器（因此它同时适用于标记和函数）

---

不幸的是，包装器不是递归调用的——如果ORM对象位于结构或数组中，那么原始问题仍然会表现出来——可以预扫描复杂变量以确定内部是否存在关系并设置适当的顶部值，但使用此方法只能获得有限的解决方案（也就是说，它会影响相邻的结构/数组）。

这就是我要推荐的解决方案。当我在脑海中进行桌面检查时，我不太清楚递归问题（我想这本身不是桌面检查）。从

origdump.cfm

中递归调用

dump.cfm

会将

top

属性传递给

dump.cfm

调用，不是吗？因此为了参数起见，对

dump.cfm

的初始调用没有

top

参数，但它会使用

top=3

origdum>调用

origdump.cfm

p、 cfm然后在内部调用

dump.cfm

，传递

top=3

，这是您的

dump.cfm

包装器所尊重的，没有问题。或者我需要拿出笔和纸并进行桌面检查吗？抱歉，我不确定我是否解释得太好。包装器仅为顶层调用-即，如果您这样做

，则为顶层调用ion失败（var是数组，不是对象），并且没有对数组的子项执行检查。因此，需要更新顶部检查以查找容器（数组/结构），然后检查它们的子节点并适当地设置顶部，除非这样做在

{one:object，two:[[a，b，c]]}等情况下不起作用

因为两个的完整内容将无法显示。有意义吗？（当然，这只是在object+3的深度存在非object值时的问题-不确定一般情况下发生的情况有多普遍。）