setting dynamic parameters

Hello,

I am setting some dynamic parameters through a script by using the scrapeableFile.addHTTPParameter() function. However when I run another script after this one that uses the scrapeableFile.getCurrentPOSTData() function to get the POST parameters (that's what I assume it does :roll: ) and print them out to the session's log, this function returns null.

Is the scrapeableFile.getCurrentPOSTData() function used to get the POST parameters? That's what I understood from reading its description in the documentation. If not then...
1) What is this function's actual role?
2) How can I check that addHTTPParameter() has actually added the parameters?

Thanks in advance for any help. 8)

setting dynamic parameters

speedster,

The basic function of getCurrentPOSTData is to return the post parameter contents from the previous page and is not intended to be used to verify the existence of post data prior to requesting the page.

Is it your intention to respond conditionally on the basis of the value of a given parameter that you previously set using the addHTTPParameter method? If so, I'm wondering if there isn't an alternate way you can check for the given value.

Could you explain a bit more about your methodology?

-Scott

setting dynamic parameters

Sorry this does not help. I do this but I still get null as the return value.

My first script adds the POST parameters and sets a session variable to the return value of scrapeableFile.getCurrentPOSTData() as follows:

for &#40; int i=0; i < session.getVariable&#40; "NumOfActivityEventParams" &#41;;
      i++ &#41; &#123;
    session.log&#40; "Adding 'ActivityEventKey' parameter with the " +
                 "following credentials&#58;" &#41;;
    session.log&#40; "name&#58; " +
                 session.getVariable&#40; "ActivityEventKey" + i &#41; &#41;;
    session.log&#40; "value&#58; " +
                 session.getVariable&#40; "ValueActivityEventKey" + i &#41; &#41;;

    scrapeableFile.addHTTPParameter&#40;
        new com.screenscraper.common.HTTPParameter&#40;
            session.getVariable&#40; "ActivityEventKey" + i &#41;,
            session.getVariable&#40; "ValueActivityEventKey" + i &#41;,
            sequence++,
            com.screenscraper.common.HTTPParameter.TYPE_POST &#41;
    &#41;;
&#125;

session.setVariable&#40; "currentPostData", scrapeableFile.getCurrentPOSTData&#40;&#41; &#41;;

This script does output to the log so I know the session variables I'm using to add the POST parameters have values.

My second script simply reads the "currentPostData" session variable and prints it out to the log like so:

session.log&#40; "GET HTTP Post Parameters&#58; POST data is&#58;\n" +
                                                 session.getVariable&#40; "currentPostData" &#41; &#41;;

The output of this script however is:

[quote]GET HTTP Post Parameters: POST data is:
null[/quote]

So what is the problem here?

setting dynamic parameters

speedster,

A local variable is returned when you call the method. So, if you're wanting to access the results of the method on a script other than the script making the method call then you'll want to save the data in a session variable.

For example. Your first script that calls the method may look like:

currentPostData = scrapeableFile.getCurrentPOSTData&#40;&#41;;

session.setVariable&#40;"currentPostData", currentPostData&#41;;
session.log&#40;"1. currentPostData**" + session.getVariable&#40;"currentPostData"&#41; + "**"&#41;;

And your second script that needs to write out the results of the previous page's post data could look like:

session.log&#40;"2. currentPostData**" + session.getVariable&#40;"currentPostData"&#41; + "**"&#41;;

I hope this helps.

Thanks,
Scott

setting dynamic parameters

I am using Pro v3.0

setting dynamic parameters

speedster,

It could be that what you're experiencing is the result of a bug we just fixed in basic edition. If you're using 4.0 basic edition would you please download the installer and try it once again?

If you're using a different version then we'll need to look in to it.

Thanks,
Scott