Hello Edward -

Unfortunately, POST parameters are only available server-side and are not exposed/available on the resulting page client side.  POST parameters are sent as part of the HTTP Request Body and are not in the URL itself like GET parameters.  VF is able to make these available via $CurrentPage because the code is executing on the server.  Since your skuid snippet executes on the client it’s too late in the request lifecycle to have visiiblity to them.  The only way to be able to access POST parameters on the client is to transpose them back within the HTML of the generated page.

It’s possible you could do this with a skuid APEX custom component although I’m not sure exactly if APEX skuid components are rendered on the client, server or both (Skuid folks??).  If even possible, it would effectively be the same as what you would be doing in the VF page but would allow you to avoid having the VF page.

Thanks for the response Barry.  I figured it had something to do with the fact that POST parameters are in the body and not in the url parameters string, but I didn’t really understand the difference between how a vf page was rendered and the skuid pages.  This at least clarifies the issue.  

I am able to easily use a vf page wrapper which includes the skuid:page component to display my wizard, and I’m just initializing a javascript variable directly in the vf page to the parameter.  Now I just have the problem with a remote call from the popup.

Hi Edward -

Glad it helped.  One other thing to make sure to test for using your VF solution is proper HTML encoding of the values in the array.  I’m not sure how VF handles this when accessing parameters via $CurrentPage.  For example, if one of the values in the array contains a quote character and if the value was not encoded the browser would think the string for accoundIds ended when really it hasn’t ended yet.  Depending on how VF handles parameters in $CurrentPage, you might need to wrap the {!$CurrentPage.parameters.IdArray} with an html encode statement.  Again, not certain you’ll need to do this since I’m not certain how VF handles this situation but something you’ll want to make sure you test for.  The safest solution would be to wrap your JS script block in a CDATA section.