为什么我们在 ATG 中需要两种不同的方法——基于拉的（液滴）和基于推的（表单处理程序）？答案

【问题标题】：Why we needed two different approach in ATG -pull based(droplet) and push based(formhandlers)?为什么我们在 ATG 中需要两种不同的方法——基于拉的（液滴）和基于推的（表单处理程序）？
【发布时间】：2014-09-26 11:05:30
【问题描述】：

我知道问题可能是通过不同的方法解决问题，但请让我详细说明我想问什么以及我对此了解多少。

我们有两种 mvc 方法用于 ATG（或许多其他框架）基于拉取和基于推送。据我了解，formhandlers 和 droplet 都在不同需求中扮演控制器的角色，存储库是我们的模型，jsps 提供视图.. 如果到目前为止我是对的，那么 servlet 链解决的目的是什么？它如何适合 MVC 的这张图片？

如果可能，请借助从请求到响应（端到端）的流程图进行解释。

非常感谢专家。请帮忙。我在任何地方都找不到这种解释。

【问题讨论】：

建议您查看ATG帮助中的DAF管道。这在基本级别进行请求和响应处理。 DAF 管道采用原始 http 请求/响应并转换为 DynamoHttpServletRequest/Response。 servlet 管道负责会话管理、安全性等事务。关于每个 servlet 的作用的文档有限，但通常名称很容易解释。还要记住，ATG 最初是为在 ATG 自己的 Dynamo 服务器上运行而构建的，并且使用了 DAS 管道，它比 DAF 管道做得更多。

标签： atg

【解决方案1】：

首先要记住 ATG 是一个旧平台。因此，当尝试通过 MVC 的视角理解不同的机制时，请记住，在设计任何东西时都没有考虑到 MVC——该平台早于 Web 开发中对 MVC 模式的广泛了解和接受。

Droplet 是一种通用机制，用于从 JSP（之前是 JHTML）模板调用 Java 代码。 J2EE 领域中最接近的类似物是标签库。因此，您可以使用它们来完成许多不同的任务。您也可以将它们用作穷人的 MVC 控制器。这是通过编写一个专门用于处理页面业务逻辑的自定义 Droplet 类，并将相关的页面状态设置为请求参数来完成的。然后调用 Droplet 作为 JSP 页面中的第一步。这与 J2EE 模型 2 没有太大区别，奇怪的是首先编译的 JSP 开始执行，然后调用“控制器”代码，然后继续处理“视图”。

顾名思义，表单处理程序是为处理表单提交而设计的。这些由 servlet 管道 (DAFDropletEventServlet) 中的链接在发布到的页面开始呈现之前执行。表单处理程序的典型用法是它们将在执行后发送重定向，并取消页面的呈现，这将中止 servlet 管道的任何进一步处理。表单处理程序是最接近 ATG 提供的“控制器”的东西。但是它们在处理 GET 请求方面很糟糕，并且在用于此目的时会导致一些非常不幸的 URL。

他们为什么要创建两种不同的机制？为什么他们没有随后引入更新的 MVC 模型作为平台的一部分？这些问题我无法回答。

【讨论】：

【解决方案2】：

在页面呈现级别上，ATG 不是 MVC。不要将其视为 MVC。 ATG 的核心是基本 Servlets API 的扩展。

表单和表单处理，successUrl 和 errorUrl 是一种 MVC。水滴当然不是。

在 ATG 应用程序中，在页面呈现时获取数据是完全可以接受的（即 Droplets）

【讨论】：