Dr Design - Closing Popups and Propagating Data

This week, the Doc’s in fine form, tending all kins of maladies. Here he treats SSIs, popups, and more… but if you have a question that’s not covered, email him and let him know. He’ll be glad to help!

Closing a Popup on Onunload

Doctor, my question is similar to Anna’s, but I want the link in the content frame that loads a page to unonload a popup. There are links that open other windows on this page, and when a new window opens, I want to unonload a popup with the link.

Shuan

Shuan it’s not a problem. As you are no doubt aware, a pop-up window requires a bit of javascript to get going. Here’s an example of the javascript you’d have in the frameset document, which would open the pop-up when the frameset loaded.

In the following example we have the code for the frameset (frameset.html) and one of its child frames, top.html

frameset.html

<script language="javascript"> 

// var settings holds the settings for the popup window 

 

var settings = "toolbar=1, scrollbars=1, location=1, status=1, menubar=1,  

resizable=1, width=640, height=400"; 

 

// windowUrl holds the url for the popup window 

 

windowUrl = "url/to/popup.html"; 

 

// now let's open the popup window. 

 

outerName = window.open(windowUrl, 'innerName', settings); 

 

// function closepopup will be called to close the popup 

 

function closepopup() { 

   outerName.close(); 

} 

</script> 

<frameset rows="200,*"> 

<frame src="top.html"> 

<frame src="bottom.html"> 

</frameset>

As you can see, frameset.html will pop-up a new window. The function closepopup will close the pop-up window when it is called. Now, here’s the tricky part. We are going to call the function from the child frame.

top.html

<HTML> 

<HEAD> 

<TITLE>TITLE> 

</HEAD> 

<BODY> 

<a href="#" onclick="parent.closepoup()">close pop</a> 

</BODY> 

</HTML>

In my example (top.html) I have used an anchor and the onclick event to trigger the javascript function closepopup in the parent document, which is frameset.html.

However, you can see the principle here and apply it to your situation by calling parent.closepopup() for the onunload event of the document. You might also want to check out this handy tutorial on popup window javascript. Hope this helps!

More SSI Magic

Hey Dr. Design,

I have two questions. First, in your last article, you said to use SSIs, you use . Is there a difference between this and ?

Second, I built a template for a client, and am trying to make updates as easy as possible for myself — or whoever the Webmaster may be. So I thought I’d use server side includes for the header and footer.

However, the image with the page title is in a table, and is much “higher” than the content. So, I thought I’d use variables in SSI. Here’s what I came up with:

        <!--#set var="which" value="blah.blah" --   

       <!--#echo $which-->

However, nothing appears on the screen when I try to run this code. Where am I going wrong? Also, can I do the same thing to output attributes to other tags (i.e. <IMG SRC="[variable here]"> )?

Thanks Doctor! …and by the way, who REALLY writes the Dr. Design column? Matt? Kevin?

Corbb

Who’s side are you on, Corbb? Would you really want me to reveal my true identity and expose myself to the enemy? Also, I count three questions in your email – but that’s OK, I’ll only charge you for two ;-)

There is a difference between the virtual and file attribute in an SSI include command.

virtual tells the server that the path to the document is a virtual path, and this is commonly used when we want to insert the results of a CGI script. What is a virtual path? Virtual paths are specified by your Web host in the apache configuration file.

Examples of virtual paths are:

DocumentRoot /home/webusers/yourdomain.com/public_html

ScriptAlias /cgi-bin /usr/local/httpd/cgi-bin

So an example of using a virtual path in an include command would be:

<!--#include virtual="cgi-bin/some_script.cgi"-->

file tells the server that the path to the file is expressed as a relative path. So,

<!--#include file="menu.txt"-->

is telling the server the document menu.txt is in the same directory as the current document.

Now, on to your second question. SSI directives are comprised of a command followed by attribute/value pairs.

<!--#command attribute1=value1 attribute2=value2 -->

So the correct code for your example would be

<!--#set var="which" value="blah.blah" -->  

<!--#echo var="which" -->

Finally Corbb, you can do as you propose and insert a variable into a HTML tag.

For example:

<!--#set var="myimage" value="imagename.gif" -->  

<img src="<!--#echo var="myimage" -->">

For more information refer to the Apache SSI Tutorial and also, the NCSA HTTPd Server Side Include tutorial.

Propagating form Data and accessing the ASP Request Object

Hi Doc, I’ve got a problem with splitting up long input forms. I read what you had to say to Jeff and it sounded so simple at first, but when I got to do it I realised that I’m missing something… what am I doing wrong?

1) form 1 has form validation (checking validity of data) on. Is that correct?

2) I’ve got the submit button (as shown in step 1 of your notes), and form 1’s action is to form 2 (the page is called reg2).

<FORM ACTION = "reg2.asp" METHOD = "post"   

onsubmit = "return Validator(this)" name="Form1" LANGUAGE=javascript   

onsubmit="return Form1_onsubmit()">

3) My problem comes with collecting the info on pg2 from pg1…I’ve tried it with session variable in global.asa…

Sub Session_OnStart   

'**Put your code here **   

   Session( "LCode" ) = Request( "LCode" )   

Session( "LName" ) = Request( "LName" )   

etc etc...   

End Sub

Then I entered those session vars in the database (after forms 2’s submit)…

insert = "INSERT INTO Learner VALUES ( '" & _      

       Session( "LCode" ) & "','" & _            

               Session( "LSurname" ) & "','" & _   

   

               Session( "LName" ) & "','" & _   

     etc etc...

Please help! What am I doing wrong?

Janice

Janice, looking at your code, it could be a simple matter of having missed the dot operator “.” when trying to access the properties of the Request object.

For example:

Request("Lcode")

Should be

Request.("Lcode")

The above is still a shortcut and the MSDN documentation recommends accessing a Request variable through its collection. In your case, the collection is the Form data so you would access that as:

Request.Form("Lcode")

Why is this advised?

Firstly, the Request object is made up of several “collections” which themselves are made up of various variables sent by the client or which are predefined server environment variables. These collections are:

Collections

ClientCertificate: The values of fields stored in the client certificate that is sent in the HTTP request.
Cookies: The values of cookies sent in the HTTP request.
Form: The values of form elements in the HTTP request body.
QueryString: The values of variables in the HTTP query string.
ServerVariables: The values of predetermined environment variables.

When you don’t state which collection the variable is in that you wish to access, ASP has to look through all of them to find the one you want.

It is also less ambiguous as you are specifying you want the form data as opposed to the URL query string data, etc.

Using Hidden Fields

If sessions make you hair stand on end, an alternative is to propagate the data by embedding the form data from the first form into the second form using hidden input tags. Following on from your code, and example would be:

<FORM ACTION = "reg2.asp" METHOD = "post" onsubmit = "return Validator   

(this)" name="Form1" LANGUAGE=javascript onsubmit="return    

Form1_onsubmit()">    

<%   

   

Response.Write "<input type='hidden' name='Lcode' value='"    

& Request.Form("Lcode")  & "'></input>"   

%>

If you are having problems debugging the nit gritty of your code, you can always seek some assistance from the friendly crowd at the SitePoint Forums ASP forum.

Debugging Your Code

Regardless of which server side scripting language you choose there are plenty of powerful integrated development environments (IDEs) available these days, to help you write and debug your code. However, let’s face it, many of us love hacking away in the text editor of our choice. This brings me to a simple debugging technique you can use to find what is tripping up your code. The technique is simply this: print out variables and messages to the browser to see what is going on behind the scenes when your script executes. For a change of scenery, let’s use PHP for the examples below.

Pesky errors in my SQL always trip me up. I think my script is working, and test it out, but alas, whatever was supposed to be inserted into the database instead vanishes into thin air. SQL statements are often tricky things to write, especially when you are embedding variables in them (and especially when concatenating a SQL string using VBScript and become confuddled by quotation marks). When I’m debugging, I always look to my SQL first, because this is where I tend to slip up the most.

Step 1. Always assign your SQL string to a variable so that you can easily add a line to print it out to the browser.

For example, don’t write:

$result = mysql_query("SELECT * FROM TableName WHERE foo=$myFoo");

but write:

$sql = " SELECT * FROM TableName WHERE foo=$myFoo";    

$result = mysql_query($sql);

Step 2. For debugging purposes you can temporarily add the following line to your code:

// hmm, why isn't this working?     

// let's see what that SQL string ended up looking like    

echo $sql;

When you run the script you can even cut and paste into the browser window the SQL statement as output by your script, and fire up MySQL at the command line (assuming that, in this case, you’re using MySQL).

Paste the query into MySQL and see if the query results match what’s expected, or whether there is something wrong with the state of the data in the database. If this is the case, we know that we have to go looking elsewhere in our script or data model to work out why the data we expect to see in our database is not there.

Alternatively, when we output the SQL to the browser, we might pick up a simple syntax error; or we may discover that a variable we have embedded into the SQL string has a value different to what is expected, or has no value at all! Often this is because we inadvertently use the wrong name for the variable we want to embed in the SQL.

Perhaps this was just a typographic error, or maybe some data we thought was being sent to the script (in POST data from a form or in the URL query string) didn’t get to the script with the name attribute we expected. So how do we know that the data we expected to be sent from the client browser to the script, is actually there? You guessed it: we print out the values from our script for debugging!

For example, let’s say we have a form on page1.php which has an input field:

<form action="page2.php" method="POST">    

<input type="text" name="firstName"></input>    

</form>

Now on page2.php we want to check that that value is actually there. So we add some debugging code to the beginning of the script.

// start debugging code -- don't forget to remove!    

echo '<br />firstName :  ';    

echo $_POST['firstName'];    

echo '<br />';    

// end debugging code

Don’t forget to remove all your debugging code from your script once you have finished debugging!

Thant’s all for this week, see you next time, and don’t forget to send in your questions for my prompt attention!

Spread the love!

Dr. Design

Dr Design – Closing Popups and Propagating Data

Closing a Popup on Onunload

More SSI Magic

Propagating form Data and accessing the ASP Request Object