1. #1
    Ext GWT Premium Member icfantv's Avatar
    Join Date
    Sep 2011
    Location
    Superior, CO
    Posts
    411
    Answers
    20
    Vote Rating
    21
    icfantv will become famous soon enough icfantv will become famous soon enough

      0  

    Question Unanswered: PagingLoadConfig and SortInfo API question

    Unanswered: PagingLoadConfig and SortInfo API question


    I assume the PagingLoadConfig takes in a list of SortInfo objects so as to be able to sort by multiple columns if necessary.

    That said, was there a reason there was no implementation was provided for just one SortInfo object as a convenience?

  2. #2
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,645
    Answers
    107
    Vote Rating
    80
    Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice

      0  

    Default


    We've tried in GXT 3 to make all of the possible data calls as flexible as possible. The main ones we are concerned with are RPC, RequestFactory, and Autobeans, as these are three general facilities offered by GWT itself. If data can be requested and loaded for these three things, then it should be compatible with any mechanism that works on Java types.

    For RPC, any object can go over the wire as long as it is marked as serializable, and all of its fields also can go over the wire. To find those fields, an actual implementation (or implementations) must be provided, and must be known to both client and server.

    AutoBeans require only that an interface is defined for the data to serialize/deserialize, and it will turn all get/set calls into that wire format. Autobeans allow other methods (through the @Category annotation) to be declared, and defined statically elsewhere. The only requirement from Autobeans is that the data must be defined by an interface - it has the capability to create an implementation.

    RequestFactory builds on autobeans, but only allows for get/set methods - no category methods can be used. This limits how data can be defined - we have to keep it to simple bean-like interfaces to ensure that RF can understand these objects.

    The only way I see to allow a convenience method (two setters, but only one getter which reads from both) would be to create it in PagingLoadConfigBean, but you would need to know throughout your application that this is the only implementation that can be used, and cast everywhere. To add it to PagingLoadConfig would require both a getter and a setter, and could result in ambiguity about which property is authoritative. - if both are set, do you combine them into one list?

    I hope this explains the thinking behind how this works - if you have an idea as to how we can make it easier to use, but still as flexible as possible, we would be interested to hear it.

  3. #3
    Ext GWT Premium Member icfantv's Avatar
    Join Date
    Sep 2011
    Location
    Superior, CO
    Posts
    411
    Answers
    20
    Vote Rating
    21
    icfantv will become famous soon enough icfantv will become famous soon enough

      0  

    Default


    Hey Colin, thanks again for a thorough reply.

    I think for this case, I'm only concerned with RPC as I just started implementing grid sorting and paging yesterday and so my knowledge is still somewhat superficial.

    I had extended PagingLoadConfig and it's bean counterpart but never was able to get it to work as I was running into a problem with the PagingToolBar.bind() method. No matter though, because I found that mucking with the PagingLoadConfig object passed in to RpcProxy.load(...) actually caused more problems and that the solution to get everything working correctly was to just step back and get out of the way.

    That said, to answer your question, I would either have the single-setter option for SortInfo simply call the setSortInfo(List<SortInfo>) method creating the list internally so the developer doesn't have to, or if this smells funny, to have a single SortInfo field in the bean class. In this latter case, I would say that it would be an error condition to call both setters. I think aggregating both to a common list could yield potentially unexpected behavior and a developer may not immediately understand why something is happening. Finally, if order is important, wouldn't a SortedSet<SortInfo> make more sense here given that redundant SortInfo objects might also be considered an error condition?

  4. #4
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,645
    Answers
    107
    Vote Rating
    80
    Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice

      0  

    Default


    That said, to answer your question, I would either have the single-setter option for SortInfo simply call the setSortInfo(List<SortInfo>) method creating the list internally so the developer doesn't have to, or if this smells funny, to have a single SortInfo field in the bean class.
    Thats the issue - when using AutoBeans or RequestFactory entities or values, there is no 'internal' from our perspective - the implementations are generated, and we don't get to say how it works.

    The fix would be to use both, and hope that all server implementors check both properties.

    PagingToolbar.bind had some generics issues - it should be safe to just do a raw cast to send the loader in. This looks a lot nicer in SVN, but could still use some attention.

    If you could share (or link to) your troubles with using a custom load config, I'll take a look - we've tried hard to make it as flexible as possible, occasionally at the cost of the generics being more complex than most users want to deal with.

  5. #5
    Ext GWT Premium Member icfantv's Avatar
    Join Date
    Sep 2011
    Location
    Superior, CO
    Posts
    411
    Answers
    20
    Vote Rating
    21
    icfantv will become famous soon enough icfantv will become famous soon enough

      0  

    Default


    Ah. I see.

    My interface extension wasn't anything fancy, it was just an extension that allowed for the setting of a single SortInfo object in addition to the list. That is, it extended and added an interface method to PagingLoadConfig of setSortInfo(SortInfo) and extended the bean counterpart to implement this.

    Then, all my PagingLoadConfig references became MyPagingLoadConfig but again I ran into trouble with PagingToolBar.bind(...).

    That said, as previously mentioned, I found that mucking w/ the PagingLoadConfig object in RpcProxy.load created more problems in that it broke grid sorting so I found that not mucking with it (and thus, removing the need to have the single-setter option) caused everything to work correctly.

    I do agree that the generics everywhere make things a little unwieldy but as you say, it adds enormous flexibility and in return allows the developer to make extremely flexible (and more importantly, reusable) widgets/tools. As an example, our first web app conversion has 13 grids and they can (and do) all use the same widget/tool to do all the column config, list store loading, grid building, paging, etc..., because of the generics and doesn't require 8 different constructor arguments. So, I appreciate that.

Thread Participants: 1

Tags for this Thread

film izle

hd film izle

film sitesi

takipci kazanma sitesi

takipci kazanma sitesi

güzel olan herşey

takipci alma sitesi

komik eğlenceli videolar