Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

What is the best practice to pass more than 10 parameters from one page to other page. Is there any way other than passing the values in the url or using the same controller.

PS : Can this be done using static variables?

share|improve this question
3  
Is there a reason you don't want to use the same controller? It is a viable option in some cases. See Creating a Wizard – Daniel Ballinger Mar 8 at 21:00
    
@DanielBallinger We need to hit different services on page load for both the vf pages. Using same controller can cause delay on loading the page. – shannu Mar 9 at 18:26
    
You could use different action methods for each Visualforce page to make the service callouts. You don't need to do everything in the constructor. – Daniel Ballinger Mar 9 at 18:56
    
@DanielBallinger Can I use POST data using jquery and redirect to the second vf page? – shannu Mar 9 at 19:39
    
Umm, maybe? I guess if you can construct the same POST request with all the viewstate information (and CSRF token) you could make it work. But why not just use the native Visualforce postback? – Daniel Ballinger Mar 10 at 0:56

There are a few other ways you could accomplish this. The following options are provided in no specific order, and should not be interpreted as an order of preference.

First, if the value is less than about 4kb worth of data, you could set cookies, perhaps setting one cookie per value or even JSON-encoding the data (serialize) from the source and then JSON-decoding the data (deserialize) at the destination.

Second, you could always store the data somewhere safe, like a personal Document, which you could then retrieve by Id; this way, you're only sending one parameter across the wire.

Third, you could use the Platform Cache, if you have it available to you. It does come at some cost (as I understand it), but it's incredibly handy for storing data temporarily.

Fourth, you could use a Custom Setting of the Hierarchy type. Perhaps a bit overkill, but it would allow you to structure the data and set/get it as needed. It's a bit more permanent than the cache (which could disappear at any time), but it's a free feature, and you can just delete the values when you're done.

Fifth, you could use localStorage along with some apex:actionFunction JavaScript to set the values on page unload (on the sending side), and loading it back at the destination. This would be a more AJAX-y approach that would provide a more responsive UI. The limit here is about 2,500,000 Unicode characters, which is more than almost any other option can provide, except for using Documents.

Explicitly referencing static variables, however... you can't rely on this working even if you share a controller, because those variables are transient, and wouldn't survive the trip across transactions.

Personally, I'd suggest using session cookies if the data should fit within the allocated space, as it's free and is client specific. However, if you're worried about users peeking at the data, you might want to encrypt the cookies beforehand when using cookies or a Document. Custom settings and the Platform Cache don't need to be encrypted normally, as only administrators can see that data, though. Just remember that both of those features are server-side and have pretty severe limitations (1MB per license with a maximum of 10MB).

share|improve this answer

Static variables are not preserved across requests because requests can be routed to any of many servers: this allows Salesforce to scale so well.

If the 10-15 parameters are each of relatively limited size e.g. ID values or flags or short strings (so that the URL doesn't get too long) then passing them as parameters is reasonable and easy to do. So you only need to look for an alternative if you have a reason to do so - maybe YAGNI.

share|improve this answer
    
Coincidentally, Salesforce has a pretty severe limitation regarding URLs it can process. After about 4kb worth of URL, it just... breaks. – sfdcfox Mar 8 at 17:37
2  
@sfdcfox Think we may have had this comment discussion elsewhere here. My best Googling suggested 2k was safer given things like proxy servers. But 2k still leaves 100 characters per parameter so a lot of information can be passed with some clear and simple code. – Keith C Mar 8 at 17:40
1  
I'm certain I've had a question about URL length before. It's just so hard to find a specific question when you're in the top 1% of site users... I'm not sure if it's my Google-fu, or just the way things are, but I can never seem to find one of my old answers when I need it. – sfdcfox Mar 8 at 17:42
    
My requirement is like we are displaying data in a pageblocktable where there is a hyperlink for one column. Clicking on the link will redirect to the second vf page(opens in subtab) along with the parameters(data from selected row). User can open mutiple subtabs. For this will I be able to proceed with cookies? – shannu Mar 8 at 17:50
    
@shannu If that row of data is in the database you can just pass the ID and the second page can query what it needs. If the row isn't e.g. the fields are editable then they would fit in the URL unless the table is incredibly wide or a field has a large amount of text in it. Using cookies or other mechanisms is IMHO over complicating this. – Keith C Mar 8 at 18:06

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.