到目前为止,在我处理的大多数情况下,Worklight Adapter 实现非常简单,只需几行 JavaScript。
在当前项目中,使用 WL 5.0.6,我们有几个适配器,每个适配器都有几个程序。我们特定的后端需要一些通用逻辑来设置请求和解释响应。似乎非常适合将公共代码重构为共享库,除了据我所知,适配器环境中没有“库”概念,除非我们想进入 Java。
适配器之间是否有任何代码重用模式?
到目前为止,在我处理的大多数情况下,Worklight Adapter 实现非常简单,只需几行 JavaScript。
在当前项目中,使用 WL 5.0.6,我们有几个适配器,每个适配器都有几个程序。我们特定的后端需要一些通用逻辑来设置请求和解释响应。似乎非常适合将公共代码重构为共享库,除了据我所知,适配器环境中没有“库”概念,除非我们想进入 Java。
适配器之间是否有任何代码重用模式?
我想你是对的。目前无法导入自定义 JavaScript 库。
有一种方法可以使用“load(xyz.js)”函数在 Mozilla Rhino 引擎中包含/加载 Javascript 文件,但这会使您的 Worklight 适配器无法部署。
但我注意到,这会使您的 Worklight 适配器无法部署。如果您在适配器中部署第二个 *.js 文件,您将收到以下错误消息:
Adapter deployment failed: Procedure 'getStories' is not implemented in the adapter's JavaScript file.
Worklight Server 似乎每个适配器只能处理一个 JavaScript 文件。
我通过在 Java 代码中实现功能并将 jar 文件包含在 Worklight war 文件中,在适配器之间共享了一些通用功能。这可以方便地通过 JDBC 调用存储的过程,该过程可以处理多个输出参数,还可以从内部后端服务检索 PDF 内容。jar 需要位于适配器将部署到的 worklight.war Web 应用程序的 lib 目录中。
在适配器中创建 java 对象的示例:
var parm = new org.apache.http.message.BasicNameValuePair("QBS_Reference_ID",refId);
在适配器之间共享 JavaScript 的一种方法是遵循类似这样的模式:
CommonAdapter-impl.js:
var commonObject = {
invokeBackend: function(input, options) {
// Do stuff to check/modify input & options
response = WL.Server.invokeHttp(input);
// Do stuff to check/modify response
return response;
}
}
getCommonObject: function() {
return commonObject;
}
NormalAdapter-impl.js:
function getSomeData(dataNumber) {
var input = {
method: 'get',
returnedContentType: 'json',
path: '/restservices/getsomedata',
}
return _getCommonObject().invokeBackend(input);
}
function _getCommonObject() {
var invocationData = {
adapter: 'CommonAdapter',
procedure: 'getCommonObject',
parameters: []
}
return WL.Server.invokeProcedure(invocationData);
}
在这种特殊情况下,通用适配器用于提供“包装器”功能,WL.Server.invokeHttp,
但它也可用于提供任何其他实用程序功能。
特别是这种模式的原因是它允许在“调用”适配器的上下文中运行,这意味着将使用调用适配器文件WL.Server.invokeHttp
中指定的端点(主机名、端口号等) 。.xml
这确实意味着必须在每个“正常”适配器中重复简短的 _getCommonObject() 函数,但这是一小部分样板文件。
请注意,此模式已与 Worklight 6.1 一起使用 - 不能保证它将在未来或过去的版本中工作。