GWT DefaultRequestTransport：什么时候/为什么要扩展？

Question

我看过几个GWT代码摘录，其中开发人员扩展了DefaultRequestTransport并为其提供了自定义功能。 DefaultRequestTransport中就是这样一个例子。但是除了这个示例以外，我还看到了其他几个示例。

我的问题：何时及为何有人需要扩展此类并重写其方法？ （换句话说，此类做什么，其方法执行什么服务以及为什么需要自定义它们？）

在那个例子中，this SO question regarding authentication/login filters方法被覆盖。根据有关该方法的Javadocs，其目的是：

创建一个将HTTP响应映射到TransportReceiver接口的RequestCallback。

对我来说，这仍然是一个神秘的解释。有人可以给我一个外行的解释，说明在什么情况下扩展此类并重写其1+方法是有益的？

Answer 1

RequestFactory不依赖特定的“传输”机制；它处理请求和响应的JSON表示形式，但是它们交换和转移的方式是out of scope，并推迟到createRequestCallback。

RequestTransport使用DefaultRequestTransport到给定（但可配置）的URL；因为它使用RequestBuilder，所以只能在GWT客户端中使用（编译为JavaScript）。还有RequestBuilder，它使用UrlRequestTransport，并且可以在JVM中运行的任何客户端上使用（服务器调用另一个服务器，Android应用程序，桌面Java应用程序等）]

理论上（因为我从没有尝试过，也从未听过别人尝试过），您可以制作一个使用Comet或WebSockets或任何您想要的传输方式的java.net.HttpURLConnection。当然，服务器端也必须进行调整（RequestTransport可以轻松地在SimpleRequestProcessor之外重用；这是类似的[[关注点分离）]

返回RequestFactoryServlet：它使用DefaultRequestTransport，并提供了一些挂钩，您可以覆盖它们以自定义其工作方式。最常见的用例是在解码JSON编码的RequestFactory响应之前，拦截所有请求以添加一些请求标头（例如凭据）和/或所有响应以处理特定的HTTP响应（例如，拦截“未经授权”的响应以要求用户登入）。RequestBuilder充当RequestFactory API和DefaultRequestTransport的适配器，RequestBuilder是其中的一半，负责调整响应。

Answer 2

在所示示例中，他们需要扩展DefaultRequestTransport以便检查所有RF服务器响应并捕获401状态（SC_UNAUTHORIZED），这意味着该请求在服务器端被拒绝，因为用户没有有效的会话，然后重定向该请求。用户进入应用程序登录页面。

我也使用DefaultRequestTransport更改了requestUrl（默认设置为createRequestCallback），因此我可以根据url模式设置过滤器：例如，已认证的RF服务转到gwtRequest或未经过认证的射频服务转到/myapp/gwtRequest等。>

我还有一个定制的RequestTransport，它使用RequestBuilder和XMLHttpRequest的修改版本，能够监视正在进行的事件，对于大型请求非常有用。

您可以扩展它以发送用于进行CORS身份验证的自定义标头或其他。

总结/myapp/anonymousRequest是修改RF的客户端传输层的方法。