Static vs dynamic websites vs application development environments
1 / 71

Static vs Dynamic Websites vs Application Development Environments - PowerPoint PPT Presentation

  • Uploaded on
  • Presentation posted in: General

Static vs Dynamic Websites vs Application Development Environments. Professor Mike Smith City University Medix UK. Prerequisites. What is HTML? Understand forms and CGI processing? If not, explanation follows. Websites. Static websites Dynamic websites. Static websites.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.

Download Presentation

Static vs Dynamic Websites vs Application Development Environments

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

Static vs Dynamic Websites vs Application Development Environments

Professor Mike Smith

City University

Medix UK


  • What is HTML?

  • Understand forms and CGI processing?

  • If not, explanation follows ...


  • Static websites

  • Dynamic websites

Static websites

  • Major components

    • HTML

    • JavaScript

    • Style sheets

    • Files

    • Directories

Pro: static websites

  • Easy to start

  • Easy to understand - initially

  • Easy to test individual pages

  • Tools insulate developers from raw HTML

Pro: static websites

  • Tools fairly inexpensive and easy to learn

  • Open source/freeware HTML editors

    • Amaya

    • Open Office

  • Word processors

    • Microsoft Word

  • Commercial HTML editors

    • Microsoft FrontPage

    • Macromedia Dreamweaver

Pro: static websites

  • Aligned with web designers’

    • Skills

    • Experience

    • Orientation/culture

Style sheet only global formatting





“Long page”

Field placement

Format (e.g., colour)

Format rules








Con: static websites

Con: static websites

  • Little reuse of effort

    • Every page may be or become “hand-crafted”

  • Maintenance > ca 50 pages becomes difficult to impossible

    • Link checking

    • Finding pages

    • Global changes, even with style sheets

Con: static websites

  • Irregularities creep in

    • Style/format

    • Navigation

  • Structure dissolves

  • “Cruft” develops

  • Management information lacking e.g.,

    • last update, author, reviewer, next review date

Con: static websites

  • Special functions needed

    • Security or login

    • Content search

    • Client customisation/configuration (“personalisation”)

    • Active functions or “push services”

    • Information collection

    • Information display

    • Navigation logic

Con: static websites

  • JavaScript often used to “personalise”

    • Functions obscure

    • Difficulty of debugging

    • Reliability of operation (?)

    • Browser incompatibilities

Con: static websites

  • JavaScript often used to “personalise”

    • Functions obscure

    • Difficulty of debugging

    • Reliability of operation (?)

    • Browser incompatibilities

Con: static websites

  • Forms and processing

    • Not well supported

    • Perl and CGI

    • ActiveX

  • No session concept

    • stateless nature of web forms

    • connects forms to a “session” or user




access methods


Dynamic mark-up language

Programming language

Form generation and processing (should be)

Compiled vs interpreted

Compiled may produce static website into files and directories

Session concept

Dynamic websitesMajor components (typical)

Pro: dynamic websitesprovide or should provide

  • Global functionality/formatting

  • Active functionality

  • Client related functionality

  • Content searching

  • Database collection/instrumentation

  • Database retrieval

  • Programmatic function

  • Security, login function

Pro: dynamic websitesbenefit from

  • Modularity

  • Abstraction

  • Data, format and function/logic separation

  • Easier overall understanding of structure

  • Rapid navigation to individual pages for maintenance

Pro: dynamic websitestend to lead to

  • Need for application building functionality

    • Form generation

    • Form processing

    • Database integration

    • Application navigation and logic

    • Report generation

Con: dynamic website tools

  • May not insulate developers from raw HTML

  • May conflict with

    • Web designers

    • Programmers

    • Existing website structure

    • Programmer – web designer separation

    • Those experienced with other systems

Con: dynamic website tools

  • Can be difficult to learn

    • Concepts may be difficult, even for computing professionals

    • Complexity (e.g., Tomcat) horrific

    • Skills and syntax usually are product specific

  • Functionality

    • May be restricted or partial

    • May not work or work as expected

    • May not scale well (software or performance)

Con: dynamic website tools

  • Cost (e.g., ColdFusion, Oracle Developer/Client Server, Microsoft ASP)

    • Acquisition, annual support/licensing fees

    • Training and familiarisation

    • Support

    • Forced upgrades

    • Scaling costs (per user licences)

  • Open source systems avoid up-front and licensing costs

Still have forced upgrades

Documentation may be very poor or excessively technical

Questionable support and reliability

Often single developer (individual) reliance

or key parts

May be forced into commercial relationship with developers

Management, investor and technician resistance

Increasingly, concerns about intellectual property rights

Con: dynamic website open source tools

Selecting an Application Development Environment

  • Dynamic web serving often leads to application development

  • Application development implies

    • Web based but with conventional IT system functionality

    • Heavy logic functionality

    • Database management system (DBMS) oriented or should be

    • User input and GUI considerations

Selecting an Application Development Environment

  • Environment style

    • Template based – mark-up language with code embedded OR

    • Code based – HTML (or other mark-up language) produced by program

    • Does it matter? Yes!

      • No - probably ignorant of system development

      • Template systems may be weak, awkward or rigid when used for “serious” application development

Selecting an Application Development Environment

  • Wide range of environments available - tend to be:

    • language based

    • database based

The “classic”



Code-based style

Runs on almost all operating systems, DBMS

Perl language “peculiarity”

Steep learning curve

Development and maintenance difficulty and costs

Probably quite easy to “sell” into organisations without technical preconceptions

Application Development Environment - Perl

Own programming language, proprietary DBMS (Oracle)

Complete HTML insulation, perhaps to an excessive degree

Client-server model

Proprietary web server

“No brainer” choice in some organisations

Documentation good

Most functionality provided

Expense of licenses and training (probably >£100k)

Practically requires full-time DBA to operate

Application Development Environment - ORACLE

Visual Basic

Excellent HTML insulation via and Front Page

Proprietary server; proprietary DBMS

Avoid Access for serious applications

Good functionality

Rapid development

Costs of licenses and training (probably >£20k)

Performance issues (?)

“No brainer” choice in many organisations

Application Development Environment - Microsoft ASP


Own programming language

Functionality seems good; reliability questioned

ORACLE DBMS oriented but others supported

Documentation seems good

Expense of licences and training (probably >£50k)

Difficult to sell in organisations with no previous experience

Application Development Environment - ColdFusion

Wide range of offerings, e.g., TomCat

Good technical documentation

Complexity of Java programming

slow, costly development

Client-server model and application server

Run-time considerations

Java engine required for browser

Application Development Environment - Java

Increasingly popular


Code and template styles

Many systems available open source

Creates confusion

Dissipates “mass”

Might not be too difficult to sell into organisations without technical preconceptions

Language looks too much like Perl to me!

Application Development Environment - PHP

Substantial popularity and open source

Single source, single community, single commercial “outlet” (Zope Corporation)


Code and template styles

Easy installation

Adequate documentation

Python based

Own server; weird port assignment; range of DBMS supported

Performance good, allegedly scaleable

Application Development Environment - Zope

Why chose Zope?

Pro: Zope

  • Python

  • Entirely web-based, therefore multi-user

  • Free

    • They try to get you to buy the book

  • PC and Linux available

    • Excellent database/DBMS integration

    • MySQL, Postgres, even Oracle, probably SQLserver

    • Built-in relational (Gadfly)

Pro: Zope

  • Excellent database/DBMS support and integration

    • MySQL, Postgres, even Oracle, probably SQLserver

    • Built-in relational (Gadfly)

    • Built-in object database

    • Wonderful, clean programming interface (ZSQL)

Pro: Zope

  • Easy to install

    • PC

    • Linux

  • Easy to learn

  • Built-in editor

  • Good performance, allegedly highly scaleable

Pro: Zope

  • Good starting and good technical documentation

  • Many packages available, most easily imported

  • Powerful site searching

  • CGI interfacing

    • Simple form field referencing

    • Defaults for testing

    • Aspects can be confusing (see below)

Pro: Zope

  • Brilliantly easy backup and application porting

    • just copy one directory

  • Although when this author started, Zope lacked a session manager, it now appears to have one

Con: Zope

  • Rather web-developer, template oriented

    • Poor insulation from HTML

    • DTML not much removed from HTML

    • Python programming uses DTML or raw HTML

    • Mainly in way documented, Not intrinsic

  • DTML horrific in serious use

    • Particularly in variable passing

    • ZPT being introduced but this author has no experience in it

Con: Zope

  • Issues with forms interfacing

    • Null field handling

    • Multiple field handling

    • “slash” reference to processing modules

Con: Zope

  • Object orientation

    • Obscures understanding

      • e.g., context.path.routinename

      • Cf, Python import statement

    • Awkward and inconsistent referencing style

      • Dot reference, e.g., context.forms.radiobutton

      • Slash reference, e.g., application/forms/registration

    • Module auto-generation is difficult

Con: Zope

  • Database package interfaces

    • not easily installed cf Zope

    • not maintained as part of the Zope core

    • Not always reliable or up-to-date

      • E.g., MySQL

  • But, wish that ZSQL was available to “normal” Python for database interfacing!

Con: Zope

  • Conflict with existing Python installations

    • Zope has its own Python copy and uses this

    • May create problems with software using later Python versions

    • May create problems if you try to use some of the Zope modules externally

Con: Zope

  • Does not facilitate large system development

    • Web-based editor “peek hole” too small

    • No built-in version control (but there is a good undo)

    • No multiple authoring features (but there are packages for this)

Con: Zope

  • Object orientation limitations

    • Difficult to understand Zope internals

    • Ironically, seems to limit scope for rapid object development inside the Zope architecture

    • Difficult to use Zope components outside Zope

Con: Zope

  • Zope is very complex

    • Some of the documentation appears intended to impress other techies rather than to inform those seeking understanding

    • You may need to dedicate your life to Zope to gain full mastery

    • This author only takes a “good enough” approach, which probably isn’t really good enough

Experiences in Web Development

  • Small websites from 1995

  • Java in 1996

  • Major developments

    • from 1999

Medix website

  • Deliberate minimisation of dynamic component to just

    • user registration

    • login

    • push questionnaire function

  • Design agreed for static component

    • Format/”look”

    • Navigation

Medix website

  • Static left to web design firm

  • Not too costly, initially

  • Author needed to focus on dynamic component

Web design

Non-technical users pushed for complex navigation function

Navigation function implemented in JavaScript

Developers neglected to test on an “average” PC at the time

Performance absolutely unacceptable

Did not work with non-IE, non-recent browsers

Detected just weeks before launch

Represented loss of £20-30k development

Medix website

Medix website rescue

  • Navigation totally redesigned (by author)

    • Simple table and list design

    • Minimum specification HTML

  • Site converted at high speed

  • Site launch only 15 minutes late

  • Major cost in author’s time and temper

    • don’t let web designers do your technology!

Medix dynamic part

  • Unknown, but potentially heavy, concurrent user base

    • Security a major issue

    • Original assumption to use Oracle database

  • Server owner promised, but was unable to install Oracle successfully

    • later went out of business

  • Another disaster!

Medix dynamic part rescue

  • Designed flat-file “database” on emergency basis

    • “Classic” Perl and CGI used

    • Necessary (e.g., text cleanup, file locking) associated routines in Perl

    • Very slow, unpleasant and laborious development

      • But delivered weeks before the static component

      • Has operated successfully now since mid-1999

      • 24X7!

Static part revisited

  • Maintenance very time consuming

  • Labour intensive

  • Expensive and slow

Static part revisited

  • About a year after launch, “W” developed

    • Single user website workstation

    • Access database

    • Produces static website from database

    • Does all formatting globally

    • Management functions

    • Rapid location and navigation of pages

    • Neat checking of internal consistency

    • Simple and secure uploading to server

Static part revisited

  • W limitations

    • Operator exposed to too much HTML

    • Template generation tedious and HTML oriented, does not use style sheets

    • Single user workstation approach limiting

      • multi-site

      • multi-user

    • multi-lingual needed

Static part revisited

  • Piloted a Zope version of W

    • Web form GUI limitations

    • Awkwardness of automatic module generation in Zope

    • Awkwardness of “peep hole” development environment

    • Abandoned after a couple weeks of development

Static part revisited

  • Now would like to develop a multi-user version

    • in Python, wxPython and MySQL

    • Multi-user and multi-site

    • “tokenised” text for multi-lingual sites

    • HTML editor to insulate operators from HTML

Static part revisited

  • Zope instead of W?

    • W developed before Zope introduced but has never seriously been considered

      • DTML too “techie” for operators

      • Management functions not mandatory

      • Performance concerns

    • If W not available, might have used Zope, though

Dynamic parts revisited

  • Still works well, requires no maintenance

  • Slow but steady integration of MySQL DBMS functionality

  • Difficult to modify and test Perl programs, especially in a functioning site

  • New functionality developed in Zope but now only in Python/CGI

Dynamic parts revisited

  • Awkward interfacing Zope & conventional website

    • Zope exposes port-based addresses

    • Possible security risk

    • Some firewalls reject port-based addressing

  • Zope can interface to Apache web server

    • Too difficult to understand

    • Risk to site operation

  • Limitations of Zope development (above)


  • Psychiatric assessment tool for children

  • Involved hundreds of forms, processing programs and reports

  • Complex logical interaction in operation and reporting

  • Internationalisation a requirement

  • Heavy database and security requirements

  • Potentially, large number of concurrent users


  • Started in Zope and MySQL

    • Abortive attempt to use DTML, wasted weeks

    • Lost weeks understanding the otherwise excellent CGI interface

      • Form information passed as lists and single values, depending on the form

      • Handling of null values from forms


  • Framework and key routines developed by author

  • Hand-developed by a specifically trained teenager over a “gap year”

    • costs low

    • did not deviate from the framework

  • System works well and is in routine use

    • moderate loading

Dawba limitations

  • Difficult to comprehend and therefore to maintain

  • Quite a bit is innate complexity

  • “Peep-hole” programming not a particular difficulty

    • forms and processing modules were individually rather small

  • Awkwardness of referring to associated Python modules increasingly painful

Dawba future

  • Now working on a Python-based generator

    • static Python forms

    • static Python processing modules

    • intention to make both dynamic

  • Non-Zope, but continuing to use Zope for the already-developed reports


  • Zope/MySQL is definitely good enough for

  • Dynamic sites

    • Serious, large scale applications

  • Version updating is straightforward and generally “safe”

    • even in a production environment

    • MySQL incompatibility problem


  • Porting to PC workstations and even operational servers is very easy and completely safe

    • Just file copying and restart (both Zope and MySQL)

  • Backup is just as easy


  • Development environment is good enough for most purposes

    • WebDAV for larger programs, in spite of some limitations

    • May be even better solutions, e.g., Boa Constructor

  • Not bad enough to bother spending days locating and evaluating improvements


  • Operationally,

    • Zope meets our performance requirements

    • Is highly reliable

      • main site running constantly for 57 days 4 hours 2 min

    • Restarts have been prophylactic or server reboots


  • This author has looked at

    • dozens of potential alternatives to Zope over the past few years

    • evaluated several seriously

  • None have replaced Zope as a web-based application environment yet

  • Login