[CLOSED] Updated Store baseParams with setBaseParam not sent during Store.Load

  1. #1

    [CLOSED] Updated Store baseParams with setBaseParam not sent during Store.Load

    Hi,

    I'm finding a similar problem to what is described here:
    http://forums.ext.net/showthread.php...am-not-working

    In short, with a Proxy, if I update a baseParam using setBaseParam, the updated value does not get sent in the Load call. Instead the old param is passed.

    I have modified your own Handler example here:
    https://examples1.ext.net/#/GridPane...rting/Handler/

    I have added just 2 things:

    1) To demonstrate the problem: a TopBar with a button, which, when clicked updates the 'limit' base param with a different value (e.g. mimicking the ability to change the page size). It then goes back to page 1 which forces a reload:

        <TopBar>
            <ext:Toolbar runat="server">
                <Items>
                    <ext:Button Text="Set Page Size to 10" runat="server">
                        <Listeners>
                            <Click Handler="#{Store1}.setBaseParam('limit', 10); #{PagingToolbar1}.changePage(1);" />
                        </Listeners>
                    </ext:Button>
                </Items>
            </ext:Toolbar>
        </TopBar>
    On its own, the above does not work. If you inspect the request, you see the original 'limit' being sent. Hence this second bit:

    2) A workaround: a BeforeLoad listener to the Store that will apply the updated params to the params object that is passed to the server. I would expect that setBaseParams should be enough and this BeforeLoad listener would not be needed?

        <Listeners>
            <BeforeLoad Handler="Ext.apply(options.params, this.baseParams, options.params);" />
        </Listeners>
    Have I missed something or is the BeforeLoad handler always needed?

    Btw, I can see the same problem with a PageProxy. Using your own example:
    https://examples1.ext.net/Examples/G..._Sorting/Page/
    In Firebug, you can run these two commands:
    GridPanel1.store.setBaseParam('limit', 2);
    GridPanel1.bottomToolbar.changePage(1);
    If you inspect the Post, you will see the limit sent back to the server is 3, not 2.

    Let me know if you want full examples.
    Last edited by Daniil; Dec 02, 2010 at 7:50 AM. Reason: [CLOSED]
  2. #2
    Hi,

    I think here is an answer:
    baseParams : Object
    An object containing properties which are to be sent as parameters for every HTTP request.
    Parameters are encoded as standard HTTP parameters using Ext.urlEncode.
    Note: baseParams may be superseded by any params specified in a load request, see load for more details.
    This property may be modified after creation using the setBaseParam method.
    Here is a link to ExtJS docs article:
    http://dev.sencha.com/deploy/dev/doc...ber=baseParams
    http://dev.sencha.com/deploy/dev/doc...re&member=load

    So, basaParams "limit" parameter is superseded during invoking of .changePage() because this method calls internally the .load() method.

    If you would try something like this:
    store.setBaseParam("foo", "bar")
    you will see "foo" parameter with "bar" value in POST.
  3. #3
    Quote Originally Posted by Daniil View Post
    So, basaParams "limit" parameter is superseded during invoking of .changePage() because this method calls internally the .load() method.

    If you would try something like this:
    store.setBaseParam("foo", "bar")
    you will see "foo" parameter with "bar" value in POST.
    Hi,

    Thanks for quick response. You are right, params passed in Load supercede anything set with baseParams (which is why I had to resort to the BeforeLoad listener).

    But, because of that, doing the setBase('foo', 'bar') will only work IF 'foo' was not set during object construction (i.e. it is a new base parameter). In my example in the first post, I simply modified your existing example from the solution explorer to show this.

    In other words, (based on the Handler example I mention in the original post above) when NOT using the BeforeLoad listener workaround I mention:

    • Updating the existing "limit" base parameter using setBaseParam (and not using the BeforeLoad listener), means the new value is NOT sent.
    • Seting a new parameter, e.g. setBaseParam('searchTerms', 'blah'), means 'searchTerms=blah' WILL be sent in the post...

    So, in terms of usage scenarios:

    • If you want ability to change page size, it seems you have to use the BeforeLoad listener workaround
    • If you want to pass more data like doing a server side search on that grid (depending how your store works) then setBaseParam is enough
    • To offer a mixture of this kind of thing, you have to use the workaround.

    This feels inconsistent in terms of expectation of setBaseParam. But the issue is really with Load() using options where options.baseParams is different to the result of doing setBaseParam!

    I guess this is ExtJs behaviour and not an Ext.Net thing per se, then...

    If so, I guess we can mark this as closed, and for anyone facing a similar problem, to see the BeforeLoad workaround if they want setBaseParam to apply to existing and new base parameters...?

    (If you agree this is an ExtJs behaviour, and if you think it is an issue, perhaps you can raise a ticket to let the store Load use the most recently updated set of baseparams rather than the original set -- your voice has more weight than mine there in terms of response etc, I find. If you do raise a ticket with Sencha, perhaps add a link to this thread to track it?)
  4. #4
    Your explanation is excellent as always:)

    If you want ability to change page size, it seems you have to use the BeforeLoad listener workaround
    You could set PagingToolbar's .pageSize property on the fly and it will be applied during the next page's change.
    http://dev.sencha.com/deploy/dev/doc...ember=pageSize

    If you want to pass more data like doing a server side search on that grid (depending how your store works) then setBaseParam is enough
    You are right.

    I guess this is ExtJs behaviour and not an Ext.Net thing per se, then...
    Yes, this is ExtJS behavior in according to their docs. We did not override this part.

    But we added <WriteBaseParams> (Store's section in markup).

    For example, the following code in the markup
    <WriteBaseParams>
        <ext:Parameter Name="limit" Value="5" Mode="Raw" />
    </WriteBaseParams>
    generates the following js script:

     beforeLoadParams: function(store,options){if (!options.params){options.params = {};};Ext.apply(options.params,{});Ext.applyIf(options.params,{"start":0,"limit":3});},
     beforeSaveParams: function(store,options){if (!options.params){options.params = {};};Ext.apply(options.params,{});Ext.applyIf(options.params,{"limit":5});}
    As you can see this will be applied during "save" request (for example, store.submitData() causes this request).

    So, you are on the right direction. If you will need to override baseParams in the future you will know how it can be done:)

    But, repeat myself, to change a page's size you could use the respective pageSize property.
  5. #5
    Thanks for the pageSize property note. I guess I used a bad example, but that was actually useful for me to know, anyway :)

    Thanks for the update and the note on WriteBaseParams as well.

Similar Threads

  1. Replies: 2
    Last Post: Jan 16, 2012, 10:34 AM
  2. Replies: 2
    Last Post: Apr 27, 2011, 12:29 PM
  3. baseParams, setBaseParam not working
    By mj.daly in forum 1.x Help
    Replies: 2
    Last Post: Nov 19, 2010, 3:48 AM
  4. [1.0 RC1] Add FileUploadField to Store's BaseParams
    By Maarten Boone in forum 1.x Help
    Replies: 0
    Last Post: Nov 13, 2010, 10:04 AM
  5. Replies: 2
    Last Post: May 06, 2010, 8:08 AM

Posting Permissions