by Mark Trescowthick - GUI Computing
Does the world really need another telephone listing application in ASP, I hear you ask. And the answer's probably 'No' I suppose. I think that the number of ASP coders who didn't cut their teeth on this sort of application can probably be counted on the fingers of one foot!
The basic phone listing has two frames, one in which to search, the other in which to list results and is really ASP 101, I agree. But recently, I was asked to enhance one, and it got just that bit more interesting…
The request was for the table listing details to have columns user-selectable. This struck me as strange, as the Intranet on which the listing was running was not heavily used and had a pretty fast server. And full details were only one click away - why need to select what was displayed on the listing panel? It turned out that this made it more convenient to print out and distribute to all and sundry… so much for the electronic office!
This seemed a pretty simple request - I could just add some checkboxes to the top of the listing and, when they wanted to change the columns, they could select what they wanted and click a "List" button and the panel would refresh. I presented this and was immediately told that this meant that the printouts(!) would look ugly with all that rubbish at the top of them… back to the drawing board with another frame to add.
The problem I had was one which has annoyed us all at some time or another… I had to target one frame for the main listing and another for the listing options. This is probably clearer if I draw…
I originally had a nice easy setup, where the Search Frame was targetted at the Main frame. I now had to still target that frame (because if only one row was returned, I wanted to go straight to full details for the row and I needed all the real estate I could get) but the Listing Frame now had to be a child of the Main Frame, and it still had to target that Main frame. The Options Frame had to target both itself and the Listing frame (otherwise the checkboxes wouldn't refresh).
This took a bit of nutting out, but sounds simple now. What I did was interpose an ASP between the search and the listing, and make sure that both the Options and Search feed it. It is then smart enough to decide if it simply wants to update the columns in the listing or whether it's a new search request. If it is the former, then the ASP turns itself into a frameset, if the latter then it first goes to the database and checks on the number of records that will be returned and handles things accordingly.
This approach is made a lot simpler by the use of Session variables (at least we don't have to construct our SQL more than once, though we do open the database twice. In fact, I could have made it a bit "smarter" and not opened the database to check numbers of records if it was a columns update being requested… but this is a multi-user system, and you just never know. Those sorts of assumptions can get you in all sorts of trouble, every now and then.
Handling framesets and targets is a right royal pain in ASP, as I'm sure we're all aware. But I've yet to find anything that flat out can't be done… it just takes that hint of the devious! I'm more and more convinced that ASP really is Sensitive New-Age CICS…
The code is available for download.