【问题标题】:Is is possible to attach EntityProxy to another RequestContext ? And should I?是否可以将 EntityProxy 附加到另一个 RequestContext ?我应该吗?
【发布时间】:2012-03-12 10:33:30
【问题描述】:

我有一个可以编辑我的实体的小表单。我使用 RequestContext 的一个实例创建该实体,然后在“保存”按钮的处理程序中尝试使用 RequestContext 的另一个实例来持久化它。

尝试持久化失败并出现预期异常:java.lang.IllegalArgumentException: Attempting to edit an EntityProxy previously edited by another RequestContext

问题是:

  • 是否可以将 EntityProxy 附加到另一个 RequestContext ?
  • 这样做对吗?或者我应该重用一个 RequestContext 保存它 作为我班级的财产?

【问题讨论】:

    标签: gwt requestfactory


    【解决方案1】:

    重复使用现有的。如果你需要一个新的,合并它们。但是做一个新的确实没有意义。原因如下:

    当您对服务器进行 RF 调用时,它会经过几个步骤,因为它主要针对如何读取和持久化实体以及它们使用的各种值属性。

    • 创建或检索任何要处理的实例
    • 将设置器应用于这些实例,无论是新的还是现有的,并验证它们
    • 运行服务调用,可以作为在实体上调用的方法、静态调用或服务调用。

    这三个步骤按此顺序完成,以确保修改后传递给服务调用的对象在到达那里时有意义。未来的调用(即其他请求)可能不需要对相同的实体进行相同的更改,如果需要,则需要自己进行更改。

    一个给定的RequestContext 包含所有这些东西。如果您有两个请求,一个代表要调用的设置器(来自表单的编辑),另一个代表服务请求,触发一个意味着只调用设置器,而不是服务调用来保存它,而触发另一个意味着只调用 save 而不调用服务。

    EntityProxy 被标记为由一个请求上下文编辑后,尝试在另一个请求上下文中使用它几乎肯定是一个错误,因此您看到的异常被抛出。使用现有的,或者根据需要使用RequestContext.append 切换到新的RequestContext 类型来实际运行保存操作。

    RequestFactory 不是 RPC - 您的对象不仅仅是 Java Bean,而是某些服务器对象的代理(EntityProxyValueProxy),并且请求用于异步操作它们。

    【讨论】:

    • Colin,您能否告诉我,在我使用上下文来持久化实体之后,我是否应该对上下文做一些事情?它适用于第一次调用,但所有后续调用都会导致 java.lang.IllegalStateException: A request is already in progress 被抛出。
    • RequestContext 是一种一次性builder。一旦你fire()d 它,它就不再可用(除非存在约束违规或由于网络错误导致请求失败)。
    • 唯一可以重用的情况是它在服务器上失败而可以重新发送 - 我相信唯一的情况是发生验证错误,所以设置器被调用,但服务调用没有。在用户纠正他们的验证问题之后,应该能够再次调用这些设置器,然后进行调用。
    猜你喜欢
    • 2020-05-09
    • 1970-01-01
    • 1970-01-01
    • 2013-12-25
    • 1970-01-01
    • 2020-07-29
    • 1970-01-01
    • 1970-01-01
    • 2011-09-06
    相关资源
    最近更新 更多