Getting data from main project html page?

Is there any way that I can pull data from the project.html page to use in the mainform.html page?


I have a case where integration is need from another program that uses POST forms with about 10 variables in the post data. 

If I post these to the project.html page via a generic sparkle server and can modify the content of the page and insert the hidden form fields needed, however those form fields and form are not accessible by anything within the application or the html code of the mainform.html page.

I have tried using something like...

document.getElementById("username").innerHTML =  parent.document.getElementById("GIG-NAM").value;

...but of course that doesn't work, as the project.html page really isn't a parent.

I know I may be missing a simple solution, something I should probably already know, but am currently stumped as to how to accomplish this. I could redirect the main request for the project.html and encode the data and add it as a url Query parameter and then use the GetQueryParam function, but wanted to avoid that if possible.

I'm not sure I fully understand what you try to achieve.

I understand that you want to post date of a form to a sparkle server and currently you do this directly from a HTML page but somehow want to integrate this with a TMS WEB Core application.
If this is the case, the more logical choice imho would be to perform the form post directly from a web core page. You can use the TWebHTTPRequest for this. Have you considered this?

A third party app needs to do a POST to my Web Core application.


A simple web core application always has at least two HTML files, the project.html and the form.html.

Since I am using a SparkleGeneric Server for static pages, I can capture the POST data at the server level, and the Sparkle Server will deliver the main "project.html" page. When it does, I can populate data into the project.html page when it is delivered to the client, however, the project.html page has the "rtl.run();" which when it starts requests the form.html page to display the actual page to the client.

When the form.html page is requested by the application, the original POST data is not available, as it was only available when the project.html page was requested. Due to this issue, I was hoping to populate hidden fields on the project.html page (which I can do) that I could then pull the values from on the form.html page via javascript, but items in the project.html page do not appear to be accessible from the form.html page.

This is a somewhat atypical scenario.
Have you considered using request parameters to pass the data from the Sparkle server to the web core client application? 
In unit WEBLib.WebTools, there are functions for getting access to the query parameter values: GetQueryParam(), HasQueryParam()

That will only work if the data is placed in a URL and the data coming is in the body  via an HTTP POST. It would be nice if there was a way to read values from the project.html page (hidden input) from within the Web Core app. Currently we are resorting to creating a cookie with all the data from the post so it will be available where needed within the Web Core app. We really don't like the idea of using cookies, but it is currently our best solution.

An alternative could be to use local storage. See WEBLib.Storage that has TWebLocalStorage to get easy access to this.

One way I found to work around the issue is to use the meta tags.

<meta id="cDat1" name="cDat1" content="Base64Encoded Data">

... then I can use document.getElementById('cVar1').getAttribute('content') to get the data, and have it available to every form. This allows me to stay away from cookies.

It seems the meta tags from the project page are always accessible to the program (and I hope this doesn't change down the road) and all forms within the program.

'cVar1' should be 'cDat1' in the example, I would have corrected it, but don't see a way to edit a post in this forum.


I have also learned to do a ctrl+a and ctrl+c before hitting the submit button since 99% of the time it complains my session has timed out (even on short replies)