Günter Schenk :: Tutorials Corner
Adobe Dreamweaver Developer Toolbox

     

Using a Dummy table: how to outsmart ADDT

Author: Günter Schenk, Added: 22.12.2007, Updated: 26.01.2008

Table Of Contents

Title	Version
The Dummy table: purpose and structure	n/a
Sample Scenario: upload an image without storing the file name	n/a
Sample Scenario: send an email on page load	n/a

1. The Dummy table: purpose and structure

1.1. Purpose of using a Dummy table

As avid user of Adobe´s Dreamweaver Developer Toolbox you have surely noticed that several advanced ADDT Server Behaviours such as "File Upload", Image Upload" or "Send Email" can only get implemented if your page contains an "Insert Record" or "Update Record" transaction -- that´s of course fine so far and will in most cases be just what you need anyway.

But if you´re like me, you´ll inescapably be dealing with scenarios when you simply don´t have any data to insert or update, but would nonetheless like to send a series of Emails or upload an image from e.g. a popup window, and that´s why I´ve figured out this "use a Dummy table" workaround already in the old MX Kollection era.

This Dummy table has a pretty elemental structure, isn´t meant to provide any reasonable content at all, and has no real purpose other than "being there" for spoofing the Dreamweaver Developer Toolbox. Using this table will not even add any notable "overhead" to your server in terms of performance, and it will always be allocating approx. 2 kB file size, because you´ll just be updating the one existing record with some tiny bogus text.


1.2. Structure of the Dummy table

Here´s the MySQL compatible SQL dump which will create the Dummy table and insert one record:

CREATE TABLE `dummy` (
`id` int(2) unsigned NOT NULL auto_increment,
`dummytext` varchar(120) default NULL,
PRIMARY KEY (`id`)
) TYPE=MyISAM AUTO_INCREMENT=1 ;

--
-- Data for table `dummy`
--
INSERT INTO `dummy` VALUES (1, 'dummytext');

2. Sample Scenario: upload an image without storing the file name

This sample scenario is about uploading an image to a statically defined Upload Folder on your server; the "Redirect page" is a simple "thanks.php".

2.1. Create "thanks.php"

...and save it in the same directory that´s meant to contain the Upload Image page

2.2. Create an Update Record Transaction

a) invoke the Developer Toolbox´s Forms -> Advanced -> Update Record Transaction server behaviour

b) define the Update Record Transaction using the specification displayed next:



Although this screenshot certainly explains it all, let me add some comments on some of the indicated settings:

• "Primary key equals" an "Entered Value" of "1" -- huh, where the heck will that be "entered" later ? Well, no, the page will not have a text field for entering this value; this is just meant to be a predefined static value that´s required to ensure that some alias data will be written into the "dummytext" column of the table´s existing ID 1
• First check variable: Form Variable: KT_Update1 -- how comes, our page doesn´t have a form at all ? Don´t worry, this is what you´ll be adding to the page after having configured the Update Record Transaction

c) next: the "Fields" tab:



As the "Advanced" tab doesn´t need any specific settings, just confirm the Update Transaction Wizard with OK and return to the page -- here´s where we´ll now...


2.3. Create the Upload Image form

Let´s keep it simple & stupid by creating a simple form containing a File Field and a Submit Button, like this:



The only important ex post modifiction will be to change the Submit Button´s default "name" to "KT_Update1" -- remember the purpose of the "First check variable: Form Variable: KT_Update1" setting you previously specified in the Update Record Transaction´s "Basic" tab ?


2.4. Adding the Upload and Resize Image behaviour



This behaviour will detect the previously implemented form and the File Field´s "name" just fine, so the only thing left to do in the "Basic" tab, is to...

• select the Upload folder, and...
• have the file name stored in the table column "dummytext".
  
  What ??? Isn´t this tutorial all about uploading an image somewhere on the server *without* storing the file name at all ?? Yes, you´re right, but as ADDT´s Upload and Resize Image - behaviour will not let you skip this step, you´ll at least temporarily need to dupe ADDT by pretending that you´re seriously keen on storing the file name. That said, just confirm your changes with OK -- but next you´ll see how easy it is to...

2.5. Outsmart ADDT

a) switch the Dreamweaver page to CODE

b) locate the Trigger_ImageUpload function:



c) "comment" the $uploadObj->setDbFieldName("dummytext"); line by preceeding it with - PHP version - a double slash (//) in order to disable ADDT´s attempt to store the file name while still having it execute the Image Upload function.

"Comments" are of course available with the ASP and ColdFusion server models as well, so please check the documentation ;-)

3. Sample Scenario: send an email on page load

This sample scenario is about applying ADDT´s Send E-Mail server behaviour to a page, which will retrieve the E-Mail´s content from a recordset and send the E-Mail when the page loads; the "redirect page" is a simple "thanks.php"

3.1. Add a new table to your MySQL database

The following MySQL compatible SQL dump which will create the table "addt_tut_email_data" and insert two records

CREATE TABLE `addt_tut_email_data` (
`id` int(1) unsigned NOT NULL auto_increment,
`content` varchar(100) default '',
PRIMARY KEY (`id`)
) TYPE=MyISAM AUTO_INCREMENT=1 ;

INSERT INTO `addt_tut_email_data` VALUES (1, 'content column one');
INSERT INTO `addt_tut_email_data` VALUES (2, 'content column two');

3.2. Create two blank PHP documents

...and save them in the same directory. Name the first document the way you like (e.g. "send_email.php") and name the second document "thanks.php"

3.3. Add an Update Record Transaction

... to the page "send_email.php".

As you might guess, this Update Record Transaction will be updating your "dummy" table with the same bogus data as before, so the steps to define this transaction are *nearly equal* to what´s already been mentioned in the previous sample scenario.

"Nearly equal" ? What´s the the difference ? As this sample scenario covers the possibility to have ADDT execute an Update Record Transaction immediately when the page loads, some settings defined in the transaction´s "Basic" tab are different from the first example:



The only difference is what you´ll need to define in the "Select transaction starter event" section :: as this page will not contain a form and hence lacks a "Submit" button for triggering this transaction, you´ll now simply need to provide a predefined "Entered Value" of e.g. "1" -- it´s self-evident that you could actually enter whatever value you like.

In "real life" the abovementioned approach of executing whatever transaction based on a static value is certainly considered to be a *huge* security risk, as anyone could open this page in a browser -- that said, always make sure that your "official" applications will check an existing URL or FORM parameter that´s getting passed to this page !!!

3.4. Add a Dreamweaver Recordset



... name this one "mainquery" and have it retrieve the "content" column related to the "addt_tut_email_data" table´s Primary Key "1"

3.5. Add the ADDT "Send E-Mail" server behaviour



As this sample scenario is meant to send a test email to yourself, enter your email address to both fields "From:" and "To:".

In order to add some data from the previously established Recordset to the "Content" field, click the lightning bolt icon to the right and select the appropriate "Dynamic Data" as displayed next:




3.6. Testing the pages

Upload both pages to your server, try to remember the URL of where you uploaded "send_email.php" page, and open it directly in your browser -- this should send you the E-Mail just fine