1. #1
    Sencha User
    Join Date
    May 2011
    Posts
    12
    Vote Rating
    0
    danieljamesscott is on a distinguished road

      0  

    Default Unanswered: RpcProxy parameters

    Unanswered: RpcProxy parameters


    Hi,

    Can someone help me figure out how RpcProxy works in GXT3.

    The examples show RpcProxy definitions using e.g.

    Code:
    RpcProxy<FileModel, List<FileModel>> proxy
    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?

    Thanks,

    Dan Scott

  2. #2
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,734
    Vote Rating
    90
    Answers
    109
    Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light

      0  

    Default


    The idea is that it should be the data, if any, that you are sending to the server to load something. Check out the http://sencha.com/examples/#ExampleP...motefiltergrid example for more details on this:

    Code:
        RpcProxy<FilterPagingLoadConfig, PagingLoadResult<Stock>> proxy = new RpcProxy<FilterPagingLoadConfig, PagingLoadResult<Stock>>() {
          @Override
          public void load(FilterPagingLoadConfig loadConfig, AsyncCallback<PagingLoadResult<Stock>> callback) {
            service.getStocks(loadConfig, callback);
          }
        };
     final PagingLoader<FilterPagingLoadConfig, PagingLoadResult<Stock>> remoteLoader 
                    = new PagingLoader<FilterPagingLoadConfig, PagingLoadResult<Stock>>(proxy)//...
    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.

  3. #3
    Sencha User
    Join Date
    May 2011
    Posts
    12
    Vote Rating
    0
    danieljamesscott is on a distinguished road

      0  

    Default


    Thanks.

    But the grid example looks significantly different from the Tree example (which is what I'm trying to implement).

    For example, I would like a Tree which can display <? extends DBObject> objects (i.e. DBTable or DBView.

    The example implies that the two parameters to RpcProxy are Object, List<Object>:

    Code:
    RpcProxy<? extends DBObject, List<? extends DBObject>> proxy = newRpcProxy<? extends DBObject, List<? extends DBObject>>() {
    @Override public void load(??????? loadConfig, AsyncCallback<List<? extends DBObject>> callback) { service.getMusicFolderChildren((???????) loadConfig, callback); }
    };
    But this won't work because I need the type for the loadConfig object. I don't know what type I should use for the first parameter. How can I do this in GXT3?

    Thanks

  4. #4
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,734
    Vote Rating
    90
    Answers
    109
    Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light

      0  

    Default


    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.

    Code:
        final ExampleServiceAsync service = GWT.create(ExampleService.class);
        RpcProxy<BaseDto, List<BaseDto>> proxy = new RpcProxy<BaseDto, List<BaseDto>>() {
     
          @Override
          public void load(BaseDto loadConfig, AsyncCallback<List<BaseDto>> callback) {
            service.getMusicFolderChildren((FolderDto) loadConfig, callback);
          }
        };
     
        TreeLoader<BaseDto> loader = new TreeLoader<BaseDto>(proxy)//...
    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>>.

  5. #5
    Sencha User
    Join Date
    May 2011
    Posts
    12
    Vote Rating
    0
    danieljamesscott is on a distinguished road

      0  

    Default


    Thanks, it's starting to make sense now.

    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?

    Thanks.

  6. #6
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,734
    Vote Rating
    90
    Answers
    109
    Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light

      0  

    Default


    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.

  7. #7
    Sencha User
    Join Date
    May 2011
    Posts
    12
    Vote Rating
    0
    danieljamesscott is on a distinguished road

      0  

    Default


    Thanks for your input.

    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.

    Thanks

  8. #8
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,734
    Vote Rating
    90
    Answers
    109
    Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light

      0  

    Default


    That's interesting, I haven't seen that done much.

    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.

Thread Participants: 1