Groovy 脚本上下文和方法解析答案

【问题标题】：Groovy Script Context and Method ResolutionGroovy 脚本上下文和方法解析
【发布时间】：2015-05-04 18:34:19
【问题描述】：

我对以下 Groovy 脚本有疑问/

nestedView("JS Pipelines") {
  views {
    build_pipelines.each {
      def build_pipeline = it
      buildPipelineView(build_pipeline.build_name + " JS Pipeline") {
        selectedJob(build_pipeline.start_job)
      }
    }
  }
}

根据build_pipelines 的内容，它需要多次调用buildPipelineView 方法，该方法位于views 对象(code) 上。

当对buildPipelineView 的调用包含在每个{} 调用中时，该方法将解析为在更高上下文中定义的另一个buildPipelineView 方法。当每个块被删除时，方法调用会正确解析。 buildPipelineView 如何在每次通话中正确解析？

【问题讨论】：

它是否在错误的对象上调用buildPipelineView？如果是这样，您可以使接收者明确this.buildPipelineView(...)。在闭包中，Groovy 方法查找也会考虑委托对象。您还可以在闭包上设置属性以更改该查找解析策略。

标签： groovy

【解决方案1】：

如果有疑问，存储外部引用，这将对闭包可见并在该对象上显式调用此方法：

nestedView("JS Pipelines") {
  views {
    final outer = it
    build_pipelines.each { build_pipeline ->
      outer.buildPipelineView(build_pipeline.build_name + " JS Pipeline") {
        selectedJob(build_pipeline.start_job)
      }
    }
  }
}

【讨论】：

【解决方案2】：

其实job-dsl-plugin的ContextHelper.groovy改变了views闭包的委托策略，正好是views的括号。

在您的情况下，只有build_pipelines 被包裹在views 闭包中，所以您确实更改了each 闭包的委托策略，但buildPipelineView 闭包仍然保持默认策略。

您可以使用getDelegate 将委托策略还给buildPipelineView 闭包。

nestedView("JS Pipelines") {
  views {
    build_pipelines.each {
      def build_pipeline = it
      def d = getDelegate()
      d.buildPipelineView(build_pipeline.build_name + " JS Pipeline") {
        selectedJob(build_pipeline.start_job)
      }
    }
  }
}

【讨论】：

【解决方案3】：

在嵌套闭包中，每个闭包都有一个owner，它是其直接包含的闭包。（请参阅 Groovy 文档中的 Delegation strategy。）对于传递给 each 的闭包，它的 owner 是传递给 views 的闭包。

Groovy 闭包的默认delegation strategy 是Closure.OWNER_FIRST，这意味着当您访问一个属性或调用一个方法时没有明确提及接收者[如buildPipelineView(...)]，Groovy 将尝试访问@ 上的属性/方法987654329@，如果没有，它将访问委托上的属性/方法。

直接的解决方案是显式提供接收器，例如this.buildPipelineView(...).

【讨论】：