My Portal Project

A customer application that was written a few years ago with ASP/VBScript had been migrated from an Access front end. The basic structure is ‘main entity’ with multiple ‘child entities’ and Access is good at working with data in this fashion. All you have to do is split the screen with the main entity on the left and the right half can display whichever child entity is selected. So we designed the browser app to look the same. For performance reasons, we designed it so that when you picked a main entity, the app would load all of the child entities into a table and hide the rows that were not needed. When a user wanted to see a certain child entity, the app made that row of the table visible.  Alot more data up front, but alot less little requests over the long run.  Since this is the side of the app used for data maintenance, the forms are always in "edit mode".

Problem is this, the Access front end handles all of the record updating for the developer and is seamless for the end user. Browser apps CAN be done this way, but there are alot of issues to think about.  So the app was designed so that there were two "Update" buttons; one on the left to update the main entity, and one on the right to update whichever child entity was visible. Although confusion about two buttons was a concern, early user testing led us to believe it was not a very big concern.

Now it is a priority, so they want a single update button.  So we have an HTML form for the main entity, a blank form to create a new child entity, and a form for each existing child entity, and we need a single button to submit them.  Second, since some main entities can have 25 child entities, I had to find a way to only submit those entities that have been "changed".  Lastly, the main entity form was posted to ASP page "A", and child entity was posted to ASP page "B", and I had ZERO desire to rewrite all that back end code to handle a new submittal method.

But all the hub-bub about AJAX and the research and learning I did to figure it out finally paid off.  How about if I could write some Javascript to POST each "changed" form to its appropriate ASP page, in an HTML POST format?  From a javascript array of "changed" forms, I loop through and concatenate each field element into a single string in the HTML POST format (field1=fieldVal1&field2=fieldVal2&etc..).  I then use the XMLHttp object to send the post to the page specified in the Form’s "Action" property.  I add a little VBScript to send back a response, and bingo!

Now ASP/VBScript has dreadful error handling so if my little XML string makes it back to the calling javascript function, then I am good to go.  Otherwise, all I have is the error page that ASP sends.  I send each form post from a pop-up window so I can use it like a status box, and depending upon the number of errors, I can decide if I want to update the main page to see the changes.

One last thing, the reason I keep referring to "changed" forms in quotes is that I am lazy and chose not to implement some fancy-pants field array methodology to track actual changes to a form.  Each form has an "onClick" event handler that adds the form name to the array.  I initially tried using the onKeyPress event, but since there are some checkboxes on the form, these needed the onClick to catch them.

I will package everything in a Domino database again, and since this is a Javascript solution, I will put together some html/js files for anyone else.
Update: the demo for this is now here

UPDATE: By popular demand, the javascript file that does the magic. Keep in mind that from the single submit button I popped up a new window where I could show the results of the multi-submit, so one of the first lines that established the array of forms is looking for window.opener

This entry was posted on Friday, September 2nd, 2005 at 9:50 pm and is filed under Microsoft, Portals, Code Bin, Web Development. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.