RpcProxy parameters

The second parameter is the return type from the proxy, same as GXT2, right? What is the first parameter for? Does it have to be the same type as the items in the list?

The documentation describes it as 'loadConfig' which appears the same as the first parameter in calls to 'load' in GXT2 - so if I want the same behaviour as in GXT2, which object should I use for the first argument in the RpcProxy?

Notice that the first parameter is the load config, the same object that is coming from the loader, and is being used to make the actual request to the server. The Loader here is defined at PagingLoader<FilterPagingLoadConfig, PagingLoadResult<Stock>>, and it will have a FIlterPagingLoadConfig to send to the server (or whatever the proxy does), and expects the proxy to give it back a PagingLoadResult<Stock> object.

Sorry, I didn't see any part of your post specific to the tree data, so I answered in general - the loader expects to send a load config, so the proxy should handle one as its first param.

This applies to Tree loading as well - the tree loader send, as its config, the parent it wants items for. So the parent item _is_ the load config in your case, which the loader's generics should make clear (as well as its constructor arg's generics).

Looking then at a tree example which uses RPC (http://sencha.com/examples/#ExamplePlace:asynctree), we can see how generics in the proxy are dependent on the loader. Remember that the function of a proxy is to go and get data from some source, usually at the request of a proxy, so the two types need to agree on what is being used to load the data, and what is being loaded.

Assuming you use the default tree loader, it is expected that the proxy takes as a param any given node, and will respond with a list of that same type. In your example this gets a little hairy because you are trying to use a wildcarded paramter, ? extends DBObject. The example above casts to FolderDto because we are ensured that only a FolderDto ever has children, so only a FolderDto will ever be passed to the proxy via the loader. If you can make the same assumptions in your code, a cast may be appropriate.

A wildcard will be difficult to use in that code, it might be worth trying to confine it slightly, or just specify DBObject itself. How is your Tree and TreeStore defined? If you specify TreeStore<DBObject>, then it almost certainly makes more sense to talk about a TreeLoader<DBObject> and a RpcProxy<DBObject, List<DBObject>>.

I'm trying to understand all of the data structures, so I didn't mention Tree in the first place. But maybe this specific example will help.

It doesn't really matter to me how I implement it - maybe I should just describe what I want to do.

I want to display a tree which can contain 3 types of object. Database objects (DBObject), tables (DBTable) and views (DBView). In my existing GXT2 application, I have a DBObject and then I extend this to create DBView and DBTable. The tree displays 2 DBObjects which are the parents and then the tables and views are the children (and possibly extend this another level so that the tables and views contain DBColumn children). My existing proxy, tree, loader and store contain <? extends DBObject> objects.

Do you have any suggestions for how to implement this in GXT3? I thought the existing design was correct. The tree only displays objects which extend DBObject. I guess I could force the returned children into lists of DBObject objects, but I'd need a flag to differentiate between them - this seems to eliminate all the benefits of the inheritance. Maybe my inheritance structure isn't the correct way to go?

How did you build this in 2.x? Either there was some kind of type check, or you read from some flag in the data to indicate what kind of item each was, to decide how to draw it - why not continue with this in 3?

The example we are looking at contains folders and files, both of which extend from BaseDto, so checks are done when rendering and looking at items to decide how to respond in certain cases. In all of these cases referencing the store and data widget as using BaseDto makes more sense than ? extends BaseDto.

Is there a reason you are using the wildcard? It isn't enough that each of these things refers to some subclass to make it worthwhile - it should actually mean something. Otherwise it would make more sense for ListStore<M>.get(int) to return ? extends M, since it is possible that the object at hand isn't M but a subclass. The extends keyword has a specific meaning, and using it outside of there generally will cause problems.

Try referring to your store as ListStore<DBObject>, and likewise the Tree, Loader, and DataProxy. I think you may find that this makes sense - if not, consider posting what you have and why it doesn't work.

In GXT2, I was using ? extends DBObject pretty much everywhere in the tree, loader, store, etc. Server side, I read the name of the parent and decided whether to get List<DBView> or List<DBTable> to return. I didn't really treat them differently client side, so I guess I didn't really need to use <? extends ...>.

I've managed to fix it for now - The tree, loader, store, etc. use plain DBObjects. Server side, I cast from List<DBTable> to List<DBObject> before returning the data.

One of the problems with GXT 2 that we attempted to resolve in 3 is that some of the generics were contradictory or confusing - regular casts were needed in a number of places where generics could have been enough, and some generic casts resulted in ClassCastException, especially when teams were getting started. In 3.x this should mostly be resolved, but some cases like your might run into problems.

It is possible that the TreeLoader could be less specific, but I think in this case that not using a wildcard is actually the correct answer.