Setting Up a Web Application

 < Day Day Up > 



Both static and dynamic pages are served to a browser from a Web server such as IIS, iPlanet Web Server, Netscape Enterprise Server, or Apache HTTP Server, that handles HTTP requests. To develop and test dynamic Web pages, Dreamweaver must have access to a Web server running the appropriate application server software. The Web server and application software may be

  • Local — Running on the same computer as the Dreamweaver application. This may be a complete solution or used only temporarily during the development process, after which, a remote solution is used.

  • Remote — Where the Web server and application software are set up on a computer that is accessed via FTP or through Local/Network (LAN). This is the most common solution for final publishing of dynamic content, where sites are either remotely hosted on virtual servers (one big computer that is subdivided into many separate domains or accounts) or on a Web server set up as part of a network of computers, most often the case in intranets, where all connected computers are behind a firewall.

With dynamic content, you must decide what type of server-side logic will be used to generate the undefined content. The Web page extension (.asp, .cfm, .jsp, and so on) is often the site visitor's only clue of a page's dynamic nature — it's the extension that tells the server to process the page via application server software. Different server technologies use specific programming or scripting languages to write the structured queries that make requests of the data source.

Dreamweaver supports five different technologies, which have their own requirements in servers and programming languages (see Table 46-1).

Table 46-1: Technologies Supported by Dreamweaver

Server Technology

Web Server Options

Programming Languages

Macromedia ColdFusion (.CFM)

Macromedia ColdFusion MX

ColdFusion Markup Language (CFML)

Microsoft Active Server Pages (.ASP)

Microsoft IIS or PWS

Sun Chili!Soft ASP

JavaScript or VBScript

Microsoft .NET (ASP.NET)

Microsoft IIS5 with .NET Framework

Visual Basic or C#

Sun Java Data Base Connectivity (JDBC)

Macromedia JRun

IBM WebSphere

Apache Tomcat

BEA WebLogic

Java

PHP Hypertext Preprocessor (PHP)

PHP server

PHP

Each technology has specific server requirements. Consult your computer's documentation to determine whether a specific technology is supported.

Defining a dynamic site

Of course, to work with Dreamweaver, a site must be defined, as you've seen throughout the Dreamweaver section of this book. To build dynamic pages using any data source, Dreamweaver must know what the server-side logic will be. You set this up in the Testing Server category of the Site Definition. To build dynamic pages that use content from a database, Dreamweaver must additionally know what type and where the database and its driver are.

Typically, a single server technology solution is used throughout a site. You enter information about the location of the Web and application server into the Site Definition. A Connection string is created that contains the type and location of the database and its driver based on the information you entered. Set up for your dynamic site is basically the same regardless of the technology, except that you might use a different driver, database, or server type and the syntax for connecting to the data source may vary. The concept is, however, the same.

Note 

The examples and exercises used in this chapter use a Microsoft Access 2000 database developed and deployed locally. A DSN-less connection string uses a Microsoft Access Driver, and the database is stored within the root\database folder with permissions to share the database folder given to all.

Using a local solution

Using Microsoft IIS or PWS on your local computer is a common solution when developing a dynamic site. You can set this up easily using either the Site Definition Wizard or in the Advanced tab's categories when defining a new site or editing an existing site. Although this is useful for development, it is seldom a final solution, because it is unlikely that your personal computer will double as a Web server. The Web server is often purposefully isolated (with software) from the rest of the network. By keeping it separate from the network, the data on other computers are protected from public access.

Note 

The Site Definition Wizard does not provide a means to define a local testing server and a remote application server. This configuration must be set up using the Advanced mode.

To define a dynamic site, you must set up the following:

  • A local folder where your working files are stored. This can be anywhere on your local computer, even using the same folder defined as the testing server root folder in the Inetpub\wwwroot directory, if you decide to use a local server solution, such as IIS or PWS. Otherwise, this would be the same folder you might use for the local root folder of a static site.

  • A remote folder in your Web server where your site will ultimately be published. This can be remotely hosted by another computer accessed via FTP, LAN, or could be your local computer if it serves also as a Web server connected to the internet (IIS or PWS). If you use your local computer, the folder will be in the Inetpub\wwwroot folder. Otherwise, this would be the remote root folder as you might set up for a static site.

  • The location of the application software used in testing and for final publication of the site. Generally, this is the same URL as the remote root folder, but it is not a requirement that it be so. The Web server and application server can be located on different computers. Dreamweaver also needs to know the URL prefix that is appended before page names during testing.

Using the site definition wizard (basic)

To set up a new site definition, follow these steps:

  1. Create a root folder for your Web application on the computer running the Web server. For example, on a computer running PWS or IIS, any file in the Inetpub\wwwroot folder or in any of its subfolders can be served to a Web browser.

  2. Choose Site ® New Sites (for new site definitions) or Site ® Edit Site (for existing site definitions).

  3. Click the Basic tab. In the Editing screens, you provide information regarding the local root folder for your site. First name your site; then click Next.

  4. Choose to use a server technology. Selecting this option adds a menu where you would choose your technology. For the examples used in this chapter, you would choose ASP/VBScript. Click Next.

  5. Choose how you will work with your files. For most users, you have four options, as shown in Figure 46-3. If using IIS or PWS on your local computer (to do exercises or for development only) the first option is most likely. For a practical approach and if you have the resources, the second option is realistic; you can develop locally and then move everything to a host Web server, which may entail building a different connection string. For Macintosh, you would likely use the same remote solution for development and publication. This screen is different on the Mac platform because you do not have the same local options as Windows users. You would choose to access a Web and application server connected to a network via LAN or use a remote hosted solution for both. Click the Next. Some options for Mac OSX exist locally but are not well-supported by Dreamweaver.

    click to expand
    Figure 46-3: Choosing how you'll test your dynamic pages

    Tip 

    Besides using the built-in Dreamweaver help pages, the Macromedia Dreamweaver support pages offer detailed tech notes that can help you troubleshoot all aspects of building a Web application, including site setup. Visit www.macromedia.com/ support/dreamweaver to read the latest tech notes.Tips and tutorials for all aspects of using Studio MX products can also be found in the Designer/Developer section of the Macromedia site www.macromedia.com/desdev.

  6. Choose the way you'll access the testing server. Choose FTP if using remote or LAN for a network server. If you chose to edit and test locally in the previous screen, you see a field where you enter the URL to the root folder in IIS or PWS. Typically, this would be something like: http://localhost/rootfolder.

    If you chose to test locally and publish remotely and you access your testing server via FTP, you need to provide the information necessary to access that server. This information is the same as what you might provide in the Remote Info category of a static site, except that the location should point to a Web server with application server software. If you access the application server via a LAN, you would browse to a folder in a Web server (with application software installed) on the network where you plan to store the files. Mac users typically choose a remote, hosted Web and application server option will provide FTP information for the host server.

  7. If a Test Connection button is visible, you must be connected (online) to get a successful result for the test. Test the URL to be sure that Dreamweaver can connect to the application server. Click Next.

  8. Provide a URL where you would browse to see your site pages. Generally, Dreamweaver pulls the appropriate information from previous entries, but the URL may not be accurate for your server. For example, Dreamweaver combines the host server information (n2dreamweaver.com) with the Host Directory information (wwwroot/siterootfolder) to produce the URL of www.n2dreamweaver.com/wwwroot/siterootfolder but this would not work correctly in some cases. Removing the wwwroot/ portion provides the appropriate URL. You can use the Test URL button to see whether Dreamweaver can connect using the URL provided by Dreamweaver, but if it fails, consider whether any of the directories in the path structure should be removed. In the previous example, wwwroot equals the public site of the domain www.n2dreamweaver.com. Although the wwwroot portion is necessary for FTP, it isn't part of the actual HTTP path to the public site.

The remaining screens offer options to use Check In/Out features and provide a summary of the choices you made in the Site Definition Wizard. Check In/Out is an option typically used in teams and provides a feature to identify and lock pages on the Web server when in use by a team member.

Tip 

Be sure to compare your Basic screens with the information in the corresponding Advanced screen to familiarize yourself with where each bit of information goes when using the Advanced setup.

Caution 

With your dynamic site defined, you can begin to build your site pages. The server model you've chosen defines the default type of page used for new pages. If using ASP/VBScript, using the right-click method to add a new file to your root folder in the Site panel results in an ASP page with the file extension .asp. Even if you give the file an .htm or .html extension during naming, code for ASP pages is automatically added to the page, which can result in errors during page previews. To build a basic HTML page in a dynamic site, be sure to use File ® New to access the New Document Gallery and choose a basic page.

On the CD-ROM 

See define_site.pdf in the chapter46_exercise files on the CD for directions to define the dynamic site "Administrative Intranet" using IIS or PWS. Mac users need to have a remote solution and follow steps in remote_hosted.pdf instead. PC users with a remotely hosted testing server can use remote_hosted.pdf, too.

Using the advanced site setup

Defining a dynamic site using the Advanced mode assumes you understand what the requested information is used for. You must complete three required categories:

  • Local Info — As with any Dreamweaver site definition, you must supply the site name and select a local root folder.

  • Remote Info — Select your Web server access using the Access menu options. This may be the same location as the testing server folder (next category) or a different folder on a remote server. A local testing option uses Local/Network access. A remote solution probably uses FTP, unless a company has set up special version control access. Consult your provider for details about the host server, host directory, login name, and password required to access your remote Web server.

  • Testing Server — Select a server model and choose your access method. Locate the testing server folder and supply the URL prefix. The testing folder may be local or remote. The URL prefix is the absolute path you would type to access your site whether local (IIS or PWS) or remote (a Web server accessed through the internet). Generally, a local testing URL prefix would be http://localhost/rootfolder. A remote URL prefix would be something like www.mydomain.com/ or if the root folder is not equal to the domain, www.mydomain.com/path/rootfolder.



 < Day Day Up > 



Macromedia Studio MX Bible
Macromedia Studio MX Bible
ISBN: 0764525239
EAN: 2147483647
Year: 2003
Pages: 491

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net