Why is extTID now required? about extdirectspring

[ralscha]

Hi.
ExtJs always sends extTID when it's a form post method. IMHO this should
throw an error if this parameter is missing.
But I can change this if there is a use case where extjs does not send an
exttid.

On Thursday, 23 August 2012, kevhender wrote:

We just updated to v1.2 from v1.0.15. I noticed that the constructor for
ExtDirectResponse has changed from:

public ExtDirectResponse(final HttpServletRequest request) {
action = request.getParameter("extAction");
method = request.getParameter("extMethod");

String extTID = request.getParameter("extTID");
if (extTID != null) {
tid = Integer.parseInt(extTID);
}
type = request.getParameter("extType");

}

To:

public ExtDirectResponse(HttpServletRequest request) {
action = request.getParameter("extAction");
method = request.getParameter("extMethod");
tid = Integer.parseInt(request.getParameter("extTID"));
setType(request.getParameter("extType"));
}

Essentially, the extTID parameter is now REQUIRED, and if it is not there,
an exception is thrown. This has broken some of our calls. Is there a
reason why this was changed? Thanks.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/40.

[kevhender]

Thanks for the quick response.

We are using simple @ExtDirectMethod methods that return ExtDirectResponse objects. These methods are not form POST handlers, so it seems that this is why that param is not passed.

Are we wrong to use ExtDirectResponse return objects in this case? We are using them for the simplicity in building them, but I suppose it's possible that we could do without that in these cases.

It might still be something that you could change back, though, if that parameter is not essential in other places.

Thanks again.

[ralscha]

You should not use ExtDirectResponse in your code. This is an internal
class.
@ExtDirectMethods should just return any object and this object is then
wrapped in a ExtDirectResponse object by the library.

If your code returns ExtDirectResponse all your responses are double
wrapped. I wonder how you deal with that on the client side.

On Thu, Aug 23, 2012 at 7:10 PM, kevhender [email protected] wrote:

Thanks for the quick response.

We are using simple @ExtDirectMethod methods that return ExtDirectResponse
objects. These methods are not form POST handlers, so it seems that this is
why that param is not passed.

Are we wrong to use ExtDirectResponse return objects in this case? We are
using them for the simplicity in building them, but I suppose it's possible
that we could do without that in these cases.

It might still be something that you could change back, though, if that
parameter is not essential in other places.

Thanks again.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/40#issuecomment-7976694.

[kevhender]

That's interesting to know, it seems that we've always just dealt with it as needed. Thanks for clarifying this, we will look into our options. Keep up the great work, we're very pleased with this project.

[ralscha]

My guess is that your code looks something like this:

@ExtDirectMethod
public ExtDirectResponse doSomething(HttpServletRequest request) {
ExtDirectResponse response = new ExtDirectResponse(request);
response.setResult("the result");
return response;
}

and the call on the client

service. doSomething (function(result) {
var v = result.result; //because response is double wrapped
});

The prefered way looks like this:

@ExtDirectMethod
public String doSomething() {
return "the result";
}

service. doSomething (function(result) {
var v = result;
});

If you don't want change the client code you could create a wrapper object
and return this from the ExtDirectMethod method. The name of the class does
not matter. Important is the name of the property (result).

public class Wrapper {
public Object result;
}

On Thu, Aug 23, 2012 at 8:54 PM, kevhender [email protected] wrote:

That's interesting to know, it seems that we've always just dealt with it
as needed. Thanks for clarifying this, we will look into our options. Keep
up the great work, we're very pleased with this project.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/40#issuecomment-7979968.