Support for @webid in POST'ed data.

This new feature adds support for @webid in POST'ed data.  It works the same way as when @webid is used as a query parameter in a GET request.  That is, the referenced server cache is used to restore bundles and saved JPL global variables, but not to restore field data.  Restoration of field data is prevented, because it may have harmful side effects.  For example, if the cached field data came from a different screen than the one being requested, fields could receive the wrong content. Unnamed dynamic labels would receive data from unnamed fields in the cache having the same field number.

However, additional data may be POST'ed along with @webid, and that data will be used on the requested screen.  This data can include an event, such as pressing a push button by sending __pushed__ with a value that is the name of a pushbutton to press.

Note that EnableWebid must be set to a non-zero value in the INI file in order for this feature to work, same as for the @webid query parameter.

Here is a code snippet that uses jQuery, showing how this new feature can be used:

var path    = window.location.pathname;

var end     = path.lastIndexOf("/") + 1;

var newPath = path.substring(0, end) + screen;

var action  = window.location.protocol + "//" +

window.location.host + newPath;

var newForm = $('<form>',

                {

method: 'post',

action: action

                });

if (cacheId) {

newForm = newForm.append($('<input>',

                           {

name: '@webid',

type: 'hidden',

value: cacheId

                           }));

}

newForm.appendTo("html");

newForm.submit();

This new feature has the advantage that the value for @webid will be encrypted before transmission when SSL is being used, whereas query parameters in a URL are visible in clear-text.