Sign Up ›

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
MarkL.ax269MarkL.ax269 

custom list controller and pagination/pagesize resets URL parameters

This is twisted, but I'll try to lay it out.  I've got a visualforce page being accessed via a URL button from the account page, with some parameters being added to the URL from the account.  The page contains a list of custom object records related to the account, accessed via a custom list controller.  I'm doing this because I want to use the standard controller for the custom objects (I'm updating them in the same screen), but the list has to be dynamic because it only shows those records related to the source account (so standard list controller isn't an option), and it works beautifully.

However I just implemented the simple Previous/Next pagination links and a selectList to set the pageSize, and discovered that they will reset the entire page to the base visualforce page URL without the parameters.  I used those parameters to specify limits on the custom list controller.  So the net result is something like this:
  1. Click URL button on account, new VF page is presented with the correct related records
  2. Click Previous/Next link, works fine, returning the pages of related records, BUT removes the params from the URL
  3. Change pageSize in the selectList to something else, rerenders the navigation links and the pageBlockTable
  4. Apparently causes my custom list controller to RESET and with the parameters removed, now I have a completely different set of records!
First, why would the previous/next methods cause the URL parameters to be removed, and second, why does changing the pageSize cause my custom list controller to re-run?

Mark
jhartjhart
Mark,

I believe I ran into something like this awhile back.

My solution was to move the prev/next paging links into actionFunctions and use partial page refresh to re-render only that portion of the page.  The parent page still has its GET args, and if you construct your controller properly it should remember the initial state (loaded from the GET args) plus any changes you've made during your partial page refreshes.

Moving away from parsing your own GET args is a good thing (or, at least, it was for me).

-john
MarkL.ax269MarkL.ax269
Thanks John.  That's essentially how I'm solving the problem, instantiating the controller in the constructor and then putting the results into a class variable that shouldn't be changed, so I won't be calling it directly any more.  But two things just don't make sense here.  First, I can sort of see why calling getPageSize also performs a full "get" and re-pulls the query but it sure seems like it shouldn't.  And second, there's no reason why calling getPrevious or getNext should obliterate the URL parameters.  That definitely seems like a bug.

[edit] I should mention that adding a simple rerender to the previous/next links does maintain the URL.  However something strange happens with getPageSize.  The URL params are still present, but apparently they have been removed from my map variable and the query is re-run on calling getPageSize without those parameters, resulting in a different set of records being returned.  Very strange.

Mark


Message Edited by MarkL on 11-25-2008 08:59 AM
MarkL.ax269MarkL.ax269
I think there's clearly a bug with the StandardSetController.getPageSize method, unless I'm doing something wrong.  The page saves as written below, meaning it expects there to be a 'getPageSize' method on the ssc class variable.  However loading the page in the browser with the controller as shown results in a VisualForce error Unknown property 'Variable__cStandardController.pageSize'.  So something run-time disagrees with compile-time.

If I un-comment the pageSize lines in the controller (which I think are clearly incorrect), the page loads just fine.  However now we have a different problem.  The ssc variable is directly instantiated in the constructor, meaning the state should be maintained and the query should not be re-run.  But selecting a new size results in the map variable being cleared (tough to trap in the debug log) and the ssc query running again with Account__c = '', returning a very different record set.  Apparently the constructor is being reloaded, but not consistently since the map is cleared (even though the parameters are still present in the URL).

Code:
<apex:page id="thePage" title="Variable Management - {!acct.Name}" standardController="Variable__c" tabStyle="Account" extensions="accountVariableController">
<apex:actionRegion >
 <apex:outputText value="Records per page: "/>
 <apex:selectList value="{!ssc.pageSize}" size="1">
  <apex:selectOption itemLabel="10" itemValue="10"/>
  <apex:selectOption itemLabel="15" itemValue="15"/>
  <apex:selectOption itemLabel="20" itemValue="20"/>
  <apex:selectOption itemLabel="25" itemValue="25"/>
  <apex:actionSupport event="onchange" rerender="vlist,navigation"/>
 </apex:selectList>
 <!-- <apex:outputText value=" {!ssc.resultSize}"/> -->
</apex:actionRegion>
</apex:page>


public class accountVariableController {
 
    public map<String, String> mapURLParams = new map<String, String>();
    //public Integer pageSize { get; set; }
    public ApexPages.StandardSetController ssc { get; set; }

    public accountVariableController(ApexPages.StandardController controller) {
     this.mapURLParams = ApexPages.currentPage().getParameters();
     //this.pageSize = 50;
     this.ssc = new ApexPages.StandardSetController(Database.getQueryLocator([select Id, Name from Variable__c where Account__c = :mapURLParams.get('recordid')]));
    }
}

 If I get specific with it like below the same problem occurs,  mapURLParams is cleared and ssc is re-run.  So I'm going to remove the selection option now and the users will just have to get by with the default size=20 list.

Code:
 public Integer pageSize {
  get { return this.ssc.getPageSize(); }
  set;
 }

 




Message Edited by MarkL on 11-25-2008 10:06 AM

Message Edited by MarkL on 11-25-2008 10:08 AM
jhartjhart
Mark,

You might want to avoid StandardSetController altogether - it seems quite buggy.

I was experimenting with using it to replace our own home-rolled pagers, but have found two bugs:

StandardSetController or QueryLocator ignores SOQL where clause [ link ]

and

StandardSetController getHasNextPage incorrect [ link ]


I won't be trying the StandardSetController again for a couple releases at least.

As an aside: Because Salesforce doesn't have a developer-accessible bug database [ link ], we have no way of knowing when they fix these except trying our own test cases again.
MarkL.ax269MarkL.ax269
I think you're right and I would add a couple of bugs specifically with the pageSize attribute of StandardSetController - disconnect between compile and runtime I noted above, as well as reloading the controller constructor, apparently using a no-argument, no-body version.  I'm too far down the road with this app right now to abandon it, and fortunately the other functions are working well.  Hopefully this will get an interim update, and yes it would be a GREAT idea to see what bugs Salesforce is working on!  I'm promoting that one.
jhartjhart
Mark,

The "soql where clause" bug no longer reproduces, so either I was utterly clueless when I posted (always a possibility) or it somehow got side-effect-fixed in the patch release that went out last night.

>> Update - it does reproduce whenever StandardSetController.setPageSize() is called.  I posted a video to that thread.

The other issue I reported - about the "getHasNextPage" being faulty - still reproduces but is a relatively minor bug that can probably be worked around in the controller.

Still hoping for a bug DB that we can view/access!  I'm never sure if something I posted about / log a case about will get fixed really quickly, or if it will get no response at all  (like this one) - in which case, I don't know if it's being worked on or not.


Message Edited by jhart on 11-26-2008 01:32 PM
dchasmandchasman
I have been personally fighting to get some form of public bug database support but so far this has been very much an uphill battle. I have been citing case after case where this kind of thing has become a common practice but so far no joy and I share your frustration.

As for the setPageSize() bug I am working on it right now but I do not expect to have a release vehicle for this until Spring '09 because we are essentially in lockdown for Winter '09 at this point... Looking for a workaround too...


Message Edited by dchasman on 11-27-2008 02:29 PM