Static vs Dynamic Websites vs Application Development Environments

1. Static vs Dynamic Websites vs Application Development Environments Professor Mike Smith City University Medix UK

2. Prerequisites • What is HTML? • Understand forms and CGI processing? • If not, explanation follows ...

3. Websites • Static websites • Dynamic websites

4. Static websites • Major components • HTML • JavaScript • Style sheets • Files • Directories

5. Pro: static websites • Easy to start • Easy to understand - initially • Easy to test individual pages • Tools insulate developers from raw HTML

6. 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

7. Pro: static websites • Aligned with web designers’ • Skills • Experience • Orientation/culture

8. Style sheet only global formatting Fonts Forms Tabular Paged “Long page” Field placement Format (e.g., colour) Format rules Background Headers Pages Sections Paragraphs Lists Tables Con: static websites

9. 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

10. 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

11. 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

12. Con: static websites • JavaScript often used to “personalise” • Functions obscure • Difficulty of debugging • Reliability of operation (?) • Browser incompatibilities

13. Con: static websites • JavaScript often used to “personalise” • Functions obscure • Difficulty of debugging • Reliability of operation (?) • Browser incompatibilities

14. 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

15. Database Relational Object access methods HTML 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)

16. 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

17. Pro: dynamic websitesbenefit from • Modularity • Abstraction • Data, format and function/logic separation • Easier overall understanding of structure • Rapid navigation to individual pages for maintenance

18. Pro: dynamic websitestend to lead to • Need for application building functionality • Form generation • Form processing • Database integration • Application navigation and logic • Report generation

19. 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

20. 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)

21. 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

22. 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

23. 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

24. 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

25. Selecting an Application Development Environment • Wide range of environments available - tend to be: • language based • database based

26. The “classic” CGI Server-side 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

27. 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

28. 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

29. Template-based 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

30. 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

31. Increasingly popular Server-side 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

32. Substantial popularity and open source Single source, single community, single commercial “outlet” (Zope Corporation) Server-side 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

33. Why chose Zope?

34. 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)

35. 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)

36. Pro: Zope • Easy to install • PC • Linux • Easy to learn • Built-in editor • Good performance, allegedly highly scaleable

37. 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)

38. 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

39. 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

40. Con: Zope • Issues with forms interfacing • Null field handling • Multiple field handling • “slash” reference to processing modules

41. 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

42. 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!

43. 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

44. 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)

45. 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

46. 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

47. Experiences in Web Development • Small websites from 1995 • Java in 1996 • Major developments • from 1999

48. Medix website • Deliberate minimisation of dynamic component to just • user registration • login • push questionnaire function • Design agreed for static component • Format/”look” • Navigation

49. Medix website • Static left to web design firm • Not too costly, initially • Author needed to focus on dynamic component

50. 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