Remove "sortField" and "sortDir".

I am evaluating Ext GWT as our new tool to replace Flex and I need to disable sorting on the grid to test one of our data sources in XML. Our data source does not accept any URL query parameter not defined in the code and every time I try to load the grid in Ext GWT it adds the parameters "sortDir" and "sortField" to the URL. I tried to disable sorting on the grid and on the store using many properties and suggestions I found in blogs and docs but these parameters are always added which causes the HTTP to return 404 (Not Found). How can I remove them?

In short, yes. And your sort info (and filter info) will still get to, and be available from, the server.

A more lengthy answer:

I would argue that while there may be a use case for doing so, 99% of the time, one would not use URL parameters when using a POST and indeed, I don't know of any web browsers that will let you add add URL request parameters to any POST operation. Apparently, though, it is allowed by the HTTP spec (which was news to me) so one could theoretically do it programmatically.

Well, modifying to POST did not change anything, the parameters "sortField" and "sortDir" are still being passed but now via POST which causes the same error. My issue is that I need to block them from being appended to the URL completely, no sorting of any kind either on the client or on the server.

They shouldn't be on the URL, they should be in the message body. Or is this what's breaking your code?

If you don't want them sent at all, the only way I can think of shutting it off is to execute the call and update the list store manually. If you're using any type of load config (paging or filter) these are going to be sent.

Alternatively, and this solution just doesn't feel right, you may be able to add a request filter to your filter chain and call HttpServletRequest.removeAttribute(...). But again, this solution doesn't feel right. Also, I think this will only work for a POST as there doesn't seem to be a way to remove parameters.

The HttpProxy takes a writer instance that decides how to serialize the data to a string, and put it on the url. By default, the UrlEncodingWriter iterates over all properties and adds them as url parameters.

It is possible to write a custom DataWriter that will take a config object, and write out only the values you need to the url string, in the format you desire. Assign this to the HttpProxy (or any proxy that passes a string to the server), and it will use that to turn the config into data.

I must be doing something wrong because my HttpProxy does not have a default UrlEncodingWriter. Instead, I just get toString called on the PagingLoadConfig, which spits out the class name. I'm really confused because the PagingGrid example obviously works, but I don't see any writer set there. And I've searched all the source. How can I get this working?

The HttpProxy takes a writer instance that decides how to serialize the data to a string, and put it on the url. By default, the UrlEncodingWriter iterates over all properties and adds them as url parameters.

That said, HttpProxy does not have a default instead of UrlEncodingWriter - without one, it must default to trying to .toString() the config data passed in. UrlEncodingWriter doesn't have a constructor that HttpProxy can invoke, because generics don't allow it to know what config Class<?> instance to use, or what AutoBeanFactory. Additionally, there are use cases (especially when using HttpProxy with POST) where UrlEncodingWriter won't make sense.

Thanks, Colin, that makes more sense. I was able to get the UrlEncodingWriter working with the HttpProxy by referring to the AdvancedComboBox example.

I really hope you have some awesome documentation about the data binding coming with the full release of GXT 3. All the flexibility and power has created a massively steep learning curve and it's really hard to figure out which parts of the various examples are applicable to my situation.