|CoverYourASP --> Submitting data to forms with IP*Works!|
|Many of you have been following along with the development of my other web site, ASPRSS.|
If you haven't, the site provides free sample code that allows publishers like me to share information about their articles using the RSS XML format. Sample code is also provided that allows directories (such as these) to read these RSS sources and submit them to their databases.
The ASPRSS subscription service
However, once the basic features were implemented I wanted to go one step further and provide a subscription service too. The service automatically submits new resources in the publishers RSS to the forms on all the registered directory sites (see an example). This article describes how that was implemented.
The idea was simple - read the RSS from the publishers, determine the new resources and submit them to the directory sites each day. As it turned out, the implementation using the /n software IP*Works! v5 component was easy too.
There is no way to submit data to a form using pure ASP code, so I had (briefly) considered writing another ATL COM component to do the HTTP POST. What dissuaded me in the end was the ease of use of IP*Works!, and the sheer number of objects supported - HTTP, FTP, POP, SMTP, NNTP and over 25 others...
Creating an instance of the component is the first step, accomplished as always by calling Server.CreateObject. All of the IP*Works! objects are prefixed "IPWorksASP".
Next, because I'm going to be submitting the same form multiple times to different directories, I initialize the form elements that will remain the same for all submissions.
The Referer property causes a Referer HTTP header to be added to the request - some sites may be interested in where the form submission is coming from.
The From property adds an HTTP From: header to provide the site with an email address to contact the submitter with. Both properties are optional, but why not set them?
All that changes between form submissions is the actual RSS data itself, so I can add the form variables to the object now. I'll just override one of the values in a moment as I loop through the publishers.
There are 2 ways to add the form variables; by setting the FormVar* properties as shown above, or by calling the AddFormVar VarName, VarValue method.
As you can see, I just have two variables to set (it's a very simple form - take a look). One is the URL of the RSS source (I'll fill in the value in a moment), and the other is the Submit button called "action".
The "ASPRSSAutoSubmit" value is hard-coded into the directory forms and allows me to simulate one of the Submit buttons being pressed, while still allowing the directories to alter the actual text on the buttons.
Having filled in 2 recordsets with the list of publishers (which I called oRSpub) and the list of directories (oRSdir) the next step was to loop through them, and submit to their forms:
Here you can see me setting the only data that changes between form submissions - the URL of the RSS source - by setting the FormVarValues ( 1 ) property that I left blank earlier. All that is left now is to submit the form.
There are 2 ways to submit the form (there are over 50 properties and 8 methods in this object alone) but the simplest is to call SubmitTo, and pass in the URL of the form.
I wrap the call in a try...catch statement which traps any errors that occur. A common one I got while testing (and one I suspect will still happen "in the wild") is when the form page is missing - submitting to a non-existent page will raise an exception with e.description set to "302 Object moved".
Note that in fact a 404 error occured, but many ASP sites redirect 404 errors to another page, causing a 302 to be returned.
I then display the contents of the StatusLine property so I can track the progress of the automatic submissions. A successful submission is displayed as "HTTP/1.1 200 OK".
That's it - how ASPRSS submits RSS data to all the registered directories! There is one more property that is very useful though - TransferredData.
You can actually see what the user would see if they submitted the forms manually by simply adding the following code inside the loop:
For debugging this was actually a very useful method - the results of the web form are displayed inline during the submission process. It's pretty strange seeing pages from other websites being displayed one after another as the submissions proceed!
As far as the WebForm object is concerned, I'm sure you'll agree it couldn't be much easier - and there are many properties that allow you to cope with whatever weird and wonderful firewalls, proxies and cookies you'll need.
Now I'm off to implement their WebUpload component with another 10 lines of code... ;-)