Static vs dynamic websites vs application development environments
1 / 71

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

  • Uploaded on

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

PowerPoint Slideshow about 'Static vs Dynamic Websites vs Application Development Environments' - khan

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

Static vs Dynamic Websites vs Application Development Environments

Professor Mike Smith

City University

Medix UK

Prerequisites Environments

  • What is HTML?

  • Understand forms and CGI processing?

  • If not, explanation follows ...

Websites Environments

  • Static websites

  • Dynamic websites

Static websites
Static websites Environments

  • Major components

    • HTML

    • JavaScript

    • Style sheets

    • Files

    • Directories

Pro static websites
Pro: static websites Environments

  • Easy to start

  • Easy to understand - initially

  • Easy to test individual pages

  • Tools insulate developers from raw HTML

Pro static websites1
Pro: static websites Environments

  • 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 websites2
Pro: static websites Environments

  • Aligned with web designers’

    • Skills

    • Experience

    • Orientation/culture

Con static websites

Style sheet only global formatting Environments





“Long page”

Field placement

Format (e.g., colour)

Format rules








Con: static websites

Con static websites1
Con: static websites Environments

  • 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 websites2
Con: static websites Environments

  • Irregularities creep in

    • Style/format

    • Navigation

  • Structure dissolves

  • “Cruft” develops

  • Management information lacking e.g.,

    • last update, author, reviewer, next review date

Con static websites3
Con: static websites Environments

  • 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 websites4
Con: static websites Environments

  • JavaScript often used to “personalise”

    • Functions obscure

    • Difficulty of debugging

    • Reliability of operation (?)

    • Browser incompatibilities

Con static websites5
Con: static websites Environments

  • JavaScript often used to “personalise”

    • Functions obscure

    • Difficulty of debugging

    • Reliability of operation (?)

    • Browser incompatibilities

Con static websites6
Con: static websites Environments

  • 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

Dynamic websites major components typical

Database Environments



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 websites provide or should provide
Pro: dynamic websites Environmentsprovide 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 websites benefit from
Pro: dynamic websites Environmentsbenefit from

  • Modularity

  • Abstraction

  • Data, format and function/logic separation

  • Easier overall understanding of structure

  • Rapid navigation to individual pages for maintenance

Pro dynamic websites tend to lead to
Pro: dynamic websites Environmentstend to lead to

  • Need for application building functionality

    • Form generation

    • Form processing

    • Database integration

    • Application navigation and logic

    • Report generation

Con dynamic website tools
Con: dynamic website tools Environments

  • 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 tools1
Con: dynamic website tools Environments

  • 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 tools2
Con: dynamic website tools Environments

  • 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

Con dynamic website open source tools

Still have forced upgrades Environments

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
Selecting an Application Development Environment Environments

  • 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 environment1
Selecting an Application Development Environment Environments

  • 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 environment2
Selecting an Application Development Environment Environments

  • Wide range of environments available - tend to be:

    • language based

    • database based

Application development environment perl

The “classic” Environments



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

Application development environment oracle

Own programming language, proprietary DBMS (Oracle) Environments

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

Application development environment microsoft asp

Visual Basic Environments

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

Application development environment coldfusion

Template-based Environments

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

Application development environment java

Wide range of offerings, e.g., TomCat Environments

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

Application development environment php

Increasingly popular Environments


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

Application development environment zope

Substantial popularity and open source Environments

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
Why chose Zope? Environments

Pro zope
Pro: Zope Environments

  • 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 zope1
Pro: Zope Environments

  • 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 zope2
Pro: Zope Environments

  • Easy to install

    • PC

    • Linux

  • Easy to learn

  • Built-in editor

  • Good performance, allegedly highly scaleable

Pro zope3
Pro: Zope Environments

  • 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 zope4
Pro: Zope Environments

  • 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
Con: Zope Environments

  • 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 zope1
Con: Zope Environments

  • Issues with forms interfacing

    • Null field handling

    • Multiple field handling

    • “slash” reference to processing modules

Con zope2
Con: Zope Environments

  • 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 zope3
Con: Zope Environments

  • 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 zope4
Con: Zope Environments

  • 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 zope5
Con: Zope Environments

  • 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 zope6
Con: Zope Environments

  • 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 zope7
Con: Zope Environments

  • 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
Experiences in Web Development Environments

  • Small websites from 1995

  • Java in 1996

  • Major developments

    • from 1999

Medix website
Medix website Environments

  • Deliberate minimisation of dynamic component to just

    • user registration

    • login

    • push questionnaire function

  • Design agreed for static component

    • Format/”look”

    • Navigation

Medix website1
Medix website Environments

  • Static left to web design firm

  • Not too costly, initially

  • Author needed to focus on dynamic component

Medix website2

Web design Environments

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
Medix website rescue Environments

  • 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
Medix dynamic part Environments

  • 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
Medix dynamic part rescue Environments

  • 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
Static part revisited Environments

  • Maintenance very time consuming

  • Labour intensive

  • Expensive and slow

Static part revisited1
Static part revisited Environments

  • 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 revisited2
Static part revisited Environments

  • 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 revisited3
Static part revisited Environments

  • 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 revisited4
Static part revisited Environments

  • 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 revisited5
Static part revisited Environments

  • 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
Dynamic parts revisited Environments

  • 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 revisited1
Dynamic parts revisited Environments

  • 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)

Dawba Environments

  • 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

Dawba Environments

  • 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

Dawba Environments

  • 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
Dawba limitations Environments

  • 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
Dawba future Environments

  • 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

Conclusion Environments

  • 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

Conclusion Environments

  • 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

Conclusion Environments

  • 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

Conclusion Environments

  • 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

Conclusion Environments

  • 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