One-Day Web Apps -- Application Generation for .NET.2nd Edition

7/28/2019 One-Day Web Apps -- Application Generation for .NET.2nd Edition

http://slidepdf.com/reader/full/one-day-web-apps-application-generation-for-net2nd-edition 1/206

1

One‐Day Web Apps

Application Generation for .NET

Alan S. Fisher

Some things are just faster.



2

© Copyright 2004‐2005, Iron Speed, Inc.

All rights reserved.

Iron Speed and the Iron Speed logo are registered trademarks of Iron

Speed, Inc.

No part of this book may be reproduced, stored in a retrieval system,

or transmitted by any means, electronic, mechanical, photocopying,

recording, or otherwise, without written permission from the author.

Iron Speed, Inc.

2870 Zanker Road, Suite 210

San Jose, CA 95134

(408) 228‐3400

www.ironspeed.com

First Edition, March 2004

Second Edition, May 2005

ISBN 0‐9752697‐4‐7



3

Acknowledgements

I’d like to acknowledge Paul Gustafson for assembling and editing

this book. His hard work kept us focused on our mission and

ensured a high level of integrity of content.

I’d also like to acknowledge Stephanie Miller for contributing

material that led to this book and for continually encouraging me to

start the process.

Eric Rollins, an authority on code generation and co‐author of Code

Generation in Action , provided many insightful comments and

helpful suggestions.

Samson Wong, our graphic designer extraordinaire created all the

screen shots and many other illustrations in the second edition.

Razi Mohiuddin contributed a number of examples and material on

techniques for extending application generators. Michael Compton

and several other Iron Speed, Inc. team members provided detailed

review of the examples and other input.

Thank you all!



4

Table of Contents

Acknowledgements............................................................................................................................................3 Table of Contents ...............................................................................................................................................4 Foreword ..............................................................................................................................................................9 Part 1) The Case for Automation ...................................................................................................................12

The Challenges of Web Application Development................................................................................... 14 Three‐Tiered Architecture Complexity......................................................................................... 15 User Interface Complexity.............................................................................................................. 16 Database Management Complexity .............................................................................................. 18 Scalability

Complexity..................................................................................................................... 18

Security Complexity ........................................................................................................................ 19 Complex, Yet Boring, Development.............................................................................................. 19

Standards Make Application Generation Possible .................................................................................. 20 User Interface Standardization....................................................................................................... 20 Database Standardization ............................................................................................................... 20 Application Integration Standardization...................................................................................... 21

Part 2) Automating Development: A Historical Perspective ...................................................................22 The Evolution of Automated Software Development .............................................................................. 23

The 1980’s:

IDEs .............................................................................................................................. 23 The 1990’s: Application Servers .................................................................................................... 24

Modern Requirements..................................................................................................................... 25 Today: Application Generators..................................................................................................... 26 UML & MDA—Poor Alternatives for Most Developers ............................................................ 27

The Emergence of Iterative Development ................................................................................................ 29 Part 3) Development Automation in Action: Common Problems Solved ............................................31

Automate “C/R/U/D” Page Creation...................................................................................................... 32 Complex Displays.................................................................................................................................... 35 Using Data Grids to Manage Large Result Sets ..................................................................................... 37

Automatic Data Validation & Display.................................................................................................... 39 Delivering a Common Request: Exporting Application Data................................................................. 40 Summary ................................................................................................................................................. 41



5

Part 4) Goals & Benefits of Automated Development...............................................................................42 What Should an Application Generator Do? .......................................................................................... 43

Starting from Scratch: The Application‐Specific Data Model .................................................... 44 The Very First Step: A Functional, Bug‐Free, Application......................................................... 44 Code

Completeness

&

Organization ............................................................................................. 45

Extending the Code Generator Itself (Automated Code Reuse)................................................ 45 Characteristics of Good Generated Code...................................................................................... 47

Implications for Development Methodology............................................................................................ 48 Gather Feedback Early & Often in the Cycle with Real Software ............................................. 49 Use Business Analysts to Develop Prototypes............................................................................. 50 Simplify Software Maintenance ..................................................................................................... 51 Custom‐ build the Unique Aspects of your Application............................................................. 51

Key Benefits of Application Generation Methodology............................................................................. 52 Speed Development and Reduce Testing Time ........................................................................... 52 Enable Corporate Computing Standards...................................................................................... 53 Automated, Yet Robust UI Brings Application Power to Light ................................................ 54 Scalability .......................................................................................................................................... 55 Boost Your Company’s ROI............................................................................................................ 55 Keep Development In‐house .......................................................................................................... 56

Part 5) How Automated Development Works............................................................................................59 Approaches to Application Generation.................................................................................................... 60

The MDA/UML Philosophy ........................................................................................................... 60 The Algorithmic Approach............................................................................................................. 60 The Declarative Method Philosophy............................................................................................. 60 Specifying

an

Application

ʹs Basic

Functionality

with

Code

Generation

Tags......................... 61 What Declarative Method Application Generators Create ........................................................ 62

Connecting Web Pages and Data‐ bound Controls to the Database.......................................... 65 Customizing Generated Applications........................................................................................... 66

Using Declarative Methods to “Specify” an Application........................................................................ 67 Layout Pages..................................................................................................................................... 67 How Code Generation Tags Work ................................................................................................ 68

Linking Database Tables, Views and Queries to an Application............................................................. 75 The Component Binding Process................................................................................................... 77 Sourcing From Parent’s Record or Current Row in a Table....................................................... 79 Adding a New Record to a Database Table.................................................................................. 81

The Application Generation Process ....................................................................................................... 82 Presentation Layer Generation....................................................................................................... 83 Application Layer Generation........................................................................................................ 84 Database Layer Generation............................................................................................................. 85

Bonus Automation (Even More Code You Don’t Have To Write) ......................................................... 85 Search Tools ...................................................................................................................................... 86 Data Sorting & Page Navigation.................................................................................................... 87



6

Import & Export Facilities............................................................................................................... 87 Exception and Error Management................................................................................................. 88

Summary ................................................................................................................................................. 89 Part 6) Automatic SQL Generation for Database‐Connected Controls ..................................................90

Meeting & Exceeding User Expectations................................................................................................ 91 SQL Efficiency......................................................................................................................................... 91 Transaction Model & Transaction Management .................................................................................... 92 Location of the SQL Statements .............................................................................................................. 94

In‐line (Embedded) SQL ................................................................................................................. 94 Stored Procedures Enhance Performance & Maintainability..................................................... 94 Generating Stored Procedures ....................................................................................................... 95

Database Views Provide Data Consolidation .......................................................................................... 96 Primary

Key

Relationships

Permit

Record

Editing................................................................................. 97

Foreign Key Relationships Permit Multi‐Table Joins.............................................................................. 98 Concurrency Control / Concurrency Handling .................................................................................... 100

Pessimistic Concurrency ............................................................................................................... 102 Optimistic Concurrency ................................................................................................................ 102 Concurrency Handling in Generated Applications .................................................................. 103

Cursor Management.............................................................................................................................. 103 Data Recency .................................................................................................................................. 104 Data Management.......................................................................................................................... 104 Database Cursors in Generated Applications............................................................................ 104

Summary ............................................................................................................................................... 105 Part 7) Automating Application Security...................................................................................................107

Generating Role‐Based Application Security ........................................................................................ 108 Simple Sign‐in Authentication ..................................................................................................... 109 Single Role Authentication ........................................................................................................... 110 Multiple Role Authentication....................................................................................................... 110

Securing Your Generated Web Application .......................................................................................... 111 Creating User Accounts ................................................................................................................ 112 Creating

User

Roles ....................................................................................................................... 113

Configuring Your Web Pages for Role‐Based Security............................................................. 114 Configuring Sign‐In Pages for Your Application ...................................................................... 114 Signing Into Your Application & Managing Lost Passwords.................................................. 115

Additional Security Issues to Address................................................................................................... 116 Automatic Sign‐out........................................................................................................................ 116 Data Transmission Encryption..................................................................................................... 116 Implied Security from an N‐Tier Architecture........................................................................... 116



7

Active Directory and LDAP ......................................................................................................... 117 Password Storage........................................................................................................................... 117 Handling SQL Injection Attacks .................................................................................................. 118

Part 8) Extending and Customizing Applications ....................................................................................120 Standards for Generated Code ............................................................................................................... 122

Well‐organized Code..................................................................................................................... 122 Code Should Meet Professional Standards ................................................................................ 123 Avoids Code Orphaning............................................................................................................... 124

An Approach to Generating Extendable Code....................................................................................... 125 Example: Changing the Presentation Layer ......................................................................................... 126 Example: Adding Custom Data Validation Code.................................................................................. 128 Every User’s Request, “Can you add a button that…?”....................................................................... 131

Common Button Actions and Properties.................................................................................... 131 Passing Primary and Foreign Key Values in URL’s.................................................................. 133 Example: Adding Reporting to a Generated Application....................................................... 137

Localizing (Internationalizing) Your Application................................................................................. 143 Summary ............................................................................................................................................... 145

Part 9) Automating IT Strategies .................................................................................................................146 Automating Page Production................................................................................................................ 147

What’s in a Page Template?.......................................................................................................... 151 Automatic Re‐use of ASP.NET Directives in Page Template Files ......................................... 156

A Pragmatic,

Yet

Revolutionary,

Approach

to

Code

Re

‐Use................................................................ 158

Automating Code Re‐Use with Panels & Components............................................................ 159 Button Panels.................................................................................................................................. 161 Generating Navigation Menu Panels .......................................................................................... 164 Generating Dynamic Context‐Sensitive Panels ......................................................................... 169

Automating Re‐Use of Custom & Third Party Controls ...................................................................... 174 Example: Integrating a Third Party Control.............................................................................. 175 Example: Integrating a Third Party Control with the Database ............................................. 176

Summary ............................................................................................................................................... 180 Part

10)

Looking

Ahead .................................................................................................................................181

Selecting Your First Project .................................................................................................................. 182 First Effort Case Study: Otis Elevator ................................................................................................. 184 First Effort Case Study: Les Schwab Tire Company ............................................................................ 187 First Effort Case Study: Open Latitude................................................................................................ 189 First Effort Case Study: Texas Youth Commission.............................................................................. 191



8

Organizational Rollout of Application Generation Technology............................................................ 192 Basic Rollout Essentials ................................................................................................................. 192 Advanced Platform Possibilities.................................................................................................. 193 Enabling a New Kind of Development Team ............................................................................ 194

The New Reality: Competitive Advantage Requires Ubiquitous Custom Software............................. 195 The Rise of “Nano” Applications................................................................................................. 195 The Application Generation Future ............................................................................................ 197

Contact Iron Speed .........................................................................................................................................198 About the Author............................................................................................................................................199



9

Foreword

The Iron Speed® founders and many of our key executives

conceived,

built,

grew

and

made

profitable

one

of

the

largest

and

most successful online stores at Onsale, Inc. (which later acquired

Egghead.com, and is now part of Amazon), growing the company to

a run rate of over $600M in annual sales. The lessons learned there

during six years of torrid growth inspired the creation of Iron Speed.

My partners and I started Onsale back in1993 as an online auction

house for all sorts of excess and out‐of‐stock merchandise. There

were no e‐commerce operations to emulate, so we took a trip to

Minneapolis – the mail order capital of the US – for a plant tour of

Damark, Inc., which specialized in consumer electronics and house

wares (what we called “big toys for big boys”) and had about $500

million in sales.

We got back on the plane to come home thinking that to be

successful in mail order you needed a lean executive staff, a huge

room of people with headphones taking orders, and a warehouse

full of other people loading boxes. It struck us that e‐commerce was

exactly this operation minus the headphones. And, we were hoping

that since we were not manufacturing anything, that we would be

able to have a very small warehouse and never take possession of

most of the items that we shipped.

That

meant

the

software

had

to

replace

the

role

of

the

order

taker,

and customer service, a.k.a.: the headphones. And, the software had

to integrate with our suppliers. We thought it would take no more

than five or ten engineers to build and manage the whole thing. We

thought, “How complex can this software be?” After all, e‐

commerce is basically a database application – a set of pages, input

forms, and SQL queries.

By the end of 1999, we had an IT staff of about 110 people and 65

modules of software that addressed everything from order taking to

bid tracking to email notification to supplier inventory management

to trouble tickets.

We had become, in essence, a giant web‐ based ERP system, perhaps

the first of its kind. Everything was heavily automated – sales to

fulfillment to vendors. It worked like a charm and was a thing of

beauty, handling over 12,000 orders, 500,000 customer transactions,

and sending 750,000 email updates each day of the week.

“We had become, in

essence, a giant ERPsystem. Everything wasautomated.”



10

But, how did we get so big in the engineering department? Those 65

modules came about from our desire to automate. You’d think that

would mean we’d have very few people and lots of computers doing

all the work. Well, every business process that could be made more

efficient and thus every effort to improve margins became a new IT

project. Once the modules were built, of course, they had to be

maintained. And they had to work with each other, which required

more engineering. And, every single aspect from development to

integration to maintenance required a different set of skills and a

dedicated team.

An example: Our original customer service “system” – comprised of

phone and fax and a lot of email! — needed an overhaul about two

years into our hyper‐growth phase. I remember a particularly

painful holiday season where the number of customer service

requests rose with the burst in sales volume. We were swamped

with orders, experiencing shipping delays, vendors were failing us,

and everything seemed to happen at once. So of course there were

lots of complaints via phone, fax and email. Because our customer

service system was dependent on manual processes to link the

paper, voice and electronic complaints, we had a near meltdown.

Some complaints were processed twice, and all complaints were

handled slowly.

We needed a customer self‐service system for routine requests, as

well as one point of access for the history of all customers to

eliminate redundant requests and increase productivity. We also

wanted an email alert system to keep customers apprised of the

status of

winning

bids

and

their

orders

so

they

didn’t

have

to

call

us

for an update.

We built it over several months and rolled it all out with huge

success. That same year we enjoyed a four‐fold increase in business,

but we kept the same number of service reps (about 14) – solely due

to automation.

Then the fun development work started. The more we used the

system, the more we wanted to improve it and customize it for the

particular needs of our business. So then we needed a team of

engineers who were specialists in these applications to grow it and

support it and link it with other internal and partner systems.

You can see how we got to 110 people pretty quickly. Although,

even in my most honest of moments, I believe we were as efficient as

possible and everyone worked very hard. There was no fat there.

Could it be, we thought, that it just takes a hundred people and

almost five‐dozen software modules to run an e‐ business? Yikes!



11

Well, the answer is that it does – if you build each module as an

island. This is what traditional engineering wisdom dictated. But

with that wisdom in mind, we are shattering the legend at Iron

Speed. We believe that with an underlying platform architecture

that supports all those applications, we can save time to market,

money and development costs.

What do we know now that we didn’t know then? The key is that

most of the modules and their operation at Onsale was not

complicated logic or calculation – it was taking data, processing it,

and displaying it in a different form to someone or several people. I

have to confess that out of almost a million lines of code that made

up those 65 modules, the “secret sauce” was only a small fraction –

maybe 20,000 lines of code on which we held several ground‐

breaking patents for online auction technology. The rest was simply

moving data in and out of forms and databases, and translating it so

it could integrate with other Customer Relationship Management

(CRM) and Supply Chain Management (SCM) Systems.

Those lessons mandate some of the fundamental tenets we use at

Iron Speed to benefit rapidly growing companies like yours:

Data‐intensive applications are not complicated to build, but

they are unique for every business.

All functionality must be flexible and extensible to grow

with the business.

Here at Iron Speed, we’re building tools and technologies to help

companies build and deploy data‐ bound applications much more

quickly and easily than ever before. Our experience at Onsale led us

to believe that there had to be better way, and thankfully, there is!



12

Part 1)

The Case for Automation

Market and technology trends point to

automation as the answer to many modern

web development challenges.



13

Like so many IT professionals, we’ve spent thousands of engineering

man‐hours figuring out how to build powerful new web‐ based

applications as well as migrating existing client‐server applications

to the web. We’ve all learned to build web applications, and we all

know these projects are harder and more complex than building

client‐server applications ever were.

On the web, the user interface includes options for states you can’t

control. And, the stateless client is far removed from the database,

so each transaction is a distinct request. Additionally, web

applications must always also include provisions for database

connection pooling, session management, scalability and

authentication.

The benefits we’ve all heard relentlessly touted

about web applications – those of simpler

deployment, improved inter‐operability and easier

integration — are so far removed from the early

planning and development tasks that they hardly

seem to matter. Really, who is thinking about the

benefits of web services, SOAP (Simple Object

Access Protocol) and XML (extensible markup

language) when he’s struggling to correct the code

surrounding the 50th SQL query in a multi‐tier

application?

There is a better way.

A new category of software that we call

application generation software generates the

majority of an application’s code faster and more efficiently than

traditional hand‐coding approaches. But, taking advantage of this

opportunity means shedding the traditional client‐server

development approach in favor of a web‐ based application

development strategy.

This book discusses the challenges as well as possibilities of building

web applications; explores the emerging category of application

generators; and introduces the breakthrough methodology for

accelerating application development invented by Iron Speed. Later

chapters explain the process details and underpinnings of the

approach, and how modifications and extensions are managed.

Enterprise applications for CRM, productcatalogs, supply chain and partner

management, and employee-HR portals, arebeing launched on the Web for easier access,improved service, stronger version control andincreased inter-operability.



14

TraditionalClient-Server Architecture

ModernWeb Application Architecture

Client Application(“Fat” Client)

Server Server

Database

Browser (“Thin” Client)

Database

ApplicationServer

App1 App2

Runs applicationsoftware, handlestransactions, and

provides scalability andaccess control.

The Challenges of Web Application Development

Every corporate IT developer is familiar with client‐server

application development. The two‐tiered architecture typically

includes a thick client and a thick server that run in a controlled

environment.

The client

‐server

architecture

formed

the

backbone

of

enterprise software for decades.

Developing with

client‐server

architecture gives

you lots of freedom

to place heavy

burdens on the client

side. There is no

need to ping the

database for every

transaction, as you

can house

functionality and

data in the client

itself, greatly

reducing the need to

scale the server‐side

software and

database.

But today, everything is migrating to the web. As a result, IT now

faces the challenges of building new applications for the web, and

migrating legacy systems to the web. At first blush, web‐ based

applications sound great because they save on deployment and

training. But, between the start of the project and deployment of a

production system, a whole lot of development work adds several

layers of complexity to the application development cycle.

Web application development puts the developer in a completely

different development scenario:

Web applications are fundamentally different. They are

three tiered, with a thin browser client, a robust application

server and a database.

HTML is a thin client so most of the web application heavy

lifting has to happen at the application server level,

including the application workflow.

HTML‐ based user interfaces lack the robustness of desktop

windowing environments, like Microsoft Windows and the



15

Apple Macintosh, making user interface development more

difficult.

Web applications are stateless, so they require complex

session management in order to implement complex

transactions. The HTML client is really designed for display

(and not transactions), so the application server layer must

pick up the bulk of the coordination and management of

database‐driven transactions.

Due to their reliance on standard protocols, web applications

are frequently exposed to the public Internet, and so must

accommodate tight security and access control.

Although web applications are intended to operate as stand‐alone

systems, they frequently rely on the operation and connection with

other web applications and web services. Ultimately, some of those

inter‐connections

may

be

between

enterprises,

and

lose

the

protection of the network firewall.

That is a very long list of challenges, even when building with a

favorite programming language like C#, C++, Java, or Visual Basic.

Comparing client‐server applications to web applications and web

services is like saying a Morris Mini and a BMW are both cars. Both

get you where you need to go, but lift up the hood and one is clearly

more complicated than the other. Web applications are more

complex to develop than client‐server applications because they

include more infrastructure, more features, more connections, and a

more complex run‐time environment.

Application generation technology speaks directly to this point:

building web applications from the bare metal is complex and time‐

consuming. Accelerating the development cycle without sacrificing

performance, features and interoperability are the key metrics by

which application generation software is being measured.

Three‐Tiered Architecture Complexity

Specifically, the three‐tiered architecture creates new challenges for

developers in several areas: creating the web‐ based user interface,

providing application infrastructure, database management, scalability and security.

Traditional client server applications didn’t have to worry about

those things nearly to the same level as web applications.

The Browser Client Tier: HTML is really designed to display

content and is not robust enough to handle complex enterprise



16

Users expect a certain threshold of

functionality and user interface look and feel. Appreciated features like navigation,search, pagination and table sorting caneach take weeks to develop.

transaction management. Java scripting, rich media and active

server/java server pages bring the language forward toward simple

interactivity, but clearly HTML is a long way from the robust,

controlled, desktop‐windowing environment of client‐server

applications. This forces all the coding and interactions that happen

at the client level in traditional applications further down your

application architecture.

The Application Server: Much of the functionality found in the

client layer of a client‐server application is now pushed to the

application server level for web applications – an expanded role for

the traditional server tier that now sits between the thin HTML client

(not doing much more than displaying the

user interface) and the database. The new

application server tier literally powers each

web application and web service.

Back in the old days, this complete

infrastructure could be built independently

and from scratch for each application. Of

course we didn’t know to call it an “app

server,” but we would build a foundation

layer that supported other functionality.

While an application server provides some

of the things you need, it isn’t central to

your development, and so it can’t take you

quite far enough for your web‐ based

application needs.

The Database Tier: Web‐ based

applications separate the database

completely from the server layer in order to allow continuous and

non‐synchronized requests to be transferred through the new

Application Server middle tier.

In a ʺstatelessʺ environment like HTTP, each separate transaction

must log in and out of the database. As many web applications are

outward facing toward customers, employees, partners or suppliers,

a “transaction” now includes everything from confirmation page

views to orders, requests and bids. Thus, the load on the database

gets pretty big pretty quickly. The emergence of what we today call “application servers” was a direct effort to mitigate this need for

database connection pooling.

User Interface Complexity

Hand‐in‐hand with the complexity of stateless transaction

processing is the user interface development.



17

HTML is a comparatively low functionality user interface relative to

a Windows or Macintosh environment. That “glossy magazine” feel

of an HTML user interface is misleading. While HTML is great for

presenting static pages, the rich interaction that we desire in

enterprise applications is missing. Additionally, and perhaps as a

result of that glossy look and feel, there is added pressure on

transaction‐ based applications to be more user‐friendly and

forgiving.

Consider the difference between the web and a Microsoft Windows

application like Excel or Outlook.

In Windows applications, multi‐step processes can be performed

within a single application screen. For instance, you can drag‐and‐

drop an email from one folder to another. This functionality is not

possible in HTML, nor can complexity be structured as conveniently

as in a controlled client‐server application. In Windows, complex

functionality like “find” and “spell check” is handled with a pop‐up

window that keeps the original screen in view. That sort of

functionality has to be handled on the web via a series of static pages

that only mimic what is a fluid and simple user experience on the

desktop. Although the web excels at lower volume, lower

complexity transactions, those are not always the types of

transactions required by high‐use enterprise‐class applications.

HTML falls short when you try to offer the selection choice of

anything more complicated than a drop down menu. Seemingly

simple features that are commonplace on most web applications can

take

weeks

to

develop

–

search,

table

sorting,

pagination

and

hierarchical navigation. Those features are more than “nice to have,”

they are expected.

Your users don’t see the complexity of your application code; they

only want a premier experience. They want to change their own

account information; change their mind half‐way through a

transaction and save only the relevant fields; ensure one customer is

forbidden from seeing another customer’s data — and they want all

the pages to load in under three seconds.

Making matters even more challenging, today’s application users are

familiar with the web and with sophisticated, highly intelligent forms and navigation features, and want similar features in their

business applications. Most developers dread the inclusion of these

features, such as paginated reports, hierarchical navigation, filtering,

and full text search, because the amount of time they take up is not

proportional to the challenge or interest they create. Still, because of

their pervasiveness on the web, these features are now part of a new



18

A web browser client can’t tellwhen a user is logged out oncethe transaction has begun. Inessence, every transaction –even in a multi-transaction

process – is potentially a uniquesession.

baseline of functionality most end users expect in any web‐ based

application.

Database Management Complexity

In a web application, database management concerns manifest in

two key areas: user session management and database connection

pooling. Since the very nature of a web application is stateless, there

is a great need to manage transaction integrity

and completion. Web applications require an

environment that supports the creation and

management of processes built from these

stateless transactions.

In traditional client‐server applications, a

“session” was straightforward: the user logged

in, stayed in, and then logged out when they

closed the application. The entire “session”

logged in once to the database. In the stateless environment of

HTTP, there is no such thing as a controlled “session.” A web

browser client can’t tell when a user is logged out once the

transaction has begun. In essence, every transaction – even in a

multi‐transaction process – is potentially a unique session.

A new way of managing the database connections is obviously

required to support this stateless session environment. Web

application servers handle this by maintaining a pool of database

connections – keeping open a number of connections and re‐using

them for

each

transaction

request.

This

way

requests

from

multiple

users as well as multiple requests from individual users – regardless

of the order they are received – can be handled without repeatedly

logging in and logging out of the database.

Functions to address these issues are best centralized and managed

as a separate collection of functions on their own machines. An

application server middle tier is a second‐generation approach,

recognizing that much more support is needed than with client

server applications.

Scalability Complexity

Since web applications are intended to scale to enterprise or even

inter‐enterprise levels, scalability must be ensured.

In client‐server applications, application scalability is managed

primarily through the client. Each end‐user ran the client‐side

application on a desktop machine, so no extra computing

horsepower was needed. And since so much of the application



19

functionality was fully contained in the client side, there wasn’t as

much concern about scaling applications.

In web applications, the entire application functionality is

concentrated in the new middle layer, running on the application

server. This application server gives you the scalability you need to

have one database support multiple applications and multiple

servers. Now, the application code has to scale as well as support

multiple users. Fiscally, web applications are more expensive, since

application server machines and software are now required to run

them. None of the application functionality runs on the desktop

machine any longer.

There is a benefit, however. The strategy of managing scalability at

the application server level lets you enable multiple server machines

to run your applications and process transactions against a single,

centralized database (the database tier). It’s much more difficult to

create a multi‐machine distributed database architecture in a client‐server development, so creating scalability at the application server

tier erases that concern.

Security Complexity

Running on the public Internet means that by nature your

applications – and the underlying databases that drive them — are

exposed to increased levels of risk. This requires increased attention

and support for security. Even intranet‐only applications run on

standard IP protocols, which are easier to hack. Security is a top of

mind concern

at

every

step

of

web

‐ based

application

development

and deployment.

Multiple layers of protection are needed from both the application

itself in the form of authentication and user access control, as well as

from your network firewall and other security measures.

Complex, Yet Boring, Development

In many software development scenarios, engaging with complexity

can be, on an intellectual plane, exhilarating. In such scenarios, it

can be extraordinarily satisfying to get something to work. Such

satisfaction is particularly sweet when the solution is particularly

elegant, timely, or valuable.

In building web applications, however, there’s not much glory in

making sure your C/R/U/D (Create/Review/Update/Delete record)

pages are complete, your database scales, getting your user roles

right, and making sure your UI works and is intuitive. Beyond the

initial phase of deciding what’s needed, the work of building the



20

application devolves into connecting individual pages to the

database and becomes repetitive, mind‐numbing, work.

Such work seems regressive, in that Visual Studio .NET does all the

work of connecting events and properties to the controls in client

server applications.

Standards Make Application Generation Possible

How can IT departments build these increasingly complex web‐

based applications with the increasingly pressured and limited

resources of today?

The answer is application generation.

And what makes application generation possible now when so many

attempts in the past have not succeeded?

The answer is standards.

While applications used to have to accommodate so many different

platforms, today, standardization is appearing in many areas. This

makes it easier to generate substantial portions of an application.

User Interface Standardization

During the last ten years, the end‐user interface environment has

become standardized with HTML web browsers becoming the client

interface of choice. For desktop applications, Microsoft Windows

remains the de facto choice for corporate environments.

Standardizing the user interface environment makes it easier to

generate user interface code that runs on almost any machine at any

location, especially if it’s HTML.

Moreover, most users see the web browser – with its ability to

combine rich text and graphics with traditional data display and

form based input — as a friendlier, more intuitive user interface than

traditional desktop windowing metaphors. In fact, most of the major

ERP and CRM vendors have rewritten, or are in the process of

rewriting, their applications for the web. It won’t be long before

most other applications follow suit.

Database Standardization

Most enterprise applications standardized over the last 20 years to

operate on SQL‐ based relational databases. More recently, database

middleware like ODBC and JDBC make it easier to retarget

applications to different databases (e.g., Oracle and DB2) without



21

significantly rewriting the query and access code. This type of

standardization makes it possible for an application generator to

target one type of relational database and generate queries in a single

language (SQL).

Application

Integration

Standardization

More recently, SOAP and XML are becoming established as

application integration standards, and make it possible to develop

applications that can adapt to new business rules and connect across

systems. While most application integration is deployed behind a

company’s firewall, web services technology offers the promise of

cross‐enterprise integration, tying together systems running on

entirely different platforms.

Ours is now a vastly different application development world

compared to traditional client‐server environments. This gradual

standardization of user interface environments, application

integration protocols and database languages has brought us to the

point where application generation technology can be built and

deployed to accelerate web application development.



22

Part 2)

Automating Development:

A Historical Perspective

Steps that led to current state of the art

development tools and the resulting

implications

for

modern

software

development methodologies.



23

The Evolution of Automated Software Development

The goal of software development tools has always been to help

programmers do more with less, and develop robust applications

more quickly.

Early

attempts

at

accelerating

application

development got us only part of the way there. Remember RPG II

(the old data processing model), CASE (Computer‐Aided Software

Engineering), and the early compiler‐compliers? Some of these still

exist as data modeling tools or have been integrated into IDEs. Some

evolved into code generators that focus on one code subset or

another. Still others evolved to offer libraries of pre‐ built

components. Even some of todayʹs web page design tools simplify

application development by enabling database calls within HTML

pages.

In the 1980’s, Integrated Development Environments promised it. In

the ‘90’s, HTML and XML promised it. Today, in the ‘00’s, SOAP

and web services promise it.

Each of those promises got developers part of the way to the goal.

Each took one segment of the development cycle, and identified the

elements that were common, could be standardized, and were not

custom or career‐ building exercises. As web services standards offer

new layers of standards and applicability across many enterprise

and departmental arenas, today’s application generators can deliver

on the promise first proposed three decades ago: that software

applications can be generated rapidly and with high quality.

The 1980’s: IDEs

Of course, software development tools have been around for as long

as there has been software. After flashing lights and manual

switches, some of the earliest tools were machines that stored code

on punch cards or paper tape, and saved programmers from

performing the task manually.

On the software front, operating systems evolved to save

programmers from having to write basic operations over and over

again. A few years later, programming languages and related

compilers and linkers appeared. These tools freed programmers

from laboring with assembly code.

In the 1980’s, the most significant wave of “software that writes

software” was the Integrated Development Environment, or IDE.

Looking back, the code these early tools actually provided wasn’t

that significant, but it did give you a standard looking application

framework.



24

Within an IDE, each application was “familiar” due to the shared

components, and each application shared a common look and feel.

This development was found to be tremendously valuable, and

made development skills from enterprise to enterprise much more

portable. Learning to develop with one of these IDEs became a

transferable skill set, and many application developers gained

experience with these tools.

About this same time, a variety database engines appeared from a

number of vendors. These engines helped developers capture and

store information more efficiently, and introduced optimized search,

relational capabilities, and fast record‐lookup features. Using a

database engine, a programmer could leverage code he didn’t have

to write, and create data‐intensive applications that were faster and

more sophisticated.

Eventually, all of these database engines largely standardized on

SQL (Structured Query Language), and again, skills programming

queries on one database engine became transferable across the

industry.

The 1990’s: Application Servers

Application servers became available in the late 1990s for much the

same reason that IDEs and database engines had become popular

and valuable: the application servers included a base level of

functionality that was common for all applications and didn’t need

to be re‐ built every time. Plus, the fact that this functionality was

handled in

the

same

way

for

each

particular

application

server

makes application development more predictable. Again,

developers gained experience with one of the vendor’s products and

that experience became transferable around the enterprise and the

marketplace.

In recent years, a “second generation” of application server has

appeared. These new application servers include components for

database connection pooling and session management. Although

this is a valuable contribution to reducing the development cycles

and makes those components more standardized across the market,

these features still have to be customized and integrated into each

specific application. Additionally, the components included in most application servers don’t go nearly far enough for the stateless

environment of today’s web applications. No application server

thinks at all about non‐controlled or non‐sequential states within a

complex end‐user transaction. And, no application server

accommodates the need for user interface functionality in the middle

server software layer – required because HTML is a thin client.



25

On the data side, a variety of tools and vendors has appeared to help

programmers create and optimize database tables and SQL queries.

DBAs and programmers have grown to rely upon these tools to

simplify and maintain production databases that have grown larger

and faster than were ever imagined during the days of punch cards

and paper tape.

Modern Requirements

Building on this august history, today’s class of application

generation offers a broader more comprehensive solution. Simply

put, an application generator is a development tool on steroids. As a

result, the best of todayʹs application generators generate a

significant portion of your entire application for you.

A powerful application generator should:

1. Help build the application‐specific data model.

2. Generate everything needed for a functional n‐tier

application, link everything together, and deliver a bug‐free,

functional prototype of the desired application.

3. Automatically generate “pure” commented source code:

native to the target platform, optimized for the production

environment, with no requirements for proprietary run‐time

servers or libraries.

4. Generate familiar languages, such as Visual Basic, C# or

Java, and support straightforward integration and

customization.

5. Provide complete and well organized, commented source

code thatʹs easy to modify and extend.

6. Automatically preserve and reintegrate customizations or

extensions during subsequent application regenerations.

Accelerating the development cycle, without sacrificing

performance, features and interoperability, are key metrics by which

application generation

is

being

measured.

An application generation tool should generate the following:

Enterprise‐class 3‐tier architecture

User interface web pages including sophisticated data grids

with advanced features like multi‐table joins, reports, and

filters.



26

User interface code and database bindings

SQL statements and stored procedures

Transaction management code

Workflow reporting

End user account management and access control

Multiple layers of application security

Scalable applications

Easily extensible class hierarchies

One caution: Application generators differ. Some generate a single

tier, like database access code. Most offer some level of user

interface generation, but the sophistication of the generated code

can, and does, vary widely. A few generate code that is orphaned

and not extensible. Some even require run‐time servers and complex

licensing schemes.

Today: Application Generators

Now that enterprise applications are migrating to the web, the user

interface, creation of the application infrastructure and database

management functionality becomes a prime candidate for

automation because these components can be easily standardized.

One of the reasons application generation is so important and timely

now is because of the ubiquity of HTML, XML, and SOAP. As a

concept, application generation works best when you can generate

software that runs anywhere in any environment. Application

generators build in many features that you might not have the time

to do by hand because you have an application backlog to work

down and deadlines to meet.

Several products claiming to be application generation technologies

or application assembly tools are on the market and each offers

different features and functionality. The tools vary in depth and

breadth of application code generated, and so does the amount of

time and complexity it takes to reach a point where the generated

software leaves off and the rest of the application must be developed

by hand.

A thorough review of the application generation options should

consider these three general categories of application generation that

focus on the routine or common elements found in most web‐ based



27

applications and web services. Specifically these are web‐ based user

interface and user interface code, workflow and SQL queries, and the

database schema and database access code.

User Interface Functionality and Features: Web‐ based user

interface pages, user interface code, search, navigation, pagination,

filtering, sorting and reports.

Complex Application Infrastructure: Workflow, business rules,

SQL queries, session management, access control and authentication.

Database Management: Database access code, database schema,

database connection pooling and data migration.

By generating some or all of these elements, you quickly add a level

of robustness to the application that makes it more complete and

powerful, and yet still lets you focus on the more interesting and

important work

that

is

specific

to

your

business

needs.

While hand‐ built code would surely get the job done, it’s not the

most interesting or signature components of an application, nor is it

the most efficient use of developer resources.

Application generators can provide deep functionality “for free”:

Generate the routine program code and provide a

predictable base for all your web‐ based applications;

Generate code of consistently high quality and performance

and so you have a jump‐start on your development and can

predict how the foundation of each application will behave;

Allow developers to focus on developing the unique aspects

of their applications, which typically involves proprietary

and career‐ building development work.

UML & MDA—Poor Alternatives for Most Developers

No historical perspective on application generation would be

complete without touching on UML (Universal Modeling Language)

and

MDA

(Model

Driven

Architecture).

Universal

Modeling

Languages generally describe higher level, typically more English‐

like, programming languages that architects use to design the overall

information architecture. Once complete, this “pseudo‐code” needs

to be translated into production‐caliber application software source

code.

Similarly, Model Driven Architecture generally describes a visual

tool that describes the overall application architecture. These tools



28

typically involve visual representations of boxes of various shapes

connected by lines. Again, once built, these visual representations

must be translated into production‐caliber application software

source code.

While sometimes touted as recent breakthrough technologies that

represent the future of software development, both UML and MDA

represent an approach to programming that’s been around for a long

time. Most introductory courses in computer science at least

introduce the topics of information architecture and systems design

as the initial steps in the structure of any computer science project.

UML and MDA describe a class of tools and technologies that cater

to this academic approach to programming.

In most commercial settings, this academic approach isn’t used. In

fact, such exercises are viewed with disdain by many experienced

and talented programmers. These programmers tend to take pride

in being able to create functional systems without wasting much

time on the design phase.

In fairness, UML and MDA can work well in programming shops

that have religious conviction about application planning and

development. Such environments are typically found in scenarios

where the applications being developed are huge, and involve lots

developers writing hundreds of thousands, or millions, of lines of

code. In such scenarios, UML and MDA approaches can provide

mechanism that help coordinate the team, organize the work to be

done, and manage the massive amount of information such projects

inherently

involve.

Even on an individual level, these tools can be productive if you are

a highly structured, organized thinker who architects and designs

first, and then writes code based on your design.

While useful in some environments as noted above, UML and MDA

represent approaches are overkill for most small scale custom

software development projects within the enterprise. These projects,

by and large, are transaction‐intensive, and mostly involve users

putting information into, and getting information out of, corporate

databases. Further, most projects face tight deadlines, and

constantly changing requirements.

The highly structured approach to programming implied by MDA

and UML tools do not lend themselves well to these common

production environments. In fact, such an approach can even

impede progress in common environments that deal with constantly

changing end‐user requirements. As such, most programmers in



29

these environments avoid MDA and UML tools, and employ a light‐

weight iterative style of development.

In these typical commercial environments, RAD (Rapid Application

Development) tools and application generators are increasingly

employed because they support the pragmatic, iterative

development approach used in these environments.

The Emergence of Iterative Development

Still, web applications do introduce more complexity than ever

before. As a result, it is imperative that the design be flawless when

the developer sits down to begin coding. Spending three weeks

adding functionality to your application only to find out that the

user community wanted something outside the specification is not

productive or enjoyable (for anyone). Yet, it is very difficult to

predict user preferences before users begin to use an application,

even if you have a very detailed requirements specification

document. Inevitably, the directive to be able to search in a product

catalog application against the description, price, manufacturer and

notes, not just the product name, comes after the three‐week

investment to build the search feature based on the original

specifications, which did not include that functionality.

In the days of client server applications, some of this frustration was

accepted, as users had little expectation that any application would

be familiar to them the first time they opened it. Application

training was an expected and required condition of use. This was

acceptable since

applications

were

built

for

relatively

small

and

controlled groups of users – i.e.: the customer service team or the

sales team.

Web application development opens new challenges in both areas.

Users do expect web applications to be familiar – they expect the

web application to conform to commonly accepted standards,

features and navigation. In addition, training is not really an option

as users of web applications are often broad groups with dynamic

memberships – i.e.: suppliers, customers and all employees.



30

Rapidly creating user interface pages is an advantage of application generated technology.This helps developers and end-users

give relevant feedback early in the

development cycle.

Application generation technology addresses this central challenge:

quickly generating a working application, so user feedback can be

collected in real time, and in a format that is helpful and relevant to

the developer.



31

Part 3)

Development Automation in

Action: Common Problems

Solved

Striking examples of how modern

automation techniques solve real‐world

development problems faced by all

developers of data‐ bound web applications.



32

So far, we’ve reviewed two high level concepts. In the first chapter,

we discussed why application generation is coming of age, and then,

in the second chapter, we described the evolution of the technology.

With the motivation and history of application generation in mind,

this chapter now dives into specific, real‐world, problems that

developers of today’s web‐ based data‐intensive applications must

solve to field production applications.

The examples here draw on our experience with Iron Speed

Designer, our application generator product. Shipping since August

of 2003, Iron Speed Designer is the leading application generator for

building web applications on top of Microsoft’s .NET framework

and SQL Server technologies. Currently used by hundreds of

developers to build applications ranging from customer service to

database publishing, Iron Speed Designer is the tool of choice for

many .NET

development

projects.

The examples presented here represent many development

problems where an application generator can greatly simplify the

task at hand.

Automate “C/R/U/D” Page Creation

Perhaps the most intimidating aspect of building data‐ bound web‐

based applications is the vast number of HTML forms needed for

users to create, review, update, and delete records in the relevant

database

tables.

While all of these pages are necessary (they’re the heart of most

usage), the work to produce them is probably the most boring.

There’s not much difference between one form and the next, and

each form, on its own, is rarely interesting. The volume of pages that

need to be created and the mundane nature of the task combine to

mute the enthusiasm of even the most gung‐ho developer. Perhaps

this is why developers use the derogatory term “C/R/U/D”

(Create/Review/Update/Delete) to describe these pages.

As you might have guessed, application generators can largely

mitigate the personality damage reportedly caused by such mind‐

numbing work.

Beyond eliminating the drudgery typically associated with the task,

application generators can also assist in enforcing corporate

standards. Once the appropriate templates have been set up, every

application that utilizes these templates automatically incorporates

any features included in the template.



33

When using an application generator with such a feature, it actually

becomes easier for developers to conform to these standards than it

is to deviate from them.

Layout pages as viewed from the Layout Page Files folder in Iron Speed Designer

One approach an application generator can take to automate the

production of repetitive pages is through the use of layout pages and

page templates. Several standard layouts and templates in a variety

of design themes can come bundled with the tool. When using an

application generator, you can either adopt these standard designs,

or create your own.

Database table view pages.Database table view pages function asreports in applications generated byIron Speed Designer. Unliketraditional reports, which are static innature, database table view pages arehighly interactive, and allowcustomization by application users.The database table view pages go far beyond typical web-based reportsbecause of this interactivity, andbecause they can allow application

users to add, edit, and delete data aswell as view data.

Developers select which columns are displayed in the table viewas well as their display order in the table and how the data issorted. Additionally, search and hierarchical drill-down controlscan be added to the table view.



34

Show Record pages.The Show Record page displays thecontents of an individual databaserecord in a field-value format. The

fields on this page are not editableby application users. These pages

can be configured as to which table fields are displayed and how theyare ordered on the page.

Add and Edit record pages. Add Record and Edit Record pagescan be created for entering andediting record data. These pagescan be configured as to which table

fields are displayed, how they are

ordered on the page, and whether the application user can enter values into the fields.

Delete Record Function

You should expect the application generator to create a Delete record

button for each table view page. A button for this operation should

appear above the table in the Database table view page.

Corresponding buttons for these web pages should be placed on the

table view page as well.

Delete buttons are automatically generated for table view pages.



35

Complex Displays

Today’s application generators create data‐ bound applications based

on the instructions you provide within your application’s HTML.

These instructions take the form of XML‐ based “code generation

tags” that specify the individual data‐ bound controls you want

within the page – the DataGrid controls, filter controls, search

facilities, and navigation controls. When the application generator

runs, it converts these commands into a combination of presentation‐

layer ASPX pages containing the actual controls, application‐layer

code‐ behinds and application logic, and database‐layer SQL

statements and transaction management code.

The sample job application site shown here was generated using

code generation tags inserted into an HTML layout page file. Each

job application is a row in the data grid and includes two additional

tables within the row – employment history and education. The

code generation tags used to create this application are shown here.



36

When you consider the difference in time and programming effort to

insert one code generation tag into an HTML page as opposed to

hand‐coding all the ASPX, C#, or Visual Basic code‐ behinds – plus

SQL statements for each control – it is easy to see how quickly an

application generator saves you significant time.

Some of the advanced functions enterprise‐class application

generators can handle include:

Displaying data in a data grid or table view

(ranging from simple row‐and‐column tables to

sophisticated tables within tables)

Parent‐child relationships

(one‐to‐many and many‐to‐many tables)

Filtering and sorting

(especially in

combination

with

other

page

controls)

Multi‐table joins

(from the same database or across multiple databases)

Data‐ bound controls

(e.g., search, sort, navigation)

Template‐driven columns

(e.g., box columns, uneven column height, multiple

databases)

Custom pagination

(e.g., alphabetical, non‐evenly distributed, etc.)

Generation of custom SQL statements

Data Entry

While each of these capabilities can be considered common

functionality, they also represent hours and hours of programming

and testing work by application developers. Let’s look at how

application generators approach these issues.



37

Using Data Grids to Manage Large Result Sets

Many data

grids

serve

their

purpose

as

simple

tabular

data

displays.

However, many CRM, contact management, and other back‐office

Web applications also need to offer forms input functionality to

application users. ASP.NET offers some shortcuts to make fields

editable. However, making an entire data grid editable or allowing

editing of template columns (using dropdown menus, for example),

requires an advanced knowledge of ASP.NET. A state‐of‐the‐art

application generator will allow you to make individual data grids

or entire forms editable (as shown here) without hand coding.

Dropdown lists, radio buttons, and other controls should also be

options for any data grid.

The standard ASP.NET DataGrid control fetches the entire result set

from a database query into the .NET application layer, even if that

result set has millions of rows. This leaves the application layer to

do the heavy lifting – sorting and filtering – activities best left to the

database rather than the application. Manipulating large datasets in

the application layer can have huge resource implications for

applications.



38

To minimize the data transmission load and the application’s

memory storage requirements, many application developers employ

database cursor management – a conventional, well‐established

database technique – to manage the number of records downloaded

from the database with each data grid page request.

An application generator can generate cursor‐management code that

retrieves one page of data at a time, and only when requested, rather

than retrieving the entire data set. Managing the “state” of your

application pages without dragging down performance is one of the

most difficult challenges for web application developers.

When cursor management is employed, the application program

doesn’t attempt to maintain the data set. When the next page (or any

other page) is requested, the generated application program simply

passes the request to the database layer, where the appropriate SQL

query

is

run

again

to

request

the

needed

pageʹ

s

data.

The

query

parameters include the page number requested and the batch size,

which is the number of records per page. Moreover, the SQL query

is rerun so that any records added or deleted since the previous page

fetch are properly accounted for. By contrast, if the cursor were

simply maintained, any data updates would not be reflected when

going from page to page.







41

would be placed next to any appropriate table view so that end‐users

can conveniently export data. Because of its near‐ubiquitous

compatibility with many data analysis tools, files exported by the

Export wizard should be saved in ASCII comma separated value

(CSV) format, one data record per file row. Of course, only the rows

in the currently selected table view should be exported. This is

convenient for end‐users who perform a search using the Search

control and then wish to export only the data subset that matches the

search.

Data exported by the Export wizard in an application created with Iron Speed Designer.

The exported data should include column headings in the first row

of the data to make it easier for other application programs to import

and make sense of the data.

Summary

These problems are representative of a myriad of issues and

challenges faced by anyone looking to build a data‐intensive web

application on Microsoft .NET and SQL Server. With IT

departments facing

ongoing

resource

and

schedule

constraints,

and

increasing application development complexity, application

generators represent an innovative solution to pressing problems

like these.



42

Part 4)

Goals & Benefits of Automated

Development

Understanding the strategic and financial

impact of automation on your organization.



43

Given the preceding concrete examples of specific real‐world

problems that application generators help solve, let’s consider the

broader goals of application generation, the new methodologies

enabled when those goals are met, and the organizational benefits

that are then feasible.

What Should an Application Generator Do?

Regardless of which type of application generator you choose, you

want the generated code to be something you can get your arms

around. The generator has to deliver a productivity boost.

Historically, code generators have often introduced as many

headaches as they’ve solved. For example, developers have

struggled with the incompleteness of the generated code, or the

difficulty of integrating that code with their own customizations or

extensions.

These problems and others can be avoided with careful diligence

during the tool selection. To assist you in the tool selection process,

this chapter describes:

the essential capabilities of modern application generators,

the impact these benefits have upon software development

methodologies, and;

the important attributes of high quality generated code.

We’ll begin with a high‐level overview of the capabilities of modern

application generators. To be considered state‐of‐the‐art, a modern

application generator should:

Start from scratch with an application‐specific data model.

As an easy first step, create everything needed for a

functional three‐tier application, link everything together,

and deliver a bug‐free, functional prototype of the desired

application.

Automatically generate all of the source code for the

application, native to the target platform, and optimized for

the production environment.

Provide complete and well organized source code thatʹs easy

to understand, modify and extend.



44

Automatically preserve and reintegrate customizations and

extensions during subsequent application regenerations.

Starting from Scratch: The Application‐Specific Data Model

When building software applications, how you start has a huge

impact on where you finish. In most situations, the web application

to be built will depend on existing databases, and the information

architecture of the relevant data and data model.

Whether engineered by architects or organically evolved over time,

every production database sports a data model. As you might

expect, the way this data is organized is central to the design of any

custom software application.

For the best results, modern application generators import and

organize the code they produce around the production data model.

No development tool should ever introduce its own special‐purpose

data model, or force a conversion from one model to another.

General‐purpose one‐size‐fits‐all approaches to the underlying data

can create unnecessary performance, complexity, and maintenance

problems downstream.

Thankfully, modern application generators are designed to create

custom applications around any data model.

The Very First Step: A Functional, Bug‐Free, Application

A common frustration shared by many developers who’ve

experimented with code generation tools centers around the

incompleteness of the code that’s created by the tool. In some cases,

a tool may only generate code for one part of the application (just the

HTML pages, or just the controls, or just the application logic, etc.).

In such cases, the developer must learn how to connect the generated

components with the parts the tool didn’t create. If the tool doesn’t

provide adequate assistance, such an effort can be laborious, tedious,

and frustrating.

Not so with application generators. The main distinction between

code generators and application generators is one of scope. An old‐

fashioned code generator may help a developer produce some parts

of the application that are repetitive in nature, but most of the

responsibility for the overall design and implementation still rests

with the developer.

Application generators, on the other hand, take on much more

responsibility. This generation of tools provides the overall

architecture for the application, generates code for every standard



45

feature, and provides a context for the developer to extend and

customize the application.

Today, these application generators utilize the tables you select from

existing databases, generate all of the necessary source code for

every standard feature, and deploy the prototype. A few even

provide a link to an operational, bug‐free, demonstrable, application.

Code Completeness & Organization

Of course, even the most feature‐rich generated application isn’t

entirely useful if the source code is unintelligible or scattered.

Whenever a generator produces source code, it needs to be created

and stored in a way that’s naturally intuitive.

While every developer faces some learning curve when using any

new development tool, such a challenge can be mitigated when the

tool produces code that’s easily read, organized well, and flows

naturally into the developer’s standard development environment.

Extending the Code Generator Itself (Automated Code Reuse)

Lastly, and perhaps most importantly, application generators should

automatically preserve and reintegrate customizations or extensions

during subsequent application regenerations.

Today, most good application generators are themselves extensible.

A major drawback of past code generator efforts is that the tools

were one‐way streets: Once you pushed the generate button, you

owned the code. Such a primitive approach just doesnʹt work for

todayʹs iterative style of development.

Ideally, the application generator should allow you to put your

extended or modified custom code back in, and allow that custom

code to become part of what the tool can generate for future

applications. Rather than just spit back out what is put in, the

application generator adds value by creating a repository of code

assets. Further, by automating the process for reusing customized

code written for one application in another, these assets become

more flexible and multi‐purpose. Using application generators, you

and other developers anywhere in your organization can easily

leverage these code assets over and over again.

In essence, the application generator does what no developer has

time or incentive to do: It manages selected application code and

creates a knowledge base of re‐usable code that meets the specific

standards and practices of that unique organization. Once in place,

code written specifically for one application can be regenerated for



46

future application development automatically. All of this takes place

without any additional work or drag on the initial applicationʹs

project schedule.

Specifically, you might leverage custom code in the following

scenarios:

Presentation Layer: Because many large enterprises require locally

constructed applications conform to a distinct set of functionality as

well as look‐and‐feel standards. With modern application

generators, this standard functionality is implemented once with

custom HTML layout pages. Originally built for an initial

application, these layouts can be automatically re‐used when

creating future applications. Once in place, it’s actually easier for

developers to conform to such standards than to deviate from them.

Application Layer: Any aspect of the application logic should be

able to

be

extended

and

then

re

‐generated

for

future

applications.

For example, an order management system may apply different

order validation logic for orders coming from partners than for

orders from the inside sales team. Another example might be

custom data structures to represent various award levels in a

customer loyalty application. In both of these cases, once the custom

code is created for one application, it can be re‐generated for

additional applications automatically.

Data Layer: The generated application should be able to work with

any data source, not just SQL‐centric databases. Examples of

alternative data sources include custom web services, message buses

(such as IBM’s WebSphere MQ or Tibco’s Rendezvous), and even

real‐time data feeds from sensors such as digital thermometers,

cameras, or motion detectors. Since all of these sources are

potentially relevant consumers and producers of data, generated

applications need to be constructed in a fashion that embraces these

data services, and makes integration as straightforward as possible.

In each of these scenarios and more, application generation delivers

on the promise of code re‐use by eliminating the re‐use development

penalty, and automating the inclusion of these custom extensions

with new applications as they are generated.

Later, we’ll show several examples of how code re‐use is enabled

through application generation. Of course, the benefits of employing

an application generator can be diminished if the code that’s created

automatically isn’t well formed. It’s crucial that the tool create

“good code” that can be understood, extended, and customized by

the development team.



47

Characteristics of Good Generated Code

In order to evaluate the true effectiveness of any application

generator, it is important to understand the necessary characteristics

of the generated code. Some of these characteristics are identical to

those

we

expect

from

a

top‐

notch

programmer.

Others

are

specific

to what a development team needs when code is automatically

created for them.

We should expect great code from both talented senior developers

and application generators. First, they both need to create code that

is easy to understand— another programmer should be able to take

over code and not feel a need to rewrite all of it.

Whether it’s generated or not, easy to understand code has several

important characteristics:

It is organized in source files in a logical and consistent way

(usually hierarchically), which makes it easy to find the code

for a particular function, structure, class, method, or

definition.

The code naming conventions clearly indicate the role of the

entity.

The code is formatted cleanly and there is little residual or

unneeded code lying around. There’s little to no “clutter” in

the source files.

In‐line comments are plentiful, and clearly indicate the

function and structure of the code, and its intended purpose.

Second, the code needs to meet the highest standards of good coding

practices. These standards include using the programming language

in a straightforward and universally accepted way. The

programming logic and algorithms must be clear and efficient. In

addition, the code needs to meet commercial‐level quality standards

by including features such as:

Built‐in data validation

Built‐in exception and error handling

Built‐in user access controls (security)

The code also needs to take advantage of the underlying

development platform or framework. That is, it should use the

functions, classes, and other features of the underlying libraries in a



48

way that takes advantage of the power of the development

environment.

The code should be easily ported to newer versions of the

development library, and it should be able to take advantage of new

features as they are introduced in new versions of the development

platform.

Implications for Development Methodology

As the application generation technology described above becomes

widely available, it’s sure to have an impact on how professional

software developers go about their business. The next few pages

describe some of the changes to expect as programmers incorporate

automation tools into the way they build enterprise software.

In a classic application development model, three groups of

individuals are involved in the development team. System analysts determine the functionality of the

application and write the specification. Then the

database administrators and process modelers get to

work and build the necessary databases (models) for

the application. At that point, the programmers start

coding. Once the programmers start writing the code,

they don’t let go of the code until the application is

released.

When you use an application generator, this model

becomes more

complicated,

because

a fourth

party

(the application generator) is added to the process.

Each time the data or process model changes, the code

must be regenerated. In most application

development efforts, the data model is in a state of

flux throughout the coding process, which creates a need for

adaptability (usually by the development staff). In a changing

environment, an application generator must be able to play a

supportive value added role, rather than an obstructive role, to the

development team.

For example:

The development team not only requires access to 100% of

the code that the application generator creates, but the code

must be easily extended and customized.

The development team must be able to easily integrate pre‐

existing code after generation.

System Analysts

Database AdministratorsProcess Modelers

Appl ication Generator

Development Team(Code Customizers)



49

The development team must be able to regenerate the

application and not lose customizations, extensions, or

integrate pre‐existing code.

Once a development team integrates application generators into

their development processes, they employ more effective

development techniques in a variety of ways. The next few pages

introduce a few of the new approaches enabled by application

generators.

Gather Feedback Early & Often in the Cycle with Real Software

Typically, development requires some proto‐types of the application

in order to gain relevant and helpful feedback. The RAD approach

prototypes the application in order to obtain some of this feedback.

But RAD doesn’t usually build much of the final application.

A more iterative development style becomes possible when the

ability to create and deploy custom applications quickly becomes

financially feasible. Iterative development manifests itself with

growing use of re‐factoring (leveraging existing code assets into new

web‐ based applications) and RAD tools.

This trend, prevalent in IT shops throughout the industry, notably

shifts emphasis away from restrictive application platforms and

outsourcing – both of which are proving to be riskier and more

costly than originally anticipated.

Moreover, iterative development lends itself better to today’s more

dynamic business environment than more traditional structured

development methodologies. An iterative approach embeds

developers within the operational line management of an

organization, and allows them to constantly incorporate frequent

feedback from end‐users. Iterative developers recognize that the

most successful applications are constantly refined, and actively

morph those applications to accommodate the shifting needs of the

ever‐changing modern company.

Application generation technology goes further than the rapid

application development (RAD) approaches of the past and the more

recent extreme programming trend. RAD is about putting a

prototype in front of users to obtain feedback during the

development cycle, not just at the end when it is too late and too

complicated to make any significant changes.

Most users (and clients) have difficulty articulating what they want

in a desired application because they can’t envision it. In this



50

respect, RAD is really helpful because a prototype (or even a mock‐

up graphic) can spur a dialog.

Sometimes, the user community requesting an application from the

IT department will employ a graphic artist to develop the web‐ based

interface in order to guide the discussion with the development

team. This can be helpful, but this tactic usually involves designing

about half a dozen of the top‐level screens. However, production

quality web applications can have hundreds or even thousands of

screens. Some of the really important workflow screens – like

account maintenance pages and data importing wizards – inevitably

get left out of this process. And yet, often those workflow

experiences represent the kind of feedback developers need most.

Until meaningful dialog occurs between analysts and users,

functional requirements typically remain vague and incomplete.

Using an

application

generator,

developers

can

dramatically

shorten

the path to meaningful dialog. Instead of an incomplete prototype

or mock‐up graphics, they can generate a functional first‐pass of the

entire application, and populate it with real‐world data. By

presenting a live, robust application to end users, developers

empower them to give deep and meaningful feedback for all levels

of the application.

Still, successful iterative development requires advanced software

tools to keep everything organized. Otherwise, this somewhat

chaotic development process can lead to a big pile of spaghetti code.

This is where contemporary application generators can help. They

are designed to facilitate iterative development, and reduce

development time penalties as changes are made and updates

deployed.

Use Business Analysts to Develop Prototypes

Beyond enabling early and relevant feedback on working

applications, application generators empower IT departments to

rethink the resource mix and project assignments of traditional

development teams. Since experience with C#, C++, Java, or Visual

Basic isn’t required, application generators empower new categories

of developers (business analysts, program managers and

information architects) with unprecedented abilities to create and

deploy working applications. This differs considerably from RAD

and extreme programming methodologies that require developers to

create prototypes before end‐user feedback can be gathered.

Typically, these members of the IT department are specifically

trained and experienced at gathering feedback from end‐users.



51

Application generation technology gives these non‐developer

members of the IT department an expanded role in the development

cycle, and frees developers to focus on the aspects of the application

which do require custom programming.

Simplify

Software

Maintenance

As soon as web applications are launched, requests for modifications

start rolling in. Sometimes these are issues end‐users did not

anticipate; sometimes they reflect changes in company strategy or

market conditions that were unanticipated. Sometimes user

interface changes are necessary because of advances on the other

websites. As certain features become commonplace, every web

application is expected to keep pace. Why do web‐ based portals

change their look and feel continuously and yet “Time” magazine

does not? The web makes everything more accessible, and increases

the competitive pressure for pushing more, rather than less, to the

user community.

This pressure to constantly evolve and improve lands squarely on

the IT department and makes application maintenance more

significant than with client‐server applications. Before the web, the

concept of RAM – rapid application maintenance – was never a part

of the application development tool set.

Typically, this sort of maintenance is a developer’s least favorite

task. There is nothing worse than trying to guess what “the other

guy” was thinking when he wrote the original code.

Application generation largely solves the RAM problem.

Application generators fully re‐generate the entire code base with

each modification. The generated code keeps up with each new

revision and each new management directive. So finally, for the vast

majority of the application’s source code, no one has to perform

“software archaeology” to understand someone else’s work before

accommodating a relevant change request.

Custom‐build the Unique Aspects of your Application

With an application generator, you should expect to generate about

80% of the application code, expect to focus the vast majority of your development resources on the other 20% of the application that is

unique and proprietary. This remaining 20% will contain the unique

algorithms and business logic and must be developed by hand.

Be very wary of any tool that claims to create 100% of every

application.



52

Given that a crucial part of the application must be created by the

developer, modern application generation software offers

convenient and comfortable interfaces for developing and

integrating this remaining, but crucial, 20%.

There are two common types of integration that must be considered

when using application generation software: integrating business

logic and communicating with external applications.

Integrating Business Logic

Integrating business logic requires a close coupling between the 80%

that is generated and the 20% that is built by hand. This is best

accomplished by a set of API’s, or set of objects, for connecting your

code with the generated code. Ideally, this integration is persistent

from regeneration to regeneration, meaning that your integration

work is not lost each time the application is regenerated by the

application generator.

If

it’s

lost,

then

you

lose

much

of

the

benefit

of using application generation software in the first place.

Integrating External Applications

Integrating external applications, such as a third‐party CRM

package, is best handled using application integration protocols.

Increasingly, web services protocols like SOAP are being used for

external integration, and ideally, your application generator

supports these web service protocols as well.

Key

Benefits

of

Application

Generation

Methodology

Once application generators are integrated into the development

process and culture, development organizations can realize a

number of benefits associated with adopting this automation

technology. The next few pages explore a few of these important

benefits.

Speed Development and Reduce Testing Time

Even if end‐users want to “webify” their favorite client‐server

application, the development cost to re‐factor existing applications

into new and improved streamlined web versions is often too high. Recognizing this dilemma, several vendors offer a variety of tools

that promise to improve developer productivity, and hence, lower

these developer costs.

Today, application generators, code generators, and RAD tools

automate various aspects of application development, and promise

to reduce overall development costs. In fact, Microsoft is releasing



53

ASP.NET 2004 with several new features to improve developer

productivity such as drag‐n‐drop wizards and some automated code

generation. Another example from Microsoft is the Enterprise

Templates feature in Visual Studio .NET. These templates are

planning and design modules that allow the developer, among other

things, to build code snippets in the IDE itself so they can be shared

across a number of applications.

In essence, these tools make it possible for developers to automate

and manage the development of application code, and create a

knowledge base of re‐usable code assets that meets the specific

standards and practices of that unique organization.

This means that the cost of application development and

maintenance is dropping – fast – for those organizations and

developers who are adept at incorporating this new generation of

tools into their development processes.

Enable Corporate Computing Standards

In addition to cost‐effectively building and maintaining state‐of‐the‐

art enterprise web applications, today’s developers must write this

software in a way that conforms to corporate standards. IT

organizations strive to establish and maintain standards for many

aspects of the software they write such as user interface,

functionality, navigation, look and feel, colors, etc.

Once in place, such standards assist IT organizations to reduce

training and support costs by leveraging user experience.

Unfortunately, the costs associated with upholding such standards

can mitigate their benefit. When developers are saddled with

constantly re‐engineering code to conform to these standards,

compliance tends to degrade.

By adopting a development methodology that incorporates

application generation as a central theme, IT organizations can turn

the tables on this common problem. Once an application generator

has been extended to support corporate standards for user interface

and functionality, future development efforts can support these

standards at no

additional

development

cost.

In fact, deviating from the

corporate standard is actually more expensive than conforming to it.

All of a sudden, the economics of supporting standards are reversed,

and the benefits of standardization can be realized across all new

web application development efforts.



54

Automated, Yet Robust UI Brings Application Power to Light

In web‐ based applications, the user interface takes on significantly

more importance than in their client‐server cousins. Because of its

ubiquitous nature, the web is already familiar to corporate end‐

users.

As

a

result,

end

users

typically

expect

any

web‐

based

application to be easier to use.

In fact, the user interface has become the bell weather for application

robustness. Even experienced developers (who might know better!)

will look at a user interface and make judgments about the

complexity and depth of the underlying application. This can be

somewhat frustrating to information architects and developers who

can spend enormous effort creating powerful capabilities at the

application or data layers.

Regardless of the power or performance of the underlying database

representation, the web‐ based user interface sends the most powerful message about the entire application than any other aspect

of the system. The impressions of end users and management are

shaped, by and large, by the user interface.

Most application developers, however, are not trained to build

highly usable and interactive web‐ based interfaces. While large

commercial e‐commerce and corporate sites have teams of people

designing the web pages, most IT departments don’t normally have

access to these experts.

Again, application generators can help. They automatically generate

the browser‐ based user interface pages and the underlying user

interface code. Moreover, they do so using contemporary user

interface standards. These standards leverage the experience end

users have with other web applications. Application generators

leverage these standards and the experience base of most web users

to make the applications they create more user‐friendly than those

built by hand right from the start.

Part of the ease of use advantage generated applications results from

mere completeness. Generated applications include all the top‐level

pages and reports you’d expect, and all the routine account

information and data management pages. Such pages normally

require hours and hours of mind‐numbing tedious development to

create, but are essential to deploying any production system. By

providing all of these pages up front through automation, generated

applications avoid all of the usability problems associated with

common errors of omission and simple programming errors.



55

Real data can be imported so end‐user testers can offer feedback

based on actual scenarios. So, application developers do not need

specific graphics training to generate attractive and compelling

graphical interface pages.

Scalability

Building transaction‐intensive web applications that scale is easier

said than done (and it’s not even that easy to say). When faced with

multiple high priorities, tight deadlines, and limited resources,

developers can cut corners on creating applications with scalability

in mind. Often times, these quick‐fix style applications don’t

anticipate needs beyond short‐term requirements. As these

applications become integrated into an organization’s business

processes, they can generate mountains of change requests, and

consume more and more resources as their creators continue to

patch and fix and enhance an application that was never intended

for the current usage pattern.

Even considered upfront, scalability is, even for experienced

developers, difficult to implement. Since all of the business logic in

web applications is concentrated server‐side in the application layer,

scalability frequently becomes a big issue for web applications.

Functionality isnʹt distributed to the client‐side as it is with client‐

server applications, so you canʹt rely on the application userʹs

machine to off load computationally intensive tasks. Hence,

improperly designed applications can cause performance bottlenecks

in the middle‐tier. Application generators should build applications

with a three

‐tier

architecture

that

scales

easily,

including

optimized

SQL, and advanced transaction, cache, and session management

techniques.

As you can see, the demands on an application generator are high,

and all of these demands must be met for this method of application

development to be a viable solution.

Boost Your Company’s ROI

Utilization of application generators has meaningful financial

benefits to any organization choosing to leverage the technology.

Consider the following table:



56

Programming Challenge Native .NET program code generated by Iron SpeedDesigner in just a few hours

Time Savings Cost Savings*

Presentation Layer

Sophisticated User Interfaces:

Page filters and sorting,including end-user reports

Iron Speed Designer generates all the web pages required

for enterprise-class applications. Quickly add sorting andfiltering on tables, records and fields.

100 hours $4,000

Sophisticated User Interfaces:Full text search

Select search for any combination of tables or fields. 10 hours $400

Sophisticated User Interfaces:Navigation

Add hierarchical navigation to any page or database tableview.

10 hours $400

Sophisticated User Interfaces:Pagination

Add pagination controls to any database table view. 15 hours $600

Appl ication Layer

Application Architecture Generates a standard 3-tier architecture with presentationlayer ASPX pages and ASCX controls, an application layer class hierarchy that is easily modified, and database layer SQL statements and transaction management code.

Weeks or monthsof hand coding $400 - $12,000

Code Extensions Generates a straightforward class hierarchy that easilyaccommodates code extensions. All your codemodifications are preserved.

Same N/A

Database Layer

SQL Statements Generates all the SQL statements required in efficientstored procedures

100 hours $4,000

Application Security Automatically generates role-based security for anynumber of roles, using your own “users” table.

35 hours $1,400

*Based on $40 per hour

The table above uses simple time‐savings for just a few common

features to begin to calculate the financial advantages of utilizing

application generators.

Beyond these simple yet concrete figures, other important factors

should also be considered when calculating the ROI of application

generators. For example, using an application generator generally

means that you’ll be deploying applications faster, and the software

starts working for your company sooner. In cases where these

applications enable productivity gains or new revenues, the value

associated with earlier deployment dates can be extraordinary.

Keep Development In‐house

Most IT directors don’t outsource development because they disdain

software development. They’d still prefer to develop in‐house. The



57

goals of most outsourcing are to save money and to get applications

launched more quickly. From a financial perspective, the headcount

cost advantages of off‐shore development resources appear to stretch

development dollars farther, and enable the development of more

application software with the same, or even reduced, budget dollars.

Alas, the hidden costs of outsourced development projects are

frequently worse than their promised savings. While it may appear

cheaper at first, managers of outsourced projects soon learn that

someone who does not speak your language and located 12 time

zones away is really hard to manage. Moreover, they can never fully

understand the internal customers you support because it is hard to

collect and share user community feedback. The dialog between

users and developers can disappear when faced when significant

barriers (time zone differences, native language differences, and

corporate culture clashes) exist between users and developers.

When dealing with demanding users and tight deadlines, these

challenges can be especially troublesome.

Further, mission‐critical applications tend to embed a tremendous

amount of intellectual property in relevant source code modules and

databases. Granting outsiders access introduces significant risk to

the business. Losing control of these assets means competitors could

get access to your proprietary data and business processes. Beyond

competitors, such assets would be of great help to malicious hackers

looking to cause chaos within your enterprise systems.

So what is a budget‐challenged IT director to do?

An increasingly preferred alternative is to keep the work in‐house,

use advanced software tools to empower non‐developers to do a lot

of the heavy lifting for routine infrastructure programming, and

focus developer resources on the unique and career‐ building code

that gives the application personality and dimension. These

advanced tools include application generators, tier code generators,

RAD tools and component libraries.

For example, a developer at a major tire distributor recently

launched an enterprise‐wide store reporting application for 360

stores in just two days using an application generator. His original

estimate for developing the application by hand was 2 person‐

months. While this wasn’t the most complicated and demanding

application, there’s no doubt that his 2‐day turn‐around time

provided a faster, easier, safer, and cheaper alternative to an

outsourced solution of any kind.

Since application generation speeds development and lets you keep

the entire application development project in‐house, it compares



58

very favorably to the only alternative: outside professional services.

Outsourcing is often impractical or overkill for application

development, and can be very costly both in terms of fees,

management time and attention, and security.



59

Part 5)

How Automated

Development Works

An insider’s guide to the inner workings of

a modern application generator



60

Approaches to Application Generation

Recognizing the advantages of application generation as detailed in

the previous chapter, developer tools providers have introduced a

variety of

products

to

help

programmers

realize

the

benefits

of

automation. As with most aspects of software development, there

are a variety of approaches and philosophies regarding such tools

and their relationships to the developer and the development

process.

The MDA/UML Philosophy

Some tools subscribe to the UML/MDA approach. Here, the tool

creates source code for your application based on a model of the

application functionality. The methodology associated with this

approach typically requires a lot of effort up front, in the design and

planning stage, to build an architectural model of the entire

application as a first step. Once the model is created and complete,

the tool converts the model into application source code.

The Algorithmic Approach

Another philosophy for an application generator centers on an

algorithmic approach. Here, the tool infers the application

functionality from a particular input source. Some tools start with

the database, and infer the business logic and UI from there. Other

tools emphasize either the business logic or the UI as the starting

point. In any case, an algorithmic approach employs an algorithm to

drive the creation of your application.

Recently, a new approach to application generation has appeared.

This new approach, called the declarative method, empowers the

developer by creating the application with multiple inputs

(primarily based on user interface requirements and existing

database schemas).

The remainder of this book will focus on this declarative approach,

it being the most recent and most powerful approach to application

generation.

The Declarative Method Philosophy

Declarative application generators work by translating a declarative

description of your application (for instance, an HTML page

containing code generation instructions) into a working n‐tier

application with well‐partitioned service layers.



61

Unlike algorithmic generators, declarative application generators

don’t presume to know what the functionality of the application

should be. Rather than rely on a predetermined and static

algorithm, they dynamically create the application based upon the

direction of the programmer.

The declarative method of application generation recognizes that

only a small percentage of the code in any application is the “secret

sauce”—the truly unique elements that differentiate one application

from another. Accordingly, the 80%‐90% of the application that is

basic infrastructure lends itself quite well to automatic generation

based on a specification of what the developer wants in the

application.

This declarative method is an important and useful approach for

modern .NET application development because:

This is

how

developers

work.

Most applications are architected based on a handful of HTML pages

and a database schema. Developers build the application from those

starting points. (In fact, HTML mock ups and database schema

diagrams form the foundation of many application development

proposals.) The declarative application generator does the same

thing—it uses your user web pages and existing database as inputs,

and generates a large volume of infrastructure code in a fraction of

the time of hand coding.

Also, declarative method application generators typically can create

custom working applications —not just a prototype or individual

components— in just a couple of hours. Such an approach supports

an iterative approach to development, and shaves months off the

development cycle.

Specifying an Applicationʹs Basic Functionality with Code

Generation Tags

By way of example, the Iron Speed Designer application generator

calls these declarative descriptions “layout pages.” Layout pages are

HTML web pages that define your applicationʹs web‐ based user

interface and contain simple XML‐ based code generation tags. Using your favorite HTML editor, you insert code generation tags

into your HTML at each place where you want a page control to

appear—everything from a data grid table to filters to data‐driven

menus. Once code generation tags are placed in the page, the

application generator prompts the developer for information about

which database tables and fields to use for each data‐ bound

component.



62

The end‐user never sees the code generation tags because theyʹre

stripped out when creating the application. When the application’s

pages (or screens) are generated, the tool reads the tags and replaces

them with all the appropriate code. This process efficiently

constructs these complex pages, and accurately connects each data‐

bound control to the database. As a result, you do not have to waste

time programming ASPX, VB or SQL to create sophisticated user

interfaces with an application generator. (Later in this chapter, we’ll

further describe how code generation tags drive the Iron Speed Designer

application generation process.)

Inputs to Generate Your Application

Declarative‐method application generation accommodates highly

iterative development. This enables you to generate your n‐tier

application with two inputs: your HTML‐ based layout pages,

including code generation tags, and the set of database tables

(schema definitions). Using the tool, the controls included in your

applicationʹs web pages are “bound” to the specific database tables

and fields. This binding information is used by the tool to generate

your application to your custom specifications.

What Declarative Method Application Generators Create

Using these inputs, application generators produce all the code

required by a functional application. This code is organized in a way

that’s consistent with standard n‐tier architectures.



63

Iron SpeedDesigner

generates acompletethree-tier application.

Presentation Layer—a complete web‐based user interface

Sophisticated web‐ based user interface pages, including database‐

connected forms, tables and reports. Advanced features include

reports with filtering and sorting, full‐text search, navigation, data

validation, and table pagination.

Application Layer—native .NET program code

Easily extensible class hierarchy built on the platform base classes

(such as the .NET Framework), as well as enterprise‐class features such as role‐ based user access control.

Database Layer—all your SQL and transaction management

All the SQL queries for data display and reporting as well as record

insertion, modification and deletion are generated. Advanced

features include multi‐table joins and a page‐ based transaction

model.

Generating the Web‐Based Presentation Layer

Translating an end‐usersʹ vision for their web application into a

functional and intelligent user interface requires three main steps,

each of them non‐trivial.

Build the applicationʹs basic functionality with the selection

and placement of sophisticated page controls and functions

ranging from filtering and sorting, to search and pagination;



64

Create the hundreds of web pages required to access and

run your application, including input forms, reports, and

data displays;

Connect the pages and controls to the database.

Fortunately, declarative method application generators can help

with each of these steps.

Create Hundreds or Thousands of Web Pages

Early on, when brainstorming or selling the project, only a handful

of high‐level pages are typically mocked up by a web designer.

These pages help communicate the basic ideas about the proposed

application to all those involved. But to actually build and deploy

the application, the developer must create the rest of the pages by

hand based on these initial designs. While designing the

applicationʹs look

‐and

‐feel

is

not

trivial

to

begin

with,

repeating

it

over and over for each of the hundreds of pages required to run your

web application is a significant and time‐consuming chore.

The four standarddatabase-connected tableview pages can beautomatically generated

for each table in your applications: Show Table,Show Record, Add Recordand Edit Record.

Top‐tier application generation tools save you this struggle by

automatically creating a suite of pages for each database table,

database view or named query in your application. These pages

reflect the four standard operations performed with any data grid:

Create record, Retrieve record, Update record and Delete record—

the “C/R/U/D pages.” Each page will be automatically linked to the

appropriate navigation menu.



65

Connecting Web Pages and Data‐bound Controls to the Database

This graphicemphasizesthe

relationshipbetween twocode

generationtags asinserted in alayout page,and theresulting

pages withcorrespondingdata-boundelements.

When using

a declarative

method

application

generator,

once

your

code generation tags are placed in your layout pages, the tool

prompts you for information required to connect the resulting

controls to the underlying databases and to set other parameters.

Typically, a wizard guides you through this binding process, and

you donʹt need to know any SQL or be an experienced programmer

to generate advanced page controls.

When the application is generated, the code generation tags are

stripped out of the final ASPX pages, and replaced by corresponding

web controls, server‐side code‐ behind logic, and transaction

management code. This means that code generation tags have no

run‐time effect on your application because they are not present in

the generated application source code – they only exist in

preliminary input files for the purpose of informing the application

generator about the required functionality.

Many IT departments have an SQL “ombudsman” who is an expert

SQL DBA and checks the SQL code written by all the other

developers. A declarative method application generator simplifies



66

the developerʹs and the ombudsmanʹs tasks by automatically

generating every SQL query (and the wrapper code around it) for

each web‐ based component that accesses the database.

In this way, the declarative method application generator creates a

complete, custom web‐ based user interface for complex, data‐driven,

web applications—typically hundreds or even thousands of distinct

web pages. This approach allows you to quickly create sophisticated

pages, including:

Database table view pages with complex data grid controls

Individual record view pages

Add/Edit/View pages for each table view and record type

Reports

Data input forms and editable tables

Account management pages

Customizing Generated Applications

Further, most declarative method application generators typically

work with the expectation that they are not producing all of the code

for the application, only most of it. As a result, they provide

mechanisms for incorporating custom code as part of the process.

For many applications, some or all of the following may be required:

Integration with existing custom systems using

programming languages such as Visual Basic, C# or J#.

The addition of custom application logic.

Additional or customized data validation code.

Adjustment of stylistic elements ranging from changing the

applicationʹs look‐and‐feel—the colors, fonts and other

visual elements—to creating more complex page layouts

with multiple database‐connected tables, fields and filter controls.

When using a declarative method application generator, one

approach is to generate a “generated” class for each page that is

updated with each regeneration, and a separate “safe” class that is

generated once and never overwritten. Placing modifications in the

“safe” classes preserves them, and makes them reusable for future



67

applications. The customizations of the generated application are

preserved when you regenerate the application.

This process is discussed in great detail later in this document in the

Modifying Generated Applications chapter.

100% Access to Generated Code

Application generators based on the declarative method generate all

of the code you need for a working application, and typically don’t

require any additional server‐side libraries or licenses. Products that

claim to help automate development, but also require special server

software from the tool vendor to actually deploy the application can

no longer be considered state‐of‐the‐art. Sometimes, these old‐

fashioned deployment schemes impose unnecessary performance or

functional bottlenecks. Some even impose additional licensing

restrictions on how the application can be deployed.

Modern application generators impose no such restrictions.

Now that you have a basic understanding of how application

generation works, let’s explore the process in more detail. The next

section describes how code generation tags and layout pages are

used, details the component binding process, explains how database

tables are linked to applications, and explains how application

generation produces the presentation layer, the application layer,

and the data layer of each and every application it creates.

Using

Declarative

Methods

to

“Specify”

an

Application

As we reviewed earlier, the application’s user interface depends

greatly upon the layout pages you create — HTML infused with

code generation tags. Let’s look at how you can use your favorite

HTML editor to create the layout pages with any design you choose.

All HTML, DHTML, and client‐side scripting in these files is

incorporated into the ASPX pages generated by the application

generator.

Layout Pages

When using a declarative method application generator, HTML

layout pages define the application’s web‐ based user interface and

contain code generation tags that define which data‐ bound controls

you want on the various pages (more about this in the next section).

Layout pages are normal HTML files with .HTML file extensions.

They can contain any HTML you wish, in any design you wish.

Most layout pages are created using one of the popular web page



68

layout tools, such as Macromedia Dreamweaver, Microsoft

FrontPage, and Microsoft Visual Studio.

Alternatively, you can allow the application generator to create them

for you. These tools can generate certain layout pages from pre‐

formatted page templates, including pages with database table

listings and for database maintenance, such as viewing a record,

adding a record, and editing a record.

The following code represents a simple layout page with a number

of common code generation tags.

<HTML>

<body>

<GEN: Recor d Name=”Cust omer ”>

. . .

<t d><GEN: Fi el dVal ue Name="Fi r st Name"/ ></ t d>

<t d><GEN: Fi el dVal ue Name="Last Name"/ ></ t d>

<t d><GEN: Fi el dVal ue Name="Addr ess" / ></ t d><t d><GEN: Fi el dVal ue Name="Ci t y"/ ></ t d>

<t d><GEN: Fi el dVal ue Name="State"/ ></ t d>

<t d><GEN: Fi el dVal ue Name="ZI P"/ ></ t d>

<t d><GEN: Fi el dVal ue Name="Count r y" / ></ t d>

<t d><GEN: Fi el dVal ue Name="PhoneNumber" / ></ t d>

. . .

</ GEN: Recor d>

</ body>

</ HTML>

Regardless of how the layout pages are created, they may have any

layout and design you choose, and may include any HTML, DHTML, and client‐side scripting in your layout pages that you

wish passed through to the ASPX pages generated by the application

generator.

How Code Generation Tags Work

When using a declarative method application generator, any

combination of simple XML‐ based code generation tags can be

placed in your layout pages to add components such as data grids,

field values, filters, buttons, and images to your web pages. Just

place the

appropriate

tag

in

layout

pages

at

the

location

where

you

wish the specific control to appear.

You can use code generation tags to:

Add any number of data‐ bound components to a web page,

including tables, records, fields and filters. Create pages of

any sophistication and layout.



69

Change the look‐and‐feel of the generated components,

including colors, fonts and other stylistic elements.

Create composite components using pre‐existing

components.

Create component and page templates that can be applied to

any number of pages in your application.

Code generation tags are very easy to use.

Because code generation tags are XML statements, any HTML editor

can be used to add them to any new or existing HTML layout page.

HTML editors and web browsers ignore them for display purposes,

and allow the pages to be viewed without seeing the code generation

tag.

The application

generator,

however,

interprets

them

during

the

component binding and application generation processes, and

replaces them with the code for corresponding web controls, code‐

behind logic and transaction management.

Unlike many scripting languages, code generation tags aren’t SQL

queries, so neither the developer nor the web designer need learn the

SQL language. The application generator generates all of the SQL

queries using information gathered about each of the code

generation tags during the binding process.

Code generation tags are designed to be used by web designers – the

graphic artists who design the creative layout of web pages –

without requiring them to become programmers or learn any new

language. A web designer can drop a code generation tag into a web

page specifying only the tag type and name. There are no additional

parameters to learn or program.

Code generation tags do not specify database binding. The

application generator prompts the developer for the additional

information it needs to generate the page component specified by

each code generation tag. Thus, programmers can focus on layout

without worrying about how to connect the components to the

database.

Code generation tags exist for everything from very simple to highly

complex page components. Some tags instruct the tool to generate

code to display data on a page, while other tags instruct the tool to

generate navigation and filtering controls. Still others govern page

layout.



70

Code Generation Tags Used by Iron Speed Designer

Field Display Tags Record Tags Table Tags Table Component Tags

FieldLabelFieldValue

Record TableItemTemplateAlternatingItemTemplate

SeparatorTemplateHeaderTemplateFooterTemplate

FieldStatisticsPaginationTableStatistics

Filter Tags Layout Tags Button Tags Grouping and Iteration Tags

CategoryFilterFieldFilterSearchFilter

HTMLHyperLinkImageLabelLiteralText

ImageButtonLinkButtonPushButton

ForEachGroupTemplateUse

The application generator binds these code generation tags with the

right data during the binding process. Later, during the application

generation process, the application generator replaces the code

generation tags with ASPX and the appropriate control tags (such as

Microsoft .NET server control tags).

The Image Tag – A “Hello World” Example

One of the simplest code generation tags is the Image tag. The

Image tag displays an image in the generated web page, and can

reference a URL, a file name, or database table. The example below

shows an Image code generation tag in an HTML layout page and

the resulting page.

<HTML>

<body>

<GEN: I mage Name=”Logo” / >

</ body>

</ HTML>

The Image tag is placed in the HTML layout page where the image is

to be displayed. The Image tag has no other parameters than Name,

which distinguishes one Image tag from another.



71

When using Iron SpeedDesigner, after binding theImage tag to a URL and

generating the application, theresulting page looks like this.

We can build on this example by adding a second Image tag.

<HTML>

<body> Thi s i s t he f i r st i mage: <br><GEN: I mage Name="Logo1" / ><br >

Thi s i s t he second i mage: <br><GEN: I mage Name="Logo2" / >

</ body>

</ HTML>

After binding twoImage tags to twodifferent URLs and

generating theapplication, theresulting page looks

like this.

In this example, name values distinguish one Image tag from the

other. This allows the application generator to create separate

components for each tag.



72

The process for hooking up the Image code generation tag to the

actual image, called “component binding”, is described later in this

document.

The use of display tags is also common in layout files. These are tags

that specify particular layout components. For example, to place a

standard button on a page, the web designer simply inserts:

<GEN: PUSHBUTTON Name=”Edi t Cust omer ”/ >

When binding this tag, the application generator prompts you for

the information necessary to connect the button to the appropriate

application function.

Now that you’ve been introduced to the notion of code generation

tags, and have seen how these tags are included in HTML files, it’s a

good time to explore how an application generator can use these tags

to link the HTML pages to the database.

Using the FieldValue Tag to Display Data

Probably the most commonly used code generation tag is the

FieldValue tag. The FieldValue tag tells the application generator to

write the code to fetch a field from a database record and display it

on a web page at the specified location. During the application

generation process, the application generator replaces the FieldValue

tag with a presentation layer control in the generated ASPX or ASCX

file.

A Stand

‐Alone

FieldValue

Tag

Example

The FieldValue tag can be inserted by itself, alone in a layout page,

or within a surrounding Record tag or Table tag. Below is a very

simple layout page that contains a stand‐alone FieldValue tag,

whose field name is “CompanyName”.

FieldValue tags may be used “stand alone” anywhere in your layout

pages. During the binding process, the application generator

prompts you for the particular database table, field, and selection

criteria necessary to fetch the appropriate data field from the

database.

The example below shows a single FieldValue tag placed in a layout

page.

<HTML>

<body>

<GEN: Fi el dVal ue Name=”CompanyName” / >

</ body>

</ HTML>



73

Like the Image tag, the FieldValue tag is placed anywhere in your

HTML layout page where you wish the data to be displayed.

The FieldValue tag is bound to a database table and field. After generatingthe application, the resulting page looks like this.

You may wonder how the generated application knew which record

to fetch and display. In the example above, we bound each of the

FieldValue tags to use a query string parameter passed in via the

page’s URL, e.g.:

ht t p: / / qa- net / Al an1/ MyPages/ I nvoi ce2. aspx?I D=ALFKI

In this case, Invoice2.aspx is the name of the ASPX page generated

by the application generator from a layout page named

Invoice2.html. ID is the query string parameter used to identify the

primary key of the record being retrieved from the database. This

name, “ID”, was arbitrarily chosen and there is nothing special about

“ID”. It equally well could have been “Key” or any other name.

“ALFKI” is the primary key value that uniquely identifies the record

we wish to display. Again, there is nothing special about this value;

it could have been any other primary key value in the Customer

table.

Later in the generation process, when you bind the layout file, the

application generator will ask you to select the particular database

table, field,

and

selection

criteria

necessary

to

fetch

the

appropriate

data field from the database.

Grouping FieldValue Tags with Record Tags

Typically, FieldValue tags are grouped within an enclosing Record

tag (as shown in the sample layout page below). The Record tag

groups together FieldValue tags that fetch and display data from the

same physical record. The Record tag provides a most convenient

way to optimize the generated code because a single SQL query is

generated for the Record and associated FieldValue tags. If there is

no enclosing Record tag, each FieldValue is generated as a separate

control with its own SQL query.

<HTML>

<body>




<t d><GEN: Fi el dVal ue Name="Addr ess" / ></ t d>

<t d><GEN: Fi el dVal ue Name="Ci t y"/ ></ t d>



74

<t d><GEN: Fi el dVal ue Name="Stat e"/ ></ t d>

<t d><GEN: Fi el dVal ue Name="ZI P"/ ></ t d>

<t d><GEN: Fi el dVal ue Name="Count r y"/ ></ t d>


</ GEN: Recor d>

</ body>

</ HTML>

More Complex Data Displays: Table Tags & Data Grids

FieldValue tags are often used inside of a surrounding Table tag.

The Table tag functions much like an enclosing Record tag in that it

groups together related tags for display within a data grid control.

The Table tag tells the application generator to create code that

iterates through the selected data result set, displaying the contents

of each successive row in the data grid.

<HTML>

<body><GEN: Tabl e Name="Cust omer ">

<t abl e> <! - - HTML t abl e t ag - - >

<t r >

<t d col span=100>

<B>Our Best Cust omer s</ B>

</ t d>

</ t r>

<GEN: I t emTempl at e>

<t r > <! - - Row i n a t abl e - - >

<t d><GEN: Fi el dVal ue Name="CompanyName"/ ></ t d>


<t d><GEN: Fi el dVal ue Name="Ci t y"/ ></ t d><t d><GEN: Fi el dVal ue Name="Stat e"/ ></ t d>

<t d><GEN: Fi el dVal ue Name="Zi pCode" / ></ t d>

<t d><GEN: Fi el dVal ue Name="Count r y"/ ></ t d>


</ t r>

</ GEN: I t emTempl at e>

</ t abl e>

</ GEN: Tabl e>

</ body>

</ HTML>



75

Linking Database Tables, Views and Queries to an Application

Now that we’ve described the mechanics of using code generation

tags to create place holders in for data‐ bound controls, let’s explore

how application generators specify which data is relevant to the

application.

Payment

Terms

Shipping

Methods

Shipping

Carriers

Customers Orders Suppliers

StatusOrder

Details Products

Users

Bank

Accoun ts

Credit

Cards

Main Tables“Lookup” Tables

Images, PDFs, etc.

File

Library

You start with your database tables, as represented by this simple database schema. Then, using IronSpeed Designer, you identify database tables to which the generated data-bound controls will be bound.This process, called “linking”, points Iron Speed Designer at the specific database table schemas, foreignkey relationships, and other parameters that it ultimately uses to generate the SQL statements and stored

procedures that are the bulk of the generated database layer.

The first step in this process involves telling the application

generator what database tables are relevant to the application. To



76

facilitate this configuration, developers using an application

generator will use a special set of features or wizard, to specify

exactly what database tables should be associated with the

application.

Using a wizard like this, developers can link any number of database

tables to the application from any number of databases. There is no

practical limit to the number of tables that can link to the application.

Armed with this information, the application generator then queries

the indicated databases and collects the schemas of the selected

tables as well as related foreign key relationships. The information is

used during the component binding and application generation

phases. The tool will use the table schemas of the linked tables in

order to generate appropriate SQL queries and database access code.

Similarly, foreign keys are used when generating multi‐table joins

and other similar SQL queries.

The user selects the database tables to be linked and Iron Speed Designer imports the table schemaand associated foreign key relationships with other tables.

Remember, an application generator is not a data modeling tool; it

cannot create or modify database tables (schema definitions) nor will

it graphically depict relationships between the various tables. For

many years now, database tools with this sort of functionality have

been available from a variety of vendors to assist with database

design and implementation. The application generator works in

conjunction with these database design tools to put web‐ based

applications into production.



77

The Component Binding Process

Once the database tables have been identified, “component binding”

which refers to the process where the application generator fuses

each individual data‐ bound control (represented by the code

generation

tags

in

layout

pages)

to

its

underlying

data

sources,

takes

place.

Individualcomponentson the page,representedby code

generationtags, arebound to theunderlyingdatabase

tables and fields. Thisallows IronSpeedDesigner to

generatespecific codeand SQLqueriescorrespondingto theunderlyingdatabase

tables.

Using a wizard within the application generator, you select a layout

page to bind. The application generator then scans the selected

layout page and presents a list containing each code generation tag

in the page. It then allows you to bind each tag to the appropriate

data source(s), select display styles, and set other parameters specific

to the tag’s type.

Based on

its

unique

purpose,

each

code

generation

tag

prompts

the

application generator to request relevant binding parameter

information from you. For example, an Image control (“Image” code

generation tag) is bound to the URL, file name or database field

containing the image to be displayed. Similarly, the Table control

(“Table” code generation tag) is bound to the underlying database

table or multi‐table join to be displayed, along with the layouts of the

header row, data rows, and footer rows.



78

For those tags associated with table fields and records, the

information collected includes “selection criteria.” The selection

criteria determine which records are selected from the database for

display or editing, and provide a built‐in filtering mechanism to

specify how much data to display within a Record or FieldValue

control.

This selection criteria forms the basis of the underlying SQL query’s

“WHERE” clause. Depending on the selection criteria you specify,

the result set can be as simple as a single record from a single

database table or as complex as multiple rows from a multi‐table join

(as shown in the following figures).

For each code generation tag found in the layout file, IronSpeed Designer determineswhat information it needsabout the component and

then asks you for thatinformation. In thisillustration, a FieldValue tagis bound to its data source.

In addition, Iron SpeedDesigner asks for information on how todisplay the data— both tospecify the exact table and

field as well as the style thatthe data should use on the

page.

During the binding process, the application generator does not

change layout files in any way.

Early in the development process, when it’s common to have

unbound components on layout pages, a good application generator

will still let you generate the application. In these cases, the tool will



79

insert placeholders to indicate where the unbound controls are to

appear.

From this simple example, you might conclude that data source

binding is an arduous process with an application generator.

Thankfully, modern application generators provide tools for binding

data sources in a variety of quick and easy ways.

The following pages explore a few such examples.

Sourcing From Parent’s Record or Current Row in a Table

For example, fields don’t have to be bound one at a time. Typically,

they’re bound in conjunction with records or tables. The selection

criteria of the control’s associated Record or Table tag are used.

This option allows you to select a database table and field based on

the enclosing Record tag bindings you previously specified. You do

not need to specify the source of the record repeatedly for each of the

field values contained in the record.

Selecting the data source as the parent tag’srecord allows a Record or Table tag toaggregate data retrieval for a collection of enclosed FieldValue tags.



80

In this example, thecustomer information issourced from a singlerecord in the Customerstable and displayed onthe web page. The

Record code generationtag is bound to theCustomers table. Theindividual FieldValuetags are set to sourcetheir data from “Selectrecord(s)”.

This is common for FieldValue tags enclosed within a surrounding

Record or Table tag where the objective is to display a related set of

fields coming from a single selected record. In this case, the Record

or Table tag specifies the record that is selected and the FieldValue

controls display the individual fields.









</ GEN: Recor d>

The record retrieved by the parent tag – a Record tag or Table tag – determines the datadisplayed for the enclosedFieldValue tags.

This option also applies to the FieldValue tag if it is enclosed within

a row of a table being displayed. This is meaningful in the context of

a FieldValue tag in a table, in which the ʺcurrent rowʺ in the table is

bound to a particular record. As the table iterates over each record

in the result set, each corresponding record is fetched and the

appropriate field values retrieved and displayed.



81

Adding a New Record to a Database Table

When binding the tag, use this Record tag option to create the code that addsa new record to the database.

Here, the field or group of fields enclosed by a Record tag is added

as a new record to the database. When you bind the tag in this

fashion, the application generator creates code that allows the user to

enter a new record into the database.


<t d><GEN: Fi el dVal ue Name="Fi r st Name"/ ></ t

<t d><GEN: Fi el dVal ue Name="Last Name"/ ></ t d






</ GEN: Recor d>

NOTE: Code generation tags areused to both display data as well asinput data, depending on their component bindings. Either way,there is no difference in how the code

generation tags are used in your layout page.

In this example, the name, address,and other contact information iscollected from the web page andinserted into the Customers table inthe database. The Record code

generation tag is bound to theCustomers table. The individualFieldValue tags would have their data sources bound to “Add newrecord” as shown above.



82

The Application Generation Process

When you press the “generate” button in an application generator,

the entire three‐tier architecture, with all of the code necessary for

each layer, is generated at once. The tool generates your

application’s ASCX,

ASPX,

C#,

SQL,

and

Visual

Basic

files.

The following figure provides a visual diagram that represents the

varieties of code and files that are generated in each layer of the

application.

Since there are three inputs into the application generator (layout

pages, database table schemas, and component bindings), you might

assume there’s a one‐to‐one correspondence with the layers in the

application. This is not the case. Several inputs affect multiple

layers. For example:

While the layout files are transferred nearly verbatim into

ASPX files, each code generation tag is replaced with an

appropriate ASP.NET component.

Component binding information is used to specify those

ASP.NET controls in the presentation layer. Additionally,

it’s used to specify application layer logic, such as the data

validation code.

Table binding information is used to generate Visual Basic

code in the application layer (such as the database access

classes

and

the

data

validation

code),

as

well

as

the

SQL

queries in the database layer.



83

The relationshipbetween theapplication

generationinputs and theapplication

layers.

When using an application generator, you can inspect all of the

generated source code from within the tool, through the file system,

or from within your favorite IDE. You have complete, unrestricted

access to one hundred percent of the generated source code, and

there are no special server software requirements for any generated

application.

Presentation Layer Generation

During the application generation phase, the layout files are used as

the basis for all ASPX pages and ASCX controls. The application

generator passes through all of the HTML, DHTML, and client‐side

scripting languages when generating the ASPX pages. However,

when a code generation tag is encountered, the application generator

replaces it with the corresponding data‐ bound control.

The application generator generates user controls that inherit from

the base classes of the target platform. When using Iron Speed

Designer, for example, this is the Microsoft .NET standard

UserControl class, and its application generation process also creates

Visual Basic code‐ behind classes for the ASPX pages and ASCX

controls. (You can easily extend or customize these controls by

writing Visual Basic code in the code‐ behind classes for the page and

controls.)

In many cases, an application generator will actually generate more

than one user control for each code generation tag. These additional



84

controls are typically validator controls that enable server‐side

validation of the data entered by the application user.

Application Layer Generation

The application generator also creates a set of classes that handle

issues such as page management, database access, security, and data

validation. Many of the generated classes inherit behavior from

.NET framework classes, which provide advanced user interface

controls and server management.

Inside the files, the application generator creates a class hierarchy

that is granular and predictable. For example, Iron Speed Designer

creates two classes for each web page, named <page_name> and

<page_name>Gen. That is, a web page named ViewProducts has

two classes associated with it, ViewProducts and ViewProductsGen.

The <page_name>Gen classes are regenerated each time you

regenerate the application. The <page name> classes are generated

only once and called “safe classes.” These can be modified to

contain customized code that will not be overwritten when the

application is regenerated.

System.Web.Ui.Page

BasePage

ViewProductsGen

ViewProducts

(.NET Class)

(Iron Speed Base Class)

(Generated Application Class)

(Safe Class)

Iron Speed Designer creates a predictable set of classes for all UI controls. The

generated classes are replacedeach time you regenerate your application; however, the Safeclasses are only generatedonce. As a result, the Safeclasses can containcustomized extensions to your application.

The application generator creates classes for all objects including

pages, tables, records, fields, buttons, menus, and so on.

Although an application generator creates a running application

when it generates code, no one can expect an uncustomized,

automatically generated application to have the exact look‐and‐feel

or functionality that is desired for a production application.

Developers commonly make several types of code extensions to

these generated applications, including:

Adding specialized customer data validation routines

Adding custom calculated field values using data from the

database



85

Integrating with other application programs

Incorporating special‐purpose or third‐party components

Integrating with web services or other application API’s.

Generated applications are specifically designed to support code

modifications, so you can regenerate an application, repeatedly,

without re‐integrating your code extensions.

Database Layer Generation

Generated applications are typically configured with a “page‐ based”

transaction model. This means that changes made to any underlying

database table on the current web page are not stored until the user

clicks “OK” (or takes a similar action on the page). As a result of the

action, all changes are committed to the database as part of a single

transaction.

Iron Speed

Designer

‐generated

applications

use

the

transaction classes in ADO.NET to perform commits and rollbacks.

An application generator automatically generates all of the SQL

statements required for each database‐connected form, web page,

table, and report in the application, as well as all of the database

access logic and storage management code. It generates the SQL

statements based on the information collected during the database

and component binding processes, so you do not always need to

know SQL to build powerful applications with an application

generator.

Some application generators place most of the generated SQL in

stored procedures, enhancing run‐time performance because the

queries are stored and executed directly from the database. This

prudent approach minimizes the number of round trips between the

application program and the database, and further enhances overall

application performance.

Specifically, when using Iron Speed Designer, all database table

view, record view, record insertion, record update, and record

deletion SQL queries are placed in stored procedures.

Bonus Automation

(Even

More

Code

You

Don’t

Have

To

Write)

In addition to writing the code for each layer of the application, a

good application generator will also “throw in” a number of features

and capabilities that every application should have. Often, these

features are cut by development teams who are short on time and

resources, and rushing to get a basic application into production.



86

An application generator will help you deliver these capabilities as

standard features of every application you create. As such, the

overall quality of the applications you build will increase, and your

backlog of enhancement requests will be reduced.

Sample application generated with Iron Speed Designer with many bonus features.

Let’s explore a few of these extras, and see how application

generators add extraordinary robustness and completeness to even

the simplest application.

Search Tools

Because of the ubiquity of the web, users of all skill levels have

grown accustomed to using text search facilities in many web

applications, and as a navigational aid on the web itself. As a result,

expectations about search facilities spill over to all kinds of web

applications, and that includes the ones you’re building.

While basic text search technology is well understood, and

straightforward to

implement,

many

applications

never

include

it

because of the time and energy that’s required to implement, test,

and maintain the functionality.

When using an application generator, search facilities are included

with the application by default. As such, you can deliver basic

search features as part of the application you’re creating with no

additional work.



87

Data Sorting & Page Navigation

As with search facilities, experience with commercial web sites has

raised user expectations about data sorting features. When

presented with multiple pages of tabular data, users now expect to

be

able

to

sort

the

data

by

clicking

on

the

headings

of

the

table

that’s

presented. They also expect to be able to specify how many records

should be displayed on a per page basis, and then page through the

data, on a page by page basis.

The software technology needed to deliver these sorting and

navigation features is straightforward to implement, but it takes time

and effort to get it right. While such facilities are integral to all data‐

intensive web applications, the code to implement these features is

tedious and time‐consuming to write, test, and maintain.

When using an application generator, data sorting and page

navigation facilities are included with the application by default. As

such, you can deliver these basic features as part of the application

you’re creating with no additional work.

Import & Export Facilities

Just about every application involves data that some user will want

to export from, or import into, the database. Here again, many

commercial web applications deliver these features for the user with

the click of a button. As such, user expectations have risen, without

a full appreciation of the technology that’s needed to deliver these

capabilities.

Implementing data import and export facilities within web‐ based

business applications can dramatically reduce the backlog of service

requests that are typically handled by the DBA. Once available,

these import/export facilities can eliminate an entire class of IT

support trouble tickets by enabling users to self‐service these

requests.

But implementing reliable import and export features can be tricky

to implement, and getting it wrong can be disastrous. As such,

many applications are deployed without these features, and IT

support staffs continue to be burdened with these requests.

Here again, when using an application generator, import/export

facilities can be included with the application by default. As such,

you can deliver basic import/export features as part of the

application you’re creating with no additional work.



88

Exception and Error Management

One of the most neglected features, and yet one of the most useful to

end users, is high quality exception handling and error management.

When users make or perceive errors, the experience they have

coping

with

the

problem

forms

the

most

permanent

impression

of

the program. In extreme cases, poor error and exception handling

can lead to the user abandoning the application altogether.

Application generators can largely alleviate this risk, if not eliminate

it entirely. For each application they create, they anticipate several

different types of errors that can occur at run time. The following

few pages describe a few different kinds of potential errors, and how

a generated application should handle each type of error.

User Input Validation Errors

As trite as it may sound, the truth is that the large majority of problems a software application will encounter will result from user

error. Simple things like typos, entering data in the wrong field, or

skipping a required field, should result in the generated application

displaying an error message to the user.

To ensure it’s not missed by the end user, the error message should

be displayed in a pop‐up dialog box or in‐line immediately at the

time of the error and provide the user with an opportunity to correct

the error.

A good application generator will automatically generate input field

validation code for all supported field types. This thoroughly tested

validation code will notify the user of input errors directly on the

web page, and give the user a chance to correct the errors and

resubmit the entry.

Internal Errors

Internal errors are caused by incorrect system configuration, or

because a required resource has become unavailable. These required

resources can include a network connection, a web server, a database

server, etc.

For these kinds of errors, the generated application should display

an error message on a web page for the application user, and explain

the reason for the error. Additionally, the generated application

should log these errors to the server’s event log. Logging these

events will enable them to be viewed through the Event Viewer by

the system administrator, and hopefully, help identify the problem,

and accelerate its resolution.



89

Database Exception Errors

Database errors occur when the SQL statements executed are invalid

or when the database is not connected. These types of errors are

largely avoided when the code is created with an application

generator. Such tools should always create syntactically correct SQL

queries, but sometimes, these queries can break when data sources

are reorganized, when needed tables are archived, etc.

Here again, the generated application should generate an error

message for the end user, and provide as much information as

possible about the nature of the problem. As with internal errors

noted previously, serious errors should also be logged to the server’s

operating system event log so they can be viewed through the Event

Viewer by the system administrator.

Application Logic Errors

Application logic errors occur when the software application itself

has a bug. Typically, application generators automatically create

code that features correct, highly reliable, application logic.

However, errors can be introduced when you extend or change the

generated code.

Even in these cases, the generated application should include

unhandled errors. When they are within a page, they can ensure the

errors are noted in the event log so they can be viewed via the Event

Viewer.

Summary

In this chapter, we’ve introduced how the most fundamental

capabilities of a modern application generator operate. We’ve seen

how you can direct the application generator to create the basic

components of your application, and also round out many standard

features that are often overlooked.

In the next chapter, we’ll focus on the data layer of the generated

application, and explore how database‐related functionality is

created with application generation tools.



90

Part 6)

Automatic SQL Generation for

Database‐Connected Controls

How Application Generation Delivers Data‐

Driven Web Applications with

Speed & Reliability





92

especially true in the state‐less environment of the web, where

maintaining transaction state between pages is difficult.

Application generators should approach SQL generation from an

efficiency perspective. For example, they should place queries for

multi‐table joins in a single query to reduce round trips to the

database. And they should take into account fields that are indexed,

and possibly go so far as to suggesting fields that should be indexed

in order to improve performance. They should also give you the

choice of placing your SQL directly in the application layer or in

stored procedures.

Technology that generates SQL

statements must be tied

specifically to your database

schema. Generic queries

(queries composed on‐the‐fly

that do not use parameterized

field values) can slow down

application performance since

they often require several round

trips to the database to

complete. Specific queries that

include the names of field

values save trips because they

use the actual field names from

your database. This is how you

would write the statements by

hand, and

this

is

what

you

should expect from a quality application generator.

Transaction Model & Transaction Management

In web‐ based applications, itʹs particularly difficult to accumulate

transaction information across multiple pages, moving from one

page to another, because of the stateless nature of the web. This

makes it important to understand what constitutes a transaction and

when it should be committed to the database. For example, a typical

web‐ based order check out process, such as a shopping cart, collects

different aspects of the order in a series of pages, such as the

customer’s name and address, credit card information, and shipping

instructions.

The difficulty is that there are few options for storing information

collected on those pages other than in the database, in the .NET

cache, or in browser cookies. While each approach has trade‐offs, an

application generator can free you from the burden of implementing

these schemes.



93

Unfortunately, storing a user’s transaction information in browser

cookies poses security and bandwidth issues. So, for most

applications, storing transaction information in the database is the

best option. This makes it important to understand what constitutes

a transaction and when it is committed to the database.

Modern generated web applications are created with a “page‐ based”

transaction model. This means that all of the changes made to any

record or table on the current web page are submitted when the user

clicks “OK” or takes a similar action on the page. This “OK”

commits to the database as part of a single transaction. Specifically,

Iron Speed Designer applications use the transaction classes in

ADO.NET to perform commits and rollbacks.

This order form illustrateshow data can be pulled from(or inserted into) multipledatabase tables into one page

in a parent-child relationship.When “Save” is clicked,records are inserted intoseveral tables, including theOrder, Order Details, andCustomer tables. In

particular, multiple recordsare inserted into the Order Details table, one record for each line item. The entiretransaction is concluded witha single commit.

Application generators use stored procedures to update the database

when appropriate and directed by the developer. If there are

multiple related records being added or updated as part of a single

transaction (e.g., Orders with multiple Order Items), then each

record is updated individually, and requires multiple round‐trips to

the database. The record insertions, updates, and deletions themselves are performed within database stored procedures, but

the application logic calling these stored procedures resides in the

generated Visual Basic .NET code.

In a multi‐part transaction, the entire transaction is concluded with a

single COMMIT statement at the end of the transaction. While these

many‐to‐many updates do require multiple trips to the database,



94

they are committed to the database by a single COMMIT at the end

of the transaction.

Location of the SQL Statements

In any

database

application,

there

is

a fundamental

decision

as

to

whether to place the SQL statements in the application layer or in the

database layer. As you might expect, there are advantages and

disadvantages to both.

Because application generators write all the SQL statements,

developers can often choose where they want the SQL generated

strictly based on performance and system architecture criteria, and

without regard to in‐house expertise constraints. There is generally

no requirement that the developer learn SQL or proprietary stored

procedure languages, such as PL/SQL (Oracleʹs Stored Procedure

Language) or Transact‐SQL (Microsoftʹs SQL Server Language).

In‐line (Embedded) SQL

If SQL statements are placed in the application layer, they are

embedded in the application’s source code. In this style, the burden

of writing and maintaining the SQL typically falls to the application

developers because they are the ones writing the application source

code. In this case, the developer of the code writes and inserts the

SQL statements at the appropriate places. This approach affords

developers the opportunity to tightly integrate the SQL and the

query results within their source code. As such, it also requires

application developers to be experts in two languages – their primary development language – C#, Visual Basic, or Java – as well

as SQL. This is oftentimes difficult for developers.

There are also, of course, good reasons to place SQL queries directly

in the database such as matching the style of existing legacy

applications, database constraints, and DBA preference.

Stored Procedures Enhance Performance & Maintainability

If SQL statements are placed in the database layer, they reside in the

database as stored procedures. This approach not only moves the

SQL to a different layer in an n‐tier architecture, but in most cases

moves it to a physically separate server machine. In this style, the

burden of writing and maintaining the SQL typically falls to the

database administrator (DBA) or an individual developer whose

primary skill and expertise is writing SQL. In this scenario,

developers rely on the DBA to implement part of their application

(the SQL) and interface their code with the stored procedures created

by the DBA.



95

Centralizing the SQL in the database layer allows for a certain

amount of application logic to be maintained in a central location

and shared across multiple application programs. Moreover, many

developers and DBA consider implementing queries in stored

procedures as a “best practice.” Consolidating most or all of an

application’s SQL in stored procedures makes it easier to review,

modify and tune individual queries without having to dig into

application code.

Finally there is the issue of execution performance. Generally, more

complex SQL statements can be placed in stored procedures. When

executed locally on the database server, this technique often reduces

the number of round‐trips between the application program and the

database. Efficiency is also improved because the queries can be pre‐

parsed, potentially saving parsing time if the query is dynamic.

While bandwidth and latency don’t always present problems for

many behind‐the‐firewall applications, they can present a problem

in web services environments where the application programs aren’t physically nearby the database executing the queries.

Generating Stored Procedures

A good application generator will automatically generate all the SQL

statements required for each database‐connected form, web page,

table, and report in your application, as well as all the database

access logic and storage management code. Because this generated

SQL is based on your data model and user interface design, you do

not need to know any SQL to build applications with an application

generator.

Further, the

application

generator

often

provides

a

variety of data filters and navigation components to provide your

end‐users with additional viewing and reporting flexibility.

From our perspective, the application generator should place most of

the generated SQL in stored procedures to enhance run‐time

performance (because the queries are stored and executed directly

from the database). Enhancing performance further, this approach

minimizes the number of round‐trips between the application

program and the database.

All the database table view, record view, record insertion, record

update and record deletion SQL queries should be placed in stored

procedures. Table join queries, however, are placed in generated

Visual Basic .NET functions.

Transact-SQLStored Procedures Purpose

Add Insert a single record in the table.



96

Transact-SQLStored Procedures Purpose

Delete Delete a single record from the table.

DeleteRecords Delete a set of records based on search criteria.

DrillDown Get a list of distinct column values based on search criteria.

Export Export records from the table based on search criteria.

Get Get a single record from the table.

GetList Get a list of records based on search criteria.

GetStats Get summarized or calculated information from a table basedon search criteria. Several possibilities including countingrecords, summing or averaging values.

Update Update a single record in the table.

Iron Speed Designer generates these database stored procedures, one set for each table anddatabase view. The stored procedures for creating, updating, and deleting records accept fieldvalues as parameters, such as record ID's and filter strings, and then execute the appropriateINSERT, UPDATE, or DELETE statements in the stored procedures.

Database Views Provide Data Consolidation

A database view is simply a subset of the database sorted and

displayed in a particular way. A database view limits the records

displayed and could contain a subset of records, such as “products

that are in stock,” or “customers that have purchased goods greater

than $1000.” A view could also contain a subset of the information

for each item, such as “product name, description, and price,” but

not the dimensions of the product. Similarly, the order of the

columns is specified in the database view. Some applications use

database views or stored procedures to embed security in the

database so that the application cannot compromise security

regardless the query used.

Because database views are an integral part of your underlying

database structure, it’s important that your generated application

embrace them. Many organizations use database views as a way of

consolidating data for reporting and other uses where a common

“definition” is required.

Applications generated by Iron Speed Designer, for example, fully

support database views. For each view, you can control which

columns are displayed, what order they are displayed in, how wide

each column is, how the data is sorted, and what types of records to

display. In general, you can perform any operation on a database

view in Iron Speed Designer that you can on any table. To protect



97

the integrity of the database, you cannot input data directly into a

database view. This must be performed in the underlying tables

from which the database view is derived.

A screen shot from IronSpeed Designer

showing a combinationof tables and databaseviews included in anapplication.

Primary Key Relationships Permit Record Editing

Primary keys in database tables indicate which fields are used to

uniquely identify each record. For example, a Customer table

generally has a CustomerID primary key field that contains a unique

customer ID value for each individual customer. In order to

generate code that can update or delete an individual record, the

application generator must know which field(s) to use as the

primary key for selecting and accessing individual records.

Frequently, a table will use several fields together to form a primary

key. These are called composite primary keys. For example, a

Customer table may use the combination of a phone number field

and last name field to uniquely identify a customer record.

The application generator determines composite key relationships by

querying the system information in the connected database(s). If

multiple rows are returned for a given table, it means that the table



98

has a composite primary key, i.e. a primary key consisting of

multiple fields.

An application generator should also support database tables

without primary keys. In general, you should be able to perform

any operation on a table lacking a primary key with the exception

that individual records cannot be selected for update or deletion.

An example web page generated by Iron Speed Designer. The generated application uses primary keyrelationships to retrieve the appropriate Order table record for editing. The application uses foreign keyrelationships to retrieve the associated Customer table records for editing.

Foreign Key Relationships Permit Multi‐Table Joins

Foreign key relationships in a database specify how one table is

related to another table. For example, an Order table may have a

Customer ID field that is a foreign key to the Customer table. The

Order ID field indicates which Customer record is associated with

the particular order.



99

Foreign keys can also indicate one‐to‐many relationships between

tables. For example, an Order table may have a related Order Detail

table containing multiple line items for each individual order. The

Order Detail table has an Order ID field that is a foreign key to the

Order table.

For example, Iron Speed Designer uses foreign key relationships to

construct multi‐table joins in SQL. In the example shown above, the

generated application is able to display Customer and Order Detail

information within a single Order page, by automatically generating

the table joins in SQL.

A good

application

generator

determines

foreign

key

relationships

by querying the system information in the connected database(s). If

multiple rows are returned for a given foreign key name, it means

that the foreign key name is a composite foreign key, i.e., multiple

foreign key fields referencing a table with a composite primary key.

Specifically, Iron Speed Designer supports two types of foreign key

relationships:

Explicit foreign keys. If linked databases contain explicit foreign

key relationships, Iron Speed Designer automatically uses them

when generating your applicationʹs SQL.

Virtual foreign keys. You can also inform Iron Speed Designer of

implicit foreign key relationships between your database tables that

may not be defined in the database. Iron Speed Designer does the

rest, generating appropriate application logic and SQL queries.

Iron Speed Designer does not differentiate between virtual and

explicit (real) foreign keys when it generates the underlying database

Iron Speed Designer uses foreign key relationships specified in your database to generate complex pageswith multi-table joins like this one.



100

access logic and SQL query statements. For example, virtual foreign

keys are usable for one‐to‐one and one‐to‐many relationships and

allow editing of multiple related records from either a single or

multiple tables.

Foreign key fields are shown in the “Databases” section of Iron

Speed Designer. For example, an Orders table may have a

“CustomerID” field that is a foreign key to the

“Customers.CustomerID” field. (If the table has multiple fields

referencing the same primary table, then the foreign table has a

composite foreign key.)

Concurrency Control / Concurrency Handling

In any multi‐user environment, concurrency becomes an issue when

two users update the same record in the database, one after the

other. If both users are viewing the same record, and then make

independent changes, how the application handles concurrency

determines which user’s changes update the data in the record. The

way your application handles concurrency affects the ability of your

application to handle simultaneous transactions against the same

records.



101

Optimistic concurrency handling ensures that a second user does not unintentionally overwrite the

changes made by a first user.

In some applications, the second user to update a record will

overwrite the changes made by the first. In others, the application

will warn the second user that the record they are viewing has just

been updated. In still others, the second userʹs view is automatically

updated when the first user updates the record.

In traditional application development, the developer has to hand‐

code concurrency handling into the application layer. This can be

tricky code to write, and it has to be written for each transaction in

your application. Unfortunately, doing it right doesnʹt earn you any

special recognition whereas mistakes can have you hunting bugs for days.

Implementing concurrency handling is typically very tedious and

must be applied carefully to nearly every transaction in an

application. Application generators create this concurrency

management code for you, saving hours of hand‐coding headaches.



102

There are two commonly used concurrency detection and handling

mechanisms: optimistic concurrency control and pessimistic

concurrency control. Iron Speed Designer, for example, generates

optimistic concurrency handling code for each of your transactions

so users cannot unintentionally overwrite each otherʹs changes.

Pessimistic Concurrency

Pessimistic, or negative, concurrency control is when a record is

locked at the time the user begins his or her edit process. In this

concurrency mode, the record remains locked for the duration of the

edit. The primary advantage is that no other user is able to get a lock

on the record for updating, effectively informing any requesting user

that they cannot update the record because it is in use by someone

else.

There are several drawbacks to pessimistic concurrency control. If

the user goes for a coffee break, the record remains locked, denying

anyone else the ability to update the record, even if it has been

untouched by the initial requestor. Also, in order to maintain record

locks, a persistent connection to the database server is required.

Since web applications can have hundreds or thousands of

simultaneous users, a persistent connection to the database cannot be

maintained without having tremendous resources on the database

server. Moreover, some database tools are licensed based on the

number of concurrent connections. As such, applications that use

pessimistic concurrency would require additional licenses for use.

Because of this drawback, almost all applications use optimistic

concurrency control.

Optimistic Concurrency

With optimistic, or positive, concurrency, the record is not locked

during the edit phase. Instead, the record is locked for a split second

just before the new changes are committed to the database and

immediately unlocked after the changes have been made. Optimistic

concurrency is generally used in environments with a low contention

for data, such as web applications, where there are minimal chances

of two users needing to update a record in close proximity to each

other.

Of course, with optimistic concurrency handling, it becomes

incumbent upon every requestor to check if the record has been

updated before they commit any changes. There are several

techniques for testing for an optimistic concurrency violation. One

involves including a timestamp column in the table. In a test for

optimistic concurrency violations, the Update Date and Time are

compared with the original value returned when the edit began. If



103

they are the same, the new changes are committed to the database. If

the Update Date and Time have changed, because another user may

have updated the record, the second user to have completed the

editing receives an error.

Concurrency

Handling

in

Generated

Applications

Iron Speed Designer also implements optimistic concurrency

handling in generated applications. Specifically, Iron Speed

Designer calculates a checksum for each record. If the checksum is

different when the application prepares to update a record, then the

application assumes the record was changed by another user. A

warning message is displayed on the application page alerting the

second user.

Cursor Management

A database cursor is the resulting set of records returned by an SQL

query. The cursor allows you to request each record in sequence so

that the query results may be displayed in a data grid, report or

otherwise operated upon.

Cursor managementallows eachrecord to berequested insequence

anddisplayed ina data gridor report.

For example, as an application user moves from page to page in an

on‐screen report, the subsequent pageʹs data is retrieved from the

cursor and displayed. Itʹs also commonplace for applications to



104

iterate over the result set, performing some calculation or other

update to each of the records in the result set. (Later, we’ll discuss

cursor management in great detail.)

Data Recency

One issue that emerges with cursors is the freshness of the data in

the result set. As long as the cursor is in use, it contains the set of

records retrieved when the query was originally performed.

However, this data may grow stale over time, especially if the query

result is being displayed in a screen that an application user is

reviewing over a period of time—minutes or hours. The application

user is viewing the result set that was current when the report was

first created.

In applications where the underlying data changes frequently, it may

be desirable to rerun the SQL query as the application user moves

from page to page in their report. This ensures that each displayed

page has the most current data. While this also places an extra load

on the database because it must rerun the query more frequently, all

modern relational databases have very good data cache management

that significantly reduces the cost of frequently rerunning queries.

Data Management

A second issue to consider is whether the entire result set is pulled

from the database into the application layer, a well‐known problem

with .NET data grids. When a result set contains only a few

hundred records,

moving

all

of

the

data

into

the

application

program

requires minimal bandwidth and memory to store and manipulate

the result set in the application. When the result set has hundreds of

thousands or millions of records, however, it becomes nearly

impossible to efficiently move all of that data into the application

program. Very few application programs are structured to

manipulate that quantity of data in memory without additional file

management logic, which defeats the purpose of using the

underlying database which provides exactly these facilities. So, in

applications where the result sets can be large, itʹs best for

applications to retrieve only a manageable subset of the result set

from a cursor—such as one page of data—operate on that data, and

then request the next subset.

Database Cursors in Generated Applications

In keeping with this philosophy, applications generated should use

database cursors to retrieve data from the database. The cursor

should be used to retrieve the number of records being displayed on

the database table view web pages. Only one page of data should be





106

Since there are so many things to consider when building any web‐

based application – everything from security to code extensions — it

is wise to off‐load the routine programming to application generator

tools, especially if you can be confident of no drop in code quality.

Such tools will save you a lot of time by generating fully functional

applications in a fraction of the time of traditional hand coding.

Moreover, they generate applications that have far fewer bugs and

require far less testing than hand‐coded applications.





108

This seemingly

straightforward

“Edit Order”

page can

create

code havoc

when you have

to add

enterprise‐class

security,

concurrency

and transaction

management

code by hand.

Generating Role‐Based Application Security

Most applications serve a variety of constituents – customers,

customer service, marketing, sales, and management, to name a few.

It’s increasingly common in contemporary web applications to

permit much broader access to applications and their underlying

data than was common with client server applications, which had

more restricted user bases. With broader use comes an increased

need to partition data according to the user type – and sometimes

down to the individual user as well.

One of the most convenient security mechanisms is role‐ based

security because it allows individual users to be assigned into roles,

and then access is granted at the role level. This makes for

convenient administration because most applications need just a

handful of roles – 5 or 10 at most – but may have thousands of users.



109

Broadly speaking, application generators should support at least

three types of role‐ based security:

1. Simple sign‐in authentication. Application users must sign

into the application. Only users with user names and

passwords can sign in, giving you control over who can

access your application.

2. Single role authentication. Application users must have a

designated role in order to access a particular web page.

Individual web pages are configured so that only those users

with the designated role can access the page.

Multiple role authentication. Individual web pages are

configured to accept users who have one of several

designated roles. For example, a customer service

supervisor might have one role as a “service rep” with

access to customer account information, and a second role as “manager” with authorization to issue refunds or credits.

Simple Sign‐in Authentication

Simple sign‐in authentication distinguishes between users who are

signed in and those are not. Users who are not signed in are called

anonymous users. Because of the flexibility the role‐ based security

model, you can grant access to individual pages to either signed in

or anonymous users, or to both signed in and anonymous users.

This is very useful when you want your application to present one

view

of

your

data

to

a

signed

in

user

and

a

different

view,

perhaps

more limited, to users that haven’t signed in or don’t have an

account (anonymous users).

Simple sign-in authenticationdistinguishes between users who aresigned-in and those who are not(anonymous users).



110

All that is needed to configure sign‐in authentication is a single

database table containing your application users’ basic user name

and password information.

Single Role Authentication

Single role authentication distinguishes between various groups of

users based on their assigned role. Individual application pages can

be configured to permit access to users who have the required role.

In the single role authentication model, individual application users

have only one role assigned to them. However, the application

pages can be configured to permit access to multiple roles, for

example, sales and marketing.

Single role authenticationdistinguishes betweendifferent classes of usersbased on their assigned role.

Each user has one role assigned to them. This role assignment is in

the same database table as the user name and password information

required for simple sign‐in authentication.

Single role securityrequires just a singledatabase table withbasic user name and

password information.

Multiple Role Authentication

In more sophisticated role‐ based security systems, users can be

assigned multiple roles, effectively giving them broader access than

would be granted by a single role. A simple example is that every

customer service representative may not be authorized to access

customer credit card data. In this example, the customer service

supervisor has one role as a ʺrepʺ with access to customer account



111

information, and a second role as ʺmanagerʺ with authorization to

issue refunds or credits. Ideally, those roles are accessible

simultaneously without requiring the user to log in under a second

role.

Multiple-role authentication

distinguishes between differentclasses of users based on their assigned role. Individualapplication users can havemultiple roles assigned to them,and individual web pages can beconfigured to permit access bymultiple roles.

Multiple role security requires linking several database tables with basic user name and password information.

Securing Your Generated Web Application

So far, we’ve introduced the basic approaches to role‐ based security,

and discussed, at a high level, some of the circumstances that might

lead you to choose one approach or another. Now let’s take a



112

specific look at how application generators assist you in completing

this work.

Courteous application generators will automatically add end‐user

authentication (sign‐in) access control as a standard feature to your

generated applications. With such a tool, you should be able to

assign any number of roles and give access to any number of roles to

each user, and create a sign‐in feature based on your own user table

in your database. Using such facilities within application generators,

you can quickly secure individual pages to specific roles.

Specifically, the application generator should support:

Separate tables for Users, User Roles, and Roles. You can

have a one, two, or three table user roles configuration.

A variety of data types for these tables so you are not

required to

change

your

schema

to

use

role

‐ based

security.

Page access restriction, menu hiding, and button hiding.

Using email to send password reminders for lost passwords.

With such a tool, securing web pages should boil down to an easy

four‐step process:

1. Create user account information in your database.

2. Create a set of user roles.

3. Identify the location of user information in your database.

4. Configure your web pages for role‐ based security.

Now let’s explore each of these steps in detail.

Creating User Accounts

Role‐ based security is predicated on your application’s ability to

know who the user is so that appropriate page access can be granted.

This requires users to log into the application, which in turn requires

your database to contain user name and password information for users.

If you are implementing role‐ based security, your application

generator will require one table in your database to be designated as

a “Users Table”. The Users Table contains a list of all of your

application’s users and can be any table in your application. Within

this table, you must have three important fields for the application



113

generator to use when building the sign in mechanism in your

application: UserID , UserName , and Password.

Any table in your database can be a Users Table; there should be no

restriction on which table may be designated as a Users Table or

what other fields it may have other than those listed above.

Field Type

UserID Integer

…

FirstName String

LastName String

UserName String

Password String

Address String

…

An example table designatedas a Users Table. This tablecontains normal accountinformation, including FirstName, Last Name, and

Address, as well as therequired sign in information(shown highlighted).

Creating User Roles

Role‐ based security requires users to belong to different roles. Based

on the roles assigned to individual users, they are granted access to

specific pages that permit access for those roles. Your database will

need a table that identifies the role(s) assigned to each user.

A good application generator will support two different styles of

user‐assigned roles:

User has only one assigned role. Each user has one and only

one role assigned to him. The role assignment can be placed

either in

the

Users

Table

(see

previous

chapter)

or

in

a

separate User Roles Table.

User has multiple assigned roles. Each user can have zero or

more roles assigned to him. The role assignments are in a

separate User Roles Table, effectively creating a one‐to‐many

relationship between each individual user in the Users Table

and multiple corresponding entries in the Roles table.

If you are implementing role‐ based security, the application

generator will require one table in your database to be designated as

a “User Roles Table”. The Users Role Table contains a list of your

application’s users and their respective roles. The User Roles Table

can be any table in your application, including the User Table.

Within this table, you must have two important fields from which

the application generator builds the role‐ based mechanism in your

application: UserIDField and RoleIDField.



114

Placing Role Information in Your Users Table

In situations where an individual user has only one assigned role,

the role assignment is usually maintained in the Users Table directly,

although there is no requirement that this information be in the

Users Table.

Field Type

UserID Integer

FirstName String

LastName String

UserName String

Password String

RoleID String

Address String

…

A Users Table with a role assignment for each user. This configuration permits only one role per individualuser.

This example shows the tabledesignated as your application’s UsersTable containing the sign ininformation (UserID, UserName, andPassword), as well as the assigned role(RoleID).

Configuring Your Web Pages for Role‐Based Security

Once you’ve specified your users, and assigned the appropriate roles

to those users, you’ll need to specify which users get access to which

pages. The application generator you use should make that process

easy. The tool should offer standard defaults, as well as quick access

to your specific roles. Using the tool, you should be able to quickly

specify which roles have access to every page in your application.

Each web pageyou wish tosecure should

be configuredto accept onlythose userswith theappropriateroles. Here isa screen fromIron SpeedDesigner where these

permissionsare set.

Configuring Sign‐In Pages for Your Application

The Sign In and Sign Out pages interface with the role‐ based security

system, and permit your users to log in and log out of your

application.



115

An example SignIn pageautomatically

generated by IronSpeed Designer as

part of its role-

based securityimplementation.

Signing outof anapplication.

Signing Into Your Application & Managing Lost Passwords

An application generator can automatically generate a default sign‐

in page for your application. Of course, you can modify or replace

the page that’s provided. Here’s an example of such a default sign‐

in page:



116

Additional Security Issues to Address

In addition to the major security‐oriented features noted above, an

application generator can save you time by handling a myriad of

other security issues.

Automatic Sign‐out

For example, many developers consider it a best practice to have the

applications they create automatically log out application users after

a period of inactivity. This feature guards against identity theft that

can occur when a user leaves their web browser open to an

application, and an unauthorized person uses that browser to extract

identity information or perform transactions in the application.

After a period of inactivity, say 30 minutes, the application user

should be prompted to sign in again to reaffirm their identity. Of

course, the application generator should make it easy to change the

amount of time.

<sessi onSt ate

. . .

Ti meout =”30”

/ >

When using Iron Speed Designer,the time out interval is set in theweb.config file of the generatedapplication, as shown here.

Data Transmission Encryption

Eventually, most web‐ based applications typically use the public

internet for remote access, or for access by customers or suppliers.

As a result, your application should encrypt information that’s

transferred between your database and the user’s browser.

Today’s modern web servers offer built‐in SSL (secure socket layer)

encryption. This standard security ensures that no one can see your

data as it passes over the public internet or over your private

intranet and local area networks (without an extraordinary amount

of effort).

The application generator you use should create the application so

that it uses encryption by default.

Implied Security from an N‐Tier Architecture

In addition to employing data encryption with SSL, generated

applications can garner an additional level of security by employing

an n‐tier architecture. In such a set up, the data collected from an

application user is passed through the web server, to the generated

application, and then to the database. This n‐tier architecture of the

generated application ensures that your database is not connected



117

directly to the application user, and risks associated with a direct

connection are mitigated.

Further, the application generator should not generate any

appreciable client‐side scripting code that contains data access logic.

All data access code should be kept in the application layer (middle

tier) or database layer, so that malicious application users cannot

reverse engineer the data access mechanisms, and then use that

information to access the database for criminal or malicious

purposes.

Active Directory and LDAP

Active Directory and LDAP (low‐overhead directory access protocol)

are “single sign on” facilities available from Microsoft and other

vendors that provide a single sign‐on and user authentication

facility. When using a “single sign on” facility, an end user can sign

in once, and that sign in will be transferred to all applications used

by the user during the session. Such an approach saves the user

from the inconvenience of signing in to each and every individual

application they may access during a session. Moreover, these

facilities provide centralized user access control for IT departments,

and make it easier for them to manage user accounts.

Because of the standard nature of this sort of feature, application

generators should create applications with support for Active

Directory and LDAP automatically, or provide easy‐to‐use examples

that demonstrate how such facilities can be integrated into the

applications they

generate.

Password Storage

Most applications with built‐in password security store the user

name and password information in the underlying database. While

this is a convenient approach and allows for easy administration, it

isn’t the most secure because a variety of users, mostly internal, will

typically have access to the password information.

A malicious employee with access to password data can steal a

user’s identity and forge bogus transactions.

Sadly, this form of identity theft is all too common. Once a

password has been stolen, it can be used by insiders to create

fictitious customer accounts. These bogus customer accounts can

then be used to ship products to mail drops (stealing merchandise),

or to initiate real credit card refunds to fake accounts (fraud).



118

One simple and effective defense against this form of identify theft is

encrypting the password in the database using one of several simple

encryption protocols. One method has the application program

encrypt the clear text password before comparing it to the stored

encrypted password as part of its authentication protocol. This

method prevents

unauthorized

users

from

using

the

passwords

because the clear text version isn’t stored in the database.

An application generator should automatically generate role‐ based

security for your application. It should use the user name and

password fields in your database, and not require any special tables

created using the tool. Using the tool, you should be able to quickly

and conveniently build applications on top of your existing

database, using existing user names and passwords, and adding the

code to encrypt the passwords should be highly automated.

Handling SQL Injection Attacks

“SQL injection” is the act of entering a particularly odd‐looking

string into a text box or query string in order to have potentially

malicious SQL code execute. For example, if you have an ASP page

that accepts as a query string parameter an ID field, and this ID field

is then used to generate a dynamic SQL query, then your application

may be subject to an SQL injection attack.



119

An application user may enter a query string like:

1; DELETE FROM Or der s ( or some ot her mal i ci ous SQL st atement )

With this code, the SQL will be executed and your database table

deleted! You can combat this particular type of attack by strictly

enforcing data

type

validation

of

input

fields.

Applications generated by an application generator should be

completely safe from SQL injection attacks. They should ensure

your application is safe by ensuring that all data that affects the

construction of SQL statements (and stored procedure parameters)

goes through at least one abstraction layer that properly encodes or

interprets the data.

While it is possible for a developer to design an application that

bypasses this security and allows custom code and / or end user

input to unsafely affect the SQL generation, doing so should require

an application customization to circumvent the generated security

mechanisms.

Moreover, the application generator should incorporate filters into

data entry fields and tables. These filters should trap and replace

string inputs from the user, and completely prevent the user from

running any malicious SQL command (such as delete table).



120

Part 8)

Extending and Customizing

Applications

A behind the scenes look at how application

generation and custom code modifications

work together.



121

Although an application generator creates a running application

when it generates code, no one can expect an uncustomized,

automatically generated application to have the exact look‐and‐feel

or functionality that is desired for a production application.

Iron Speed

Designer,

for

example,

provides

a wealth

of

tools

and

techniques that make the process of customizing both an

application’s presentation and application layer easier. Some

customizations are done with wizards and allow the developer to

easily modify the application generation process. Other changes and

extensions can be made by extending the code that is automatically

generated.

Developers commonly make several types of code extensions to

generated applications, including:

Adding specialized, domain‐specific, data validation

routines

Adding custom calculated field values using data from the

database

Integrating with other application programs

Integrating with web services

While no application generator can anticipate every possible

extension and enhancement to every generated application, it should

create the application in a way that makes these extensions easy.

In practice, generated applications are easier to enhance than those

written by developers. Human programmers, because they’re

human, don’t always organize their work in a consistent fashion.

But the methodical, mechanized approach taken by an application

generator always writes and organizes the code it creates the same

way. It repeats this approach, day after day, application after

application, with no variance.

In addition to this mechanical consistency, application generators

consistently create every application with a complete state‐of‐the‐art

n‐tier architecture. Because of its automated approach, an application generator never cuts corners, and always follows all of

the best practices that have been baked into its approach.

As such, application generators bring a level of power and

functionality historically not associated with “quick and dirty”

applications. Armed with application generators, you can provide

unprecedented functionality, security, and robustness even for



122

applications created and deployed on short notice, and with very

small development teams.

Standards for Generated Code

Of course,

the

results

you

achieve

will

vary

widely

with

the

application generator you choose to employ. Ill‐formed code

generators, in the past, have produced code without much regard for

consistency, organization and coherence, all of which are

requirements for creating enhancements and downstream

maintenance. One bad experience using a poorly designed tool can

cause developers to resist, or even swear off, the whole idea of using

an application generator.

If you’ve had such an experience, rest assured that today’s

commercial grade application generators have made great strides in

producing code that meets developer expectations in this regard.

Let’s explore how today’s modern application generator tools

approach the problem, and create code that’s easy to understand,

extend, and maintain.

Well‐organized Code

Most application generators generate your application’s source code

and related files in a well‐organized file system hierarchy. Each

application is generated with exactly the same hierarchical structure,

making it easy to modify and extend generated applications once

you “come

up

to

speed”

on

the

architecture

of

the

generated

application.

In the case of Iron Speed Designer, all source code for the application

can be found in the Custom folder within a directory named after

the application. The generated ASPX pages, associated classes, and

the generated source code files associated with a specific database

table, are all stored in a folder named after the table. Within each

table folder, the code is further separated.



123

File hierarchy generated by Iron Speed Designer

<Application 1> <Ap pl icat ion 2> <App li cati on 3> <Ap pl icat io n 4>

App bin Custom

Common/Src Components Pages

<Table 3>

Theme

<Table 2>

Library

Platform

Iron Speed Designer FolderIron Speed

<Table 1> Misc

Deployed Internal Source

System.Web.UI.Page

BcBasePage

View_Products_PageSafeClass

View_Products_Page

(.NET class)

View_Products_PageGenClass

(Generated class)

(Base class)

(Safe class)

(ASPX page)

Inside the files, Iron Speed Designer creates a class

hierarchy that is granular and predictable. For

example, Iron Speed Designer creates two classes for

each web page, named <page_name>SafeClass (the

safe class) and <page_name>GenClass (the generated

class).

That

is,

a

web

page

named

View_Products_Page will have two classes associated

with it, View_Products_PageSafeClass and

View_Product_PageGenClass. (The significance of

these particular two classes will be discussed later

when we discuss modifying the code.) Iron Speed

Designer generates classes for all objects that you

would expect including pages, tables, records, fields,

buttons, menus, and so on.

The class hierarchy of the View_Products_Page

Control.

Code Should Meet Professional Standards

Application generators should write clean code and use standard

programming constructs. They should never add extra lines of code

that “might come in handy later.” Because you can easily regenerate

the application after you make changes to the attached database



124

table schema and web page designs, the application generator

should only create the exact code that is needed.

Files generated by Iron Speed Designer for a database table called ”Products”.

Found in <AppID>\Custom\Products Found in <AppID>\Custom\ComponentsEditProductsRecord.aspx Edit_Products_Record.ascxEditProductsRecord.gen.aspx.vb Edit_Products_RecordGenClass.ascx.vbEditProductsRecord.safe.aspx.vb Edit_Products_RecordSafeClass.vb

AddProductsRecord.aspx New_Products_Record.ascx AddProductsRecord.gen.aspx.vb New_Products_RecordGenClass.ascx.vb AddProductsRecord.safe.aspx.vb New_Products_RecordSafeClass.vbShowProductsTable..aspx Table_View_Products.ascxShowProductsTable.gen.aspx.vb Table_View_ProductsGenClass.ascx.vbShowProductsTable.safe.aspx.vb Table_View_ProductsSafeClass.vbShowProductsRecord.aspx Table_View_Products_Header_Row.ascxShowProductsRecord.gen.aspx.vb Table_View_Products_Header_RowGenClass.ascx.vbShowProductsRecord.safe.aspx.vb Table_View_Products_Header_RowSafeClass.vb

Table_View_Products_Record_Row.ascxDatabase Related Classes Table_View_Products_Record_RowGenClass.ascx.vb Db20001Products.vb Table_View_Products_Record_RowSafeClass.vbProductsRecord.vb View_Products_Record.ascxProductsRecordBaseClass.vb View_Products_RecordGenClass.ascx.vbProductsUtils.vb View_Products_RecordSafeClass.vbProductsUtilsBaseClass.vb

The names of all the files, classes, functions, and so on are based

upon the associated entity. For example, for a table called Products ,

Iron Speed Designer generates the web pages, safe classes, generated

classes, and data access classes, as shown in the table above.

In addition, the application generator should automatically write all

the data validation code, exception handling, and SQL queries based,

in part, on your data model. For example, when a field is declared as

type “Date”, Iron Speed Designer automatically creates classes that

inherit the validation methods that check to make sure that the user

entered a valid date.

Avoids Code Orphaning

One of the biggest problems with code generators of the past was

“orphaned code.” This was code that once generated, could not be

modified or extended. In todayʹs high‐pressure IT department, there

is no place for code that canʹt be leveraged for both current projects

and future applications.

Top tier application generators allow your application to be

regenerated repeatedly without requiring you to re‐integrate your

external code extensions. This can be accomplished using a





126

code extensions are not overwritten when the application is

regenerated. This approach provides a high degree of flexibility in

making code extensions to the generated application. You can

override any of the functions or methods in the generated base

classes, or write your own methods in combination with the existing

base class methods.

This is accomplished using a class hierarchy in the generated

application, which has a set of “safe” classes expressly for code

integration that is not affected by application regeneration. This

code is safe because it isn’t overwritten when the application is

regenerated. For example, every page, record, and control has its

own Safe class that is not overwritten, allowing the developer a high

degree of flexibility in making code extensions to the application.

The application generator writes the underlying safe classes for your

application only once, typically the very first time each page is

generated. Once the individual safe class for a page has been created

the first time, it is never overwritten. Thus, it is safe to add your

own code to and modify these safe classes.

Moreover, a developer can override functions in the page’s base

class. Typically you integrate custom code by either overriding one

of the methods on the base class, or you can write your own methods

in combination with the existing base class methods.

As previously mentioned, Microsoft .NET supports several

programming languages, including Visual Basic, C++, and C#.

Because all Iron Speed Designer‐generated applications are .NET

applications, code written in any of the languages that .NET

supports can be added. This includes any code extensions you make

or any pre‐existing code that you integrate with your application.

Example: Changing the Presentation Layer

For most applications, a developer will want to change the layout of

the default pages automatically generated by the application

generator, as well as create entirely new pages. These changes might

range from changing the applicationʹs look‐and‐feel (the colors,

fonts, and other visual elements) to creating more complex page

layouts with multiple database‐connected tables, fields, and filter

controls. Application generation technology provides a number of

tools to make these types of customizations easy for the developer,

including:

A number of wizards that enable a developer to specify the

types of pages created for a given database table, the







129

The two functions to override in our particular example are

initValidatorControl( ) and validateData( ). The default code for

these functions is shown below.

Functions from BaseRecordControl to overrideProtect ed Over r i dabl e Sub i ni t Val i dator Cont r ol ( ByVal v As I Val i dator Component )

' Does not hi ng unl ess overr i dden by subcl asses

End Sub

Protect ed Fri end Over r i dabl e Funct i on val i dat eData( ByVal v As

Recor dCont r ol Cust omVal i dator) As Bool ean

' Does not hi ng unl ess overr i dden by subcl asses

Return True

End Funct i on

To change the error message or other appearance aspects of a

validator, the developer needs to override the initValidatorControl( )

method. To change the validation logic of any of the

RecordControlCustomValidator validators, the developer needs to

override the validateData( ) function.

Overridable methods for BaseRecordControl class

createForeignKeyValueListItems getContainer getFieldValue

getFieldValueDisplayString getFieldValueString getField getFieldListItems getRecord getTable initFieldControl

initUI initValidatorControl isCreateMode

OnIronSpeedEvent SetDataBoundRecordInfo setFieldValueString setRecordWorkflowState updateData validateCheckSum validateData



130

Class hierarchy for the

Edit_Products_Record

class.

BaseRecordControl

Edit_Products_RecordGenClass

init ValidatorControl()validateData() Edit_Product_RecordSafeClass

Modify here

(Base class)

(Safe class)

System.Web.Ui.UserControl

(.NET class)

(Generated class)

Edit_Product_Record

(ASCX control)

init ValidatorControl()validateData()

For example, let’s say that for the Edit_Products_Record control we

want to

make

sure

that

the

price

of

each

product

is

divisible

by

4.

Because we are changing the logic of the validator, we want to

override the validateData( ) function on the BaseRecordControl class.

In order to create custom code that will be retained if the application

is regenerated, we modify the validateData( ) function on the

associated Safe class, Edit_Products_RecordSafeClass, as indicated

below:

Prot ected Over r i des Funct i on val i dateData(ByVal v As

Pl at f orm. Recor dCont r ol Cust omVal i dator) As Bool ean

Di m ct r l As System. Web. UI . Cont r ol = v. GetCont r ol ToVal i date( )

I f ( ( Not I sNot hi ng( ctr l ) ) AndAl so ( TypeOf ( ctr l ) I s

Pl at f orm. I Fi el dVal ueComponent ) ) Then

Di m f i el d As Pl at f orm. BcCol umn = Me. getFi el d( CType(ct r l ,

Pl at f orm. I Fi el dVal ueComponent ) )

Sel ect Case (f i el d. Name)

Case "Pr i ce"

Di m val ue As St r i ng = v. Get Val ueToVal i dat e()

I f ( I sNumeri c( val ue) AndAl so ( ( val ue Mod 4) = 0) ) Then

Retur n Tr ue

El se

v. Er r or Message = "Pri ce i s not di vi si bl e by 4. "

Return Fal se

End I f

End Sel ect

End I f

End Funct i on

Modified function from Iron Speed Designer’s Edit_Products_RecordSafeClass.vb.



131

The code shown, in the file Edit_Products_RecordSafeClass.vb,

checks to see if value is a number and if the price is divisible by 4. If

not, an error message for the field is set.

Because Iron Speed Designer writes

Edit_Products_RecordSafeClass.vb only once, the developer can

regenerate the application as many times as he or she wishes, and

this function will persist.

All code customizations and extensions are made in an analogous

fashion to this data validation example. Although it does require

knowledge of the class hierarchy, changing the code in an Iron Speed

Designer application is straightforward.

Every User’s Request, “Can you add a button that…?”

Any developer who has introduced any number of new applications

to end users has experienced the following scenario: You’ve just completed a demo of the system that you’ve worked for weeks or

months to produce. Regardless of how well the application

implements the original goals, there’s always a request to add some

sort of special feature that wasn’t included.

Of course, adding the button graphic is easy. But making sure it

appears in the right context, and actually does something useful

when you click on it, requires careful programming and testing.

Like most things related to web application development,

application generators can help developers accommodate such

requests quickly.

A

good

application

generator

will

include

the

ability to insert a variety of pre‐ built buttons and configure them to

do many of the most common things users request.

The next few pages offer an example of how application generators

can help developers accommodate such requests faster than ever

before.

Common Button Actions and Properties

Button actions determine what action is taken when a button is

clicked. While there are several button types – image buttons, link

buttons, and push buttons – they share the same binding properties,

which are detailed below.



132

Iron Speed

Designer

allows

developers to

easily

configure commonly

requested

buttons and

their

properties.

Using these configuration tools in an application generator, you can

specify a variety of button properties and actions. Simple properties

include the text to display in the button or link, the URL of the image

to be displayed, and the “tool tip” – the help text that’s displayed

when the user hovers the mouse over the button.

Using the

action

configuration

settings,

you

can

instruct

the

button

to perform a variety of tasks when pressed. Some of these

capabilities include data validation, adding or deleting records,

exporting data, filtering data, opening a new window with new

URL, searching the database, updating data, or executing custom

code.

Further, you can configure each button to specify a consumer of the

event when activated. This event‐handling mechanism allows other

controls to take action based on the event. This is how pages can

change based on interacting with users. Examples of button

consumers include the page, the parent, the parent record, and the

parent table.

When a button event redirects to a new URL, it can pass data along

using URL parameters. This data can be hard‐coded or dynamic.



133

The image on the left shows an Iron

Speed Designer example of a

redirect URL and associated

parameters. During configuration,

values for the parameters “id” and

“name” are URL arguments. At runtime, these parameters are

instantiated with the values from

the relevant record. In this case, the

values for the “id” and “name”

parameters are “444” and

“michael” respectively.

Passing Primary and Foreign Key Values in URL’s

Using an application generator, you can specify the button to pass

multiple parameters, and each parameter can be passed one or more

values. Parameters such as primary and foreign key values can be

passed from one page to another through the destination page’s

URL. However, the parameters passed as part of the URL shouldn’t

be limited to the primary and foreign keys. You should be able to

pass any field value, as well as display values. The display values

might be

different

than

the

field

values

– for

example,

for

Boolean

fields, the field value might be 1 or 0, but the display value might be

True or False.

The parameters passed as part of Redirect URL and URL Parameters

should be available for any of the buttons or links. When using Iron

Speed Designer, for example, the URL Parameters field specifies a

comma delimited set of arguments that can be passed on the URL.



134

Developers usingIron SpeedDesigner use theRedirect URL andRedirectargument

parameters to pass primary and foreign key valuesbetween pageswhen a button isclicked.

In the example shown above, the Redirect URL uses an argument

“Orders={PK}” to indicate the Orders parameter will be bound at

run‐time to the primary key (PK) field value. This means that the

parameter {PK} will be substituted with the record’s primary key

(PK) value.

Passing Primary Key Values Between Pages in URL’s

Passing primary key values from one page to another via URL’s is

very straightforward. As an example, in Iron Speed Designer, you

specify:

Field ValueAction Redirect

URL Parameters ID

Redirect URL {0}

This will pass the primary key value to the destination page via the

URL. Even though the argument is called “ID”, what is passed to

the URL is an XML element that specifies the full primary key of the



135

record. If the primary key is a composite key, the composite key is

passed as an argument.

If the ID of the field is a single integer value, you can use the “FV”

Redirect Parameter type to pass the value to the URL. However, if

you later change the Id to a more complex key, your existing pages

will not work correctly. As such, we recommend always using the

“ID” or “PK” Redirect Parameter types to pass primary keys to other

pages.

Passing Other Values Between Pages

As discussed earlier, you can use the URL Parameters types to pass

any field value to a page via its URL. For example, to pass the first

and last names from the employee record, specify the URL and the

URL Parameters as follows:

Field Value

Action Redirect

URL Parameters FV:FirstName,FV:LastName

Redirect URL ViewEmployeePhoto.aspx?First={0}&Last={1}

Passing Parameters in URL’s

A component can interact indirectly with other components by

interacting with the page’s HTTP response object and causing a

client‐side redirect to a different page (i.e. A different URL). This is

similar

to

interaction

using

events,

but

instead

of

creating

an

event

object, the component redirects the client’s browser to a new URL.

By dynamically constructing the URL, the component can choose the

page to which the user will be redirected. Also, using URL

parameters, the component can pass data to the new page. The

benefit of this over interaction using events is that it works even for

components on different pages. However, because URLs are limited

to a browser‐specific maximum length, the quantity of data that can

be passed to a new page is fairly limited. Also, unlike events, a

redirect will cause the current page to stop processing immediately.

Therefore, some situations may require a combination of event

interaction and page redirection.

There are many contexts in which passing data from one page to

another via the URL is a convenient means of transferring data. This

example passes the Id’s of two products to a page to show how

parameter passing works. Two products are displayed as a result of

this example.



136

Two different products are selected for display by passing their respective primary key values to the generated application page via URL query string parameters.

The following pages show the steps and the code used to create this

functionality with a modern application generator.

First, create a new layout page as follows:

<di v al i gn="center" >

<GEN: Recor d Name="Pr oduct ">

<t abl e cel l paddi ng="5" st yl e="bor der- col l apse: col l apse" bor der ="1"

bor der col or l i ght ="#C0C0C0" bor der col ordar k="#C0C0C0">

<t r st yl e="f ont - f ami l y: Ver dana; f ont - si ze: 10px">

<t d al i gn="r i ght ">Product I d: </ t d>

<t d st yl e="f ont - wei ght : bol d"><GEN: Fi el dVal ue Name="Product I d" / >

</ t d>

</ t r>


<t d al i gn="r i ght ">Product Name: </ t d>

<t d st yl e="f ont - wei ght : bol d">

<GEN: Fi el dVal ue Name="Pr oduct Name" / >

</ t d>

</ t r>


<t d al i gn="r i ght ">Uni t Pr i ce: </ t d>

<t d st yl e="f ont - wei ght : bol d"><GEN: Fi el dVal ue Name="Uni t Pr i ce" / >

</ t d>

</ t r>


<t d al i gn="r i ght ">Uni t s i n St ock: </ t d>

<t d st yl e="f ont - wei ght : bol d">

<GEN: Fi el dVal ue Name="Uni t sI nSt ock" / >

</ t d>

</ t r>

</ t abl e>

</ GEN: Recor d>

</ di v>

Then, using the tool, bind the Record tags to specify the source of the

data as from the Products table. You’ll also specify the URL

parameter as P1 as shown below:



137

Repeat this step for the second Product code generation tag. This

time specify a different name for the query string parameter such as

P2.

Then bind the field values to their respective fields, generate the

application, and you’re done.

Example: Adding Reporting to a Generated Application

In many custom business applications, the first set of goals for the

application revolve around getting access to and from a set of data

that’s relevant to the task at hand. Once the basic functionality of

deploying an application that allows various user roles to maintain,

and get access to, a set of data, a new set of requirements tend to

surface. Once the basics are in place, users reappear with additional requirements for version 2.0.

A common example of a “v.2.0” enhancement involves integrating

with another program to produce charts and graphs for presentation

and analysis purposes.

Let’s explore how a generated application can be integrated with a

reporting program. The following example shows how to add a

button to a page (generated by Iron Speed Designer) to populate an

existing report (a Crystal Reports .rpt file) and display it in a popular

document format

(Adobe’s

Portable

Document

Format,

PDF).

The required steps involve:

Customizing a generated layout by adding a custom button.

Binding the new button to a custom event.



138

Adding code for event handling and report generation to a

safe class.

This example uses an application that’s based on the Northwind

database that comes with Microsoft SQL Server. Here is the page

that will be generated in this example.

Created withIron SpeedDesigner, thismodified pageadds the new“Export toPDF” button.

Here is an image of the “Northwind Products” report as rendered in

the browser by Acrobat Reader.

Let’s walk through the steps needed to complete this modification

with an application generator.



139

First, you’d use the application generator to create the standard

Show Table page shown here. NOTE: The application generator will

create everything shown except the text shown in blue.

<! - - BEGI N Ever est\ Tabl e_Vi ew. ht ml - - >

<t abl e cel l spaci ng="0" cel l paddi ng="0" border ="0" cl ass="mast er_ t abl e">

<t r ><t d cl ass="but t on_bar ">

<t abl e cel l paddi ng="0" cel l spaci ng="0" border="0" cl ass="hol der_ t abl e">

<t r >

<t d cl ass="but t on_bar_cel l ">

<GEN: BUTTON FI LE=" . . / Shar ed/ Butt on. ht ml "

NAME="Pr oduct sNewBut t on"></ GEN: BUTTON>

</ t d>



NAME="Pr oduct sEdi t But t on"></ GEN: BUTTON></ t d>



NAME="Pr oduct sDel et eBut t on"></ GEN: BUTTON>

</ t d>



NAME="Pr oduct sExpor t But t on"></ GEN: BUTTON>

</ t d>

<! - - New "Export t o PDF" But t on - - >

<t d cl ass="but t on_bar _cel l ">


NAME="Pr oduct sExpor t ToPDF" ></ GEN: BUTTON>

</ t d>

</ t r>

</ t abl e>

Then, you’d need to locate and open the layout file, e.g.:

…\ <AppDi r ectory>\ Source\ Products\ Vi ewProductsRecords. html

and insert the new GEN:Button tag as shown above in blue.

Then, you’d use the application generator to bind the page to the

database, and bind the new button as shown below.



140

Binding a custom “Export to PDF” button with Iron Speed Designer.

Here, you’d set the following:

Field ValueCommand name Custom

Custom command DisplayAsPDF

Consumers Page

You can also specify a tool tip if you like. Then, you’d save the

bindings and generate the application.



141

Now, you’ll need to extend the

code to use the reporting

engine and report. Open the

project in Visual Studio by

clicking on the application’s

generated .VBPROJ file. Click

the “Show All Files” icon at

the top of the Solution

Explorer pane so that the

application’s “code behind”

files are added to the Solution

Explorer.

Find the “ProductsList.rpt”

file. This defines the report

that Crystal Reports will

produce.

Next, add the

“ProductsList.rpt” file to the

project by right‐clicking on the

Products folder in the Solution

Explorer pane, selecting “Add

Existing Item…”, and

navigating to the

ProductList.rpt.

Now locate and open the page’s safe class, e.g.:

Vi ewProduct sRecor ds. saf e. aspx. vb

If you are using Visual Studio, expand the

“ViewProductsRecords.aspx” node in the solution tree, and then

expand the ViewProductsRecords.gen.aspx.vb node to display the

“safe class” file, ViewProductsRecords.safe.aspx.vb. Double click on

the safe class file to open it in the source code editor.

Insert the following two lines at the top of the page’s safe class file.

These statements cause the necessary Crystal Reports objects to be

linked into your generated application.

I mpor t s Cr yst al Deci si ons. Cr ystal Repor t s. Engi neI mport s Cr ystal Deci si ons. Shared

Now, insert the following code into the (otherwise empty)

ViewProductsRecords class definition.

The OnIronSpeedEvent function implements an event handler that

will be called when the new “Export to PDF” button is clicked.

Adding theProductsList.rpt

file to the generatedapplicationusing VisualStudio.



142

The DisplayReportAsPDF function connects to the data base,

populates the report, and then displays it in the web browser.

' Thi s method handl es t he I r onSpeedEvent produced by t he Export ToPDF but t on

Publ i c Over r i des Sub OnI r onSpeedEvent( ByVal args As I r onSpeed. Base. I r onSpeedEvent Ar gs)

' Handl e t he cust om"Di spl ayAsPDF" command, but pass ot hers of f t o t he base cl assI f args. Event Type = I r onSpeed. Base. I r onSpeedEvent Ar gs. Event Types. Cust omAndAl so _

ar gs. Cust omEvent Name = "Di spl ayAsPDF" Then

' ' cr eat e the report obj ect and pr oduce t he report

Di m cr Repor t Document As New ProductsLi st ( )

Di spl ayRepor t AsPDF( cr Repor t Document )

El se

' not t he cust om"Di spl ayAsPDF" command, pass i t on

MyBase. OnI r onSpeedEvent ( args)

End I f

End Sub

'' Thi s f unct i on cr eat es an i nst ance of t he Cr yst al Repor t , i n PDF f or mat , and di spl ays i t

'

Sub Di spl ayReport AsPDF( ByVal r eport Obj ect As

Cr ystal Deci si ons. Cr ystal Repor t s. Engi ne. Repor t Cl ass)

' Decl are t he necessary Cr ystal Report s obj ect s

Di m dbTabl e As Cr ystal Deci si ons. Cr ystal Report s. Engi ne. Tabl e

Di m dbLogi n As Cr ystal Deci si ons. Shar ed. Tabl eLogOnI nf o

Di m cr Export Opt i ons As Export Opt i ons

Di m crDi skFi l eDest i nat i onOpt i ons As Di skFi l eDest i nat i onOpt i ons

' Cr eat e a t empor ary f i l e t o hol d t he r eport

' - - use t he sessi on I D i n t he f i l ename t o avoi d pr ocess conf l i ct s' - - use a bui l t - i n I r on Speed ut i l i t y f unct i on ( and t he "MapPat h" met hod) t o get t he

cur r ent

' - - appl i cat i on' s root pat h

Di m f name As St r i ng =

Server . MapPat h( I r onSpeed. Base. Conf i gur ati on. Appl i cat i onSet t i ngs. Cur r ent . AppRoot Path) _

& "\ " & Sessi on. Sessi onI D. ToSt r i ng & ". pdf "

' def i ne the Cr ystal Repor t ouput opt i ons

crDi skFi l eDest i nati onOpt i ons = New Di skFi l eDest i nati onOpt i ons( )

cr Di skFi l eDest i nat i onOpt i ons. Di skFi l eName = f name

cr Export Opt i ons = r eport Obj ect . Export Opt i onsWi t h crExport Opt i ons

. Dest i nati onOpt i ons = cr Di skFi l eDesti nati onOpt i ons

. Export Dest i nati onType = Export Desti nati onType. Di skFi l e

. Expor t FormatType = Expor t FormatType. Port abl eDocFormat

End Wi t h

' Retr i eve DB Connect i on I nf o

Di m ProductsTabl e As New Cr yst al Repor t sDemo. Product sAccess( )



143

Di m DBConnect i onName As Str i ng = Product sTabl e. Connect i onName

Di m DBConnSt r i ng As St r i ng = _

I r onSpeed. Base. Conf i gur at i on. Appl i cat i onSett i ngs. Cur r ent . GetConnect i onSt r i ng( DBConnect i onName

, Fal se)

Di m DBConnect i on As I r onSpeed. Base. Conf i gur at i on. DatabaseConnect i on

DBConnect i on =I r onSpeed. Base. Conf i gur at i on. DatabaseConnect i on. Par se( DBConnect i onName, DBConnSt r i ng)

' get t he connect i on' s user i d and password val ues

Di m ui d As St r i ng = DBConnect i on. User Name

Di m pw As St r i ng = DBConnect i on. Password

' set t he l ogi n f or al l t he t abl es i n t he r epor t

For Each dbTabl e I n r eport Obj ect . Database. Tabl es

dbLogi n = dbTabl e. LogOnI nf o

dbLogi n. Connect i onI nfo. Password = pw

dbLogi n. Connect i onI nf o. User I D = ui d

dbTabl e. Appl yLogOnI nfo( dbLogi n)Next

' export t he document t o t he temporar y f i l e

r epor t Obj ect . Expor t ( )

' Cr eat e t he HTTP Response as PDF and output t he f i l e

Response. Cl ear Cont ent ( )

Response. Cl ear Header s( )

Response. Cont ent Type = "appl i cat i on/ pdf "

Response. Wr i t eFi l e( f name)

Response. Fl ush( )

' Cl ean up t he Response obj ect and del ete t he t emporar y f i l e

Response. Cl ose( )

System. I O. Fi l e. Del ete( f name)

End Sub

Once complete, save all files and the compile the application.

Run the newly‐customized application, navigate to the Products

page, and click on the new Export to PDF button. A PDF report

showing Northwind Products data will be displayed in your web

browser.

Localizing (Internationalizing) Your Application

As part of today’s global economy, business applications are being

asked to span multiple geographies, and support users in their

native languages. Application generators provide support for



144

developers looking to embrace these international requirements in

the software they create.

This section discusses a few issues developers face when they

internationalize (localize) generated applications. While no

application generator has a “magic switch” you can throw to

generate your application in one language or another, you should

expect them to support the customizations you would naturally

want to make when localizing your application.

Local date formats, currency symbols and character sets are supported by Iron Speed Designer in generated applications.

A variety of factors, settings, and parameters contribute to a

localized application:

Culture encoding. Your generated application should have a

culture coding to indicates to the underlying platform (such as the

.NET framework) how to handle basic properties, like date and time

formatting, language, etc.

Page encoding. The application generator should create the

application with an internationally recognized page encoding. For

example, Iron Speed Designer supports UTF‐8 Unicode encoding

throughout the applications it generates.

Date and time formatting. A variety of date and time formats are

used worldwide. The tool you use should make it easy to configure

your application

to

accept

a variety

of

date

and

time

formats.

Number and currency formatting. Some number formats use a

decimal point to separate dollars and cents; other formats use

commas. Again, it should be easy to support these different formats.

Error text string translation. Error and information text messages

should be managed by the tool in a way that makes them easy to

translate to the appropriate language for the application.



145

Summary

In the last 10 years, experiments with data and business modeling

software packages that generate code have resulted in a fairly

thorough understanding of the characteristics that an application

generator must

have

to

be

a viable

solution.

New

tools,

such

as

Iron

Speed Designer, make web‐ based application generation worth

investigating as a potential solution for an IT department that needs

to decrease development costs as well as speed up its

implementation schedule. Developers no longer need to worry

about whether the generated application can be customized and

extended in a timely fashion. And, a developer need not be

Microsoft .NET savvy to take advantage of this powerful framework.



146

Part 9)

Automating IT Strategies

How IT Departments Automate

Implementation of Standards & Best

Practices



147

Now that we’ve demonstrated how generated application can be

modified or extended, this chapter will focus on how these

extensions can be automatically re‐used across the enterprise. As

you’ll remember, in an earlier section we discussed how a software

development methodology that embraced application generation

technology could

enable

corporate

computing

standards

in

meaningful and pragmatic ways.

The following pages describe real‐world examples of how Iron

Speed Designer delivers on these promises through automated page

production, code‐reuse, custom controls, and custom page

templates.

Automating Page Production

Using an application generator, you can automatically create

hundreds of

web

pages

based

on

your

own

design,

or

you

can

create

standard pages using page templates provided with the tool.

Automated production of web pages imposes organization and

structure upon the hundreds of pages that may be necessary for your

application. Not only does this structure allow the application

generator to do most of the work, but it helps the development team

organize and keep track of what pages are needed, and the

functionality required.

As an example, Iron Speed Designer utilizes three different types of

pages.

Page Templates – These “master” HTML pages are used to

automatically create layout pages. This automatic layout

page creation process is enabled by a special set of code

generation tags that are used to automatically create layout

pages. Also, Page Templates can include standard code

generation tags that are replaced when the application is

generated.

Layout Pages – These HTML pages are used by the

application generator when creating the application. They

include

code

generation

tags

that

are

replaced

with

references to .NET controls when the application code is

written.

ASPX Pages – Created by Iron Speed Designer these “Active

Server Pages” are used by the server to dynamically create

and display pages requested by an end user’s browser.



148

An application generator should include various sample page

templates to give you a choice of application look‐and‐feel without

forcing you to create one. These page templates allow you to create

standard pages to create, review, update, and delete (C/R/U/D)

records. Tools should also include similar page templates for

viewing and editing entire tables.

Each of the page templates provided with Iron Speed Designer

follows a design theme. A design theme is a collection of Page

Templates and Layout Pages where a consistent look and feel is

reflected in the layout of the pages, the colors, and the common elements across pages such as menu bars, and search, pagination

and filter controls.

Following are three examples of the same page created from page

templates using different design themes.

Page Templates Layout Pages ASPX Pages

Created by the developer Can be created by thedeveloper or Iron SpeedDesigner.

Created by Iron SpeedDesigner

Contain HTML &code generation tags &special code generationtags used by application

generator toautomatically createlayout pages

Contain HTML &code generation tags

Contain HTML &references to data-bound.NET controls in place of code generation tags

Typically used to createhundreds of C/R/U/D

pages for records andtables.



149

A table view page rendered with Iron Speed Designer’s Alps design theme.

A table view page rendered with Iron Speed Designer’s Everest design theme.



150

A table view page rendered with Iron Speed Designer’s Annapurna design theme.

Page templates and layout pages within a design theme utilize

panels for repetitive page elements that don’t change from page to

page. This approach achieves a consistent look and feel across

multiple pages with a minimum amount of work. For example, you

only need specify the button look and feel once and use it as a panel

in all layout pages rather than describing the layout for each button

within each and every page.

Iron Speed Designer includes predefined panels for each of the page

templates it provides. In addition to buttons, headers and footers,

the pre‐defined panels include:

Panel Description

Menu A menu panel containing one or more menu items. To add a new menuitems, edit the Menu.html.

Menu_Item The panel for an individual menu item. This panel is used for the normaldisplay of the menu item.

Menu_Item_Highlighted This panel specifies the highlighted state of an individual menu item.

Pagination The pagination panel containing a number of controls including previouspage, first page, next page, last page, a text box to enter the number ofrecords to display and an indicator showing the page you are oncurrently.

Range_Filter The range filter displays two field filters so the application user can



151

Panel Description

specify a range for searching.

Search The search panel includes a standard text box and a button.

What’s in a Page Template?

Page template files are just HTML files that have been enhanced

with code generation tags. They specify the graphics and

organization – the look and feel – that will be used on layout pages

and ASPX pages that are derived from this master page template.

Each page template uses a set of common component files that are

used by other page template files belonging to the same design

theme.

For

example,

the

button

on

the

Add,

Edit,

and

View

pages

of

the Everest design theme files is specified in a separate component

layout file called Button‐Everest.html. (In a few pages, we’ll discuss

how these common components, or panels, are used to facilitate code

re‐use.)

In addition to the regular set of code generation tags, page templates

can also use a few special code generation tags. These special code

generation tags help the application generator to create layout pages

based on the page template.

An Example Page Template: Automated Record Pages

Remember, code generation tags are used to specify places on pages

where data controls appear. Code generation tags specify the

relevant data, and at binding time, you specify how they’ll be used.

Keeping this in mind, the Add, Edit and Show Record generated

layout pages are based on exactly the same template. The binding of

the code generation tags determines whether the page functions as

an Add, Edit or Show Record page.

The application generator determines the type of the template using

the GEN:Template code generation tag.

A simple example page template for Add Record is shown below.

Each of the code generation tags is highlighted, and discussed in

detail following the page template.

<! - - St ar t AddRecor d. ht ml - - >

<! - - Templ ate Tag t o Speci f y the ki nd of page t hi s i s t o the bi nder - - >

<GEN: TEMPLATE TYPE="Add One Record" FI LE="Record Panel s/ Add Record - Label on Si de. html " / >

<! - - St ar t Logo Tabl e - - >



152

<t abl e cel l spaci ng="0" cel l paddi ng="0" border="0" wi dth="100%">

<t r >

<t d><GEN: I mage Name="Logo" / ></ t d>

</ t r>

</ t abl e>

<! - - End Logo Tabl e - - >

<! - - St ar t Menu - - >

<GEN: Menu Name="Menu" FI LE=" . . / Menu Panel s/ Menu. html " / >

<! - - End Menu - - >

<! - - St ar t Recor d Tabl e - - >

<t abl e cel l paddi ng="0" cel l spaci ng="0" border="0" wi dth="100%">

<t r >

<t d>

<GEN: Recor d Name="Recor d">

<! - - St ar t Di al og Tabl e - - >

<t abl e cel l paddi ng="0" cel l spaci ng="0" border="0" wi dth="100%">

<t r >

<t d><GEN: I mage Name="Di al ogI con" / ><GEN: Ht ml Name="Di al ogTi t l e" / ></ t d>

</ t r>

<t r >

<t d>

<t abl e cel l paddi ng="0" cel l spaci ng="3" border ="0">

<t r >

<t d>

<%= Me. Syst emUt i l s. GenerateEnterKeyCapt ureBegi nTag( Me. Fi ndCont r ol ( "V_Cancel But t on") )

%><%= Me. Syst emUt i l s. GenerateEnterKeyCapt ureBegi nTag( Me. Fi ndCont r ol ( "V_OKButt on") ) %>

<! - - St ar t Actual Tabl e Secti on - - >

<t abl e al i gn="cent er" cel l paddi ng="0" cel l spaci ng="3" bor der="0">

<GEN: For Each Name="Recor d">

<t r >

<t d><GEN: Fi el dLabel Name="Fi el dVal ueLabel " / ></ t d>

<t d><GEN: Fi el dVal ue Name="Fi el dVal ue" / ></ t d>

</ t r>

</ GEN: For Each>

</ t abl e>

<! - - End Act ual Tabl e Tabl e - - >

<%= Me. Syst emUt i l s. GenerateEnt erKeyCapt ureEndTag( Me. Fi ndCont r ol ( "V_OKButt on") ) %>

<%= Me. Syst emUt i l s. GenerateEnterKeyCapt ureEndTag( Me. Fi ndCont r ol ( "V_Cancel Butt on") ) %>

</ t d>

</ t r>

<GEN: For Each Name="OneToManyTabl e">

<t r >

<t d>



153

<! - - St art of "1" One- To- Many Tabl e Vi ew - - >

<! - - St art But t on Bar Tabl e f or One- To- Many - - >


<t r >

<GEN: For Each Name="But t onBar ">

<t d>

<GEN: But t on Name="But t onBar" f i l e=" . . / Shared/ But t on. ht ml " / ></ t d></ GEN: For Each>

</ t r>

</ t abl e>

<! - - End But t on Bar Tabl e f or One- To- Many - - >

<! - - St art Act ual One- To- Many Tabl e - - >


<GEN: Tabl e Name="Tabl e">

<! - - Start One- To- Many Tabl e Header Row - - >

<t r >

<GEN: For Each Name="Header Row">

<t d><GEN: Fi el dLabel Name="Fi el dLabel " / ></ t d>

</ GEN: For Each></ t r>

<! - - End One- To- Many Tabl e Header Row - - >

<GEN: I t emTempl at e Name="Recor dRow">

<! - - Star t One- To- Many Recor d Row - - >

<t r >

<GEN: For Each name="Recor dRow">

<t d <GEN: Al i gn Name="Al i gnTabl eFi el dVal ue" / >><GEN: Fi el dVal ue

name="Tabl eFi el dVal ue" / ></ t d>

</ GEN: For Each>

</ t r>

<! - - End One- To- Many Record Row - - >

</ GEN: I t emTempl at e></ GEN: Tabl e>

<%=

Me. Syst emUt i l s. GenerateEnterKeyCapt ur eEndTag(Me. Fi ndCont r ol ( "V_For EachButt onBar1Butt on") ) %>

</ t abl e>

<! - - End Act ual One- To- Many Tabl e - - >

<! - - End of "1" One- To- Many Tabl e Vi ew - - >

</ t d>

</ t r>

</ GEN: For Each>

<t r >

<t d><! - - St art Di al og But t ons ( Ok and Cancel ) - - >

<t abl e al i gn="cent er" cel l paddi ng="0" cel l spaci ng="0" bor der="0">

<t r >

<t d>

<GEN: Butt on Name="OKButt on" f i l e=" . . / Shar ed/ Butt on. ht ml " / ></ t d>

<t d><i mg sr c=". . / I mages/ Vani l l a/ space. gi f " hei ght ="6" wi dt h="3" al t =""></ t d>

<t d>

<GEN: But t on Name="Cancel But t on" f i l e=". . / Shared/ But t on. ht ml " / ></ t d>



154

</ t r>

</ t abl e>

<! - - End Di al og But t ons ( Ok and Cancel ) - - >

</ t d>

</ t r>

</ t abl e>

</ t d></ t r>

</ t abl e>

</ GEN: Recor d>

</ t d>

</ t r>

</ t abl e>

<! - - End Recor d Tabl e - - >

<! - - St ar t Foot er Tabl e - - >

<t abl e cel l spaci ng="0" cel l paddi ng="0" border="0">

<t r >

<t d><GEN: Footer Name="Footer" f i l e=". . / Header & Footer/ Footer. ht ml " / >

</ t d>

</ t r>

</ t abl e>

<! - - End Foot er Tabl e - - >

<! - - End AddRecord- Vani l l a. ht ml - - >

The first tag in the page template is the GEN:Template tag. The

Type value of this tag determines the type of template. The

application generator requires the presence of the tag to identify this

file as a page template file.

<GEN: TEMPLATE TYPE="Add One Recor d" FI LE="Recor d Panel s/ Add Recor d - Label on

Si de. ht ml " / >

Following the Template code generation tag, the template may

include one or more tags that include the image and the menu. The

application generator expects a code generation tag called Logo and

it uses this information to bind the logo image file to this tag in the

component binding file.

Similarly the GEN:Menu code generation tag refers to a menu layout

component.

<GEN: I mage Name="Logo" / >

<GEN: Menu Name="Menu" f i l e=" . . / Menu Panel s/ Menu. html " / >

The GEN:Record tag with the name Record is bound to the table to

which the record is being added, edited or viewed. When an Edit or

View page is created, the name of the table is also used to create a

URL parameter to retrieve the Id of the record.



155

<GEN: Recor d Name="Recor d">

The DialogIcon and DialogTitle tags are Image and HTML code

generation tags respectively. These tags are bound automatically to

the icon_edit.gif image in the Images\<Design Theme> folder.

Similarly, the GEN:Html tag specifies the default dialog title and is

automatically initialized to the name of the file.

<GEN: I mage Name="Di al ogI con" / ><GEN: Ht ml Name="Di al ogTi t l e" / >

In this example, the most important set of tags in the page template

are the ForEach, FieldLabel and FieldValue tags. The application

generator asks you to select all the fields to include on the layout file.

The beginning and ending ForEach tags are completely removed

from the layout file created and all the HTML and code generation

tags within the ForEach tags are expanded and repeated as many

times as the number of fields specified. In this way, the application

generator iteratively writes code for each record specified, and does

this until completion – saving you hours and hours of repetitive,

mind‐numbing, work.

<GEN: For Each Name="Recor d">

<GEN: Fi el dLabel Name="Fi el dVal ueLabel " / >

<GEN: Fi el dVal ue Name="Fi el dVal ue" / >

</ GEN: For Each>

Each repeated FieldLabel tag is given its own name by adding the

name of the field as a prefix. For example, if the field name is

FirstName, the FieldValue tag is called FirstNameFieldValueLabel.

A similar repetition is performed on the FieldValue tag and the

name of the tag is derived from adding the field name as a prefix to

the name of the FieldValue tag. Here again, the application

generator utilizes the labels you provide, but writes all the code for

you.

After the set of field label and field value pairs, the page template

allows you to specify one‐to‐many or master‐detail tables to be

added, edited or viewed for the page templates.

<GEN: For Each Name="OneToManyTabl e">

<GEN: For Each Name="But t onBar ">

<GEN: But t on Name="Butt onBar" f i l e=". . / Shared/ Butt on. html " / ></ t d></ GEN: For Each>

<GEN: Tabl e Name="Tabl e">

<GEN: For Each Name="Header Row">

<GEN: Fi el dLabel Name="Fi el dLabel " / >

</ GEN: For Each>

<GEN: I t emTempl at e Name="Recor dRow">



156

<GEN: For Each name="Recor dRow">

<t d <GEN: Al i gn Name="Al i gnTabl eFi el dVal ue" / >>

<GEN: Fi el dVal ue name="Tabl eFi el dVal ue" / >

</ GEN: For Each>


</ GEN: Tabl e></ GEN: For Each>

Since there can be zero or more one‐to‐many tables, a ForEach code

generation tag is used to enclose the contents of each of the detail

tables. Within each detail table, there can be zero or more buttons

specified. The ButtonBar ForEach code generation tag indicates the

set of buttons to display.

The next section contains the code generation tags for the table itself.

First, the table header is defined followed by an ItemTemplate to

describe

each

row

of

the

table.

Included

in

the

row

is

an

Align

code

generation tag that allows the application generator to create an

alignment attribute for each TD HTML tag. As mentioned before,

the naming of the code generation tag is important in page

templates. These names are used by the application generator to

map to the fields from the database or buttons.

<GEN: Butt on Name="OKButt on" f i l e=" . . / Shared/ Butt on. html " / >

<GEN: But t on Name="Cancel But t on" f i l e=" . . / Shared/ But t on. ht ml " / >

The record page templates contain a set of buttons to save or cancel

the page. In some cases, such as the Show Record page template,

only the OK button is specified since there is no need to save

anything from that page. The application generator provides the

appropriate binding for the buttons based on their name in the page

template.

<GEN: Footer Name="Footer" f i l e=" . . / Header & Footer/ Footer. ht ml " / >

Finally, each layout page from a page template contains a footer

component. A blank footer component is created as part of each

page. You can enhance this footer component to include a copyright

notice or other information at the bottom of each page created using

page templates.

Automatic Re‐use of ASP.NET Directives in Page Template Files

Most commonly found at the beginning of the page, ASP.NET

Directives control the settings and properties of the page.

Sometimes, developers use ASP.NET directives to include custom

controls in a header or footer of a page (or both). Modern

application generators can easily incorporate these directives into the

applications they create.



157

For example, in Iron Speed Designer, you can place ASP.NET

directives in page templates by inserting @Register directives at the

very beginning of the page template file. The @Register directives

can occur anywhere in page template files as long as they are placed

before the first use of a tag prefix, i.e., they must precede the

<HTML> tag in the page template file. This allows you to freely mix

ASP.NET controls in theme files by following this simple rule.

Let’s further consider the example of incorporating an existing web

page header and footer which were developed using Visual Studio

.NET as web user controls into a generated application. To include

these header and footer web user controls, and potentially other web

user controls, you can customize a copy of the appropriate page

template to include these controls.

By way of example, here the following directives are inserted into a

page template file before the <HTML> tag:

<%@ Regi st er TagPr ef i x="MyCont r ol " TagName="Header "

Src="/ 20001/ Common/ Cont r ol s/ Border s/ Header . ascx" %>

<%@ Regi st er TagPref i x="MyCont r ol TagName="Footer "

Src="/ 20001/ Common/ Cont r ol s/ Border s/ Foot er . ascx" %>

Where the header is:

<MyCont r ol : Header

i d="Header "

r unat="server ">

</ MyCont r ol : Header>

and the footer is:

<MyCont r ol : Foot er

i d="Footer"

r unat="server ">

</ MyCont r ol : Footer>

Once ASP.NET directives are incorporated into the appropriate page

templates, every application created with these page templates

automatically includes them. As a result, future applications can

both support existing corporate standards, and reduce development

costs when

built

with

an

application

generator.

This notion is taken further in the next section that describes other

ways to automate code re‐use with application generation

technology.



158

A Pragmatic, Yet Revolutionary, Approach to Code Re‐Use

Now that you’ve been introduced to the notion of defining page

templates to create multiple layout pages, you have an

understanding of how application generators can be used to

automate, even

eliminate,

the

amount

of

labor

involved

in

creating

typical pages. Further, we’ve explained how those pages can

leverage existing ASP.NET directives within page templates to avoid

the labor typically involved with reusing that kind of code.

Contemporary application generators, however, take this idea even

further. Just about every snippet of any page can be created as a

reusable panel or component.

For purposes of this discussion, regard a component as simple and

single‐purpose in nature (e.g., a button, or a link, or a text box). A

panel is a collection of components with a single purpose. For

example, a search panel might have a text box and a “go” button.

One of the most powerful features of application generators is their

ability to create and use reusable panels and components. As in the

ASP.NET directive example earlier, a header, footer and menu panel

can be included on every page of a generated application. Reusable

panels allow the definition of the panel in one place and pages

simply refer to these panels. Changes only need be made once to the

panel and will be reflected on all pages that use the panel. This

allows you to consolidate the most common aspects of your

application into one location and reuse them as often as necessary.

Reusable panels are simply fragments of a page and are generated as

ASCX controls instead of ASPX pages. Just like a regular page, they

start with an HTML layout page file and are bound with the

application generator. Once created, they are referred to by other

HTML layout pages or panels by using a GEN:Use code generation

tag.

Reusable panels or components can be either completely

independent or they can be dependent on the page or panel that

includes them. For example, the header panel typically is a

completely independent panel containing a logo, and other images.

To contrast this, a reusable button component specifies its

appearance, but the page or panel that incorporates the button

specifies the actual button label, the action to take, and the URL to go

to when the button is clicked. In this case, the immediate parent

provides any additional information needed by the dependent

component. For example, the button label within a footer panel can

only be specified at the footer panel level, but not at the page level.



159

Reusable panels can be nested as deeply as you like. For example, a

reusable button panel might be included in the reusable Footer panel

that is included on each page. Typically, application generators

impose no limitation on the number of levels of nesting.

Automating

Code

Re‐

Use

with

Panels

&

Components

Experience has shown that just having the ability to re‐use code

that’s organized and configured for re‐use doesn’t always ensure it

happens. In some situations, merely the process of incorporating

reusable software parts has imposed more difficulty than just

rewriting the code. Modern application generators, however, pave

the way for code re‐use by dramatically simplifying the process as

shown below.

Building & Reusing an Independent Reusable Panel

The most common place you’ll most likely want to employ an

independent reusable panel is in the “header” of your application.

The following pages describe how you can use Iron Speed Designer

to create a simple reusable panel that puts a company logo in the

header of every page.

First, create a layout file for the reusable panel called

HeaderPanel.html as shown here. Note the GEN:Image tag.

<t abl e wi dth=100%cel l paddi ng="0" cel l spaci ng="0"

st yl e="border - bot t om- wi dth: 1; bor der - bot t om- col or : #DDDDDD; bor der - bot t om-

styl e: sol i d">

<t r ><t d><GEN: I MAGE Name="Logo" / ></ t d>

</ t r>

</ t abl e>

Now bind this file using the application generator. Select the Logo

tag and enter the URL of the logo and save.



160

Screen shot of how Iron Speed Designer specifies the path to an image.

The panel is now ready to be included in a page. To include this

panel on a page:

Create a simple layout file that includes the reusable panel. The

reusable panel is specified by using the GEN:Use code generation

tag. The File attribute of this tag specifies the panel to use.

<GEN: Header Name="Header " Fi l e=" . . / Header & Footer / Header . html " / >

t hi s i s t he r est of t he page

Now bind this file using the application generator. At this point you

can also override the layout file and point to a different file if

desired. This allows you the flexibility of overriding the panel to

point to a different panel.

Iron Speed Designer creating a reusable header panel.

Generate the

application

and

view

the

generated

page.





162

<! - - gr een but t on - - >

<st yl e t ype="t ext / css">

a {

col or: #FFFFFF;

f ont - f ami l y: Ver dana;

f ont - si ze: 10px;

f ont - wei ght : bol d;t ext - decorat i on: none;

t ext - al i gn: cent er;

paddi ng- l ef t : 3px;

paddi ng- r i ght : 3px;

}

</ st yl e>

<t abl e cel l paddi ng="3" cel l spaci ng="0" border ="1"

bor der col or l i ght ="#C0C0C0" bor der col ordar k="#808080"

st yl e="border - col l apse: col l apse" bgcol or="#008000">

<t r >

<t d><GEN: Li nkBut t on Name="But t on"/ ></ t d></ t r>

</ t abl e>

<! - - r ed but t on - - >


a {

col or: #FFFFFF;


f ont - si ze: 10px;

f ont - wei ght : bol d;t ext - decorat i on: none;

t ext - al i gn: cent er;

paddi ng- l ef t : 3px;

paddi ng- r i ght : 3px;

}

</ st yl e>

<t abl e cel l paddi ng="3" cel l spaci ng="0" border ="1"

bor der col or l i ght ="#C0C0C0" bor der col ordar k="#808080"

st yl e="bor der- col l apse: col l apse" bgcol or="#FF3300">

<t r >

<t d><GEN: Li nkBut t on Name="But t on"/ ></ t d></ t r>

</ t abl e>

Once created, these layout pages can be bound with the application

generator as shown here.



163

Using Iron Speed Designer to bind a reusable button.

Now you’re ready to use these buttons on a new page. To make that

page, create a new layout page, one that uses these buttons multiple

times, as shown below.

<di v al i gn="center" >

<t abl e cel l paddi ng="8" cel l spaci ng="0" border ="0">

<t r >

<t d><GEN: BUTTON Name="OKBut t on" FI LE=". . / Shared/ But t on. html " / ></ t d>

<t d><GEN: BUTTON Name="SaveButt on" FI LE=" . . / Shared/ Butt on But t on. html " / ></ t d>

<t d><GEN: BUTTON Name="Cancel But t on" FI LE=" . . / Shared/ But t on. html " / ></ t d>

</ t r>



164

</ t abl e>

</ di v>

Now bind each of the buttons on this page by specifying the button

text, the command name and the URL.

Generate the page and review the buttons displayed.

Simple page featuring reusable button panels bound differently for varying purposes.

Generating Navigation Menu Panels

Another extraordinarily useful aspect of this code reuse idea is its

ability to define a menu for your entire application and use it on

every page. Such menus can even incorporate different menu

choices based upon the context of the page, and yet, they’re only

defined once.

Such a feature can save a development organization hours and hours

of building and testing appropriate menu options for various pages

within an application.

The next several pages walk through a simple example of how

reusable menus are created with an application generator.

In this example, the menu is dependent on the page to determine the

currently highlighted menu item. To create a menu, we’ll first create

two layout files – one to display the normal unselected state and the

other to display the highlighted state. Next, we’ll create a menu

panel that includes all of the menu items you would like to display

in the application, and finally, we’ll include the menu panel on a

page.

The menus can be created using links or images. Depending on your

preference, you can use either of the two code generation tags.

So, the first step is to create the layout page for the normal

unselected menu item as shown here.

<t abl e wi dth=140 hei ght =14 bor der col or l i ght ="#FFFFFF" border col ordar k="#C0C0C0"

bor der ="1" bor der col or="#111111"

cel l paddi ng="0" cel l spaci ng="0" st yl e="bor der- col l apse: col l apse">

<t r >

<t d cl ass="Nor mal Menu" bgcol or="#000080" >

<GEN: Li nkBut t on Name="But t on"/ >

</ t d>

</ t r>

</ t abl e>



165

Once created, you need to bind the layout page using the


Iron Speed Designer binding a reusable navigation menu panel.

Then, you’ll need to create a layout page for the selected menu item

as shown here, and bind this as well.

<t abl e wi dth=140 hei ght =14 bor der col or l i ght ="#FFFFFF" border col ordar k="#C0C0C0"

bor der ="1" bor der col or="#111111"

cel l paddi ng="0" cel l spaci ng="0" st yl e="bor der- col l apse: col l apse">

<t r >

<t d cl ass="Sel ect edMenu" bgcol or="#000080" >

<GEN: Li nkBut t on Name="But t on"/ >

</ t d>

</ t r>

</ t abl e>

Now you’re ready to create a layout page (below) for the menu for

your application. The following layout page defines the specific

menu items needed in your application. The individual menu items

are specified using a GEN:Button code generation tag. If a different

style is

required

for

the

selected

menu

item,

then

two

GEN:Button

tags must be used for each menu. When the application generator

uses these tags, it will create code that automatically hides one of

them based on the currently selected menu item.


. Sel ect edMenu a {

col or : #FFFF00;






167

within each of the panel files. Browsers do not differentiate between

panels – since they receive one HTML file. As such, if the same style

is defined multiple times, the last definition is used. This results in

the selected and unselected menu items looking similar.

Now you’re ready to bind the Menu layout page using the


Iron Speed Designer binding a reusable menu panel.

The application generator will prompt you to bind each of the menu

item (button) tags and provide the menu text (button text), the

command, and the URL for both the normal and the highlighted

menu items.

Now that the menu panel has been created, it can be incorporated

into a page using the GEN:Use code generation tag. In the following

example, the layout page file includes a header panel, the menu

panel, and the products from the database.

<GEN: Use Name="Header " Fi l e="Header Panel . html " / >

<br >

<t abl e>

<t r >

<t d val i gn="t op">

<GEN: Menu Name="Menu" Fi l e=". . / Menu Panel s/ Menu. html " Type="Menu" / >

</ t d>

<t d val i gn="t op">

<GEN: Tabl e Name="Pr oduct s">

<t abl e cel l paddi ng="5" st yl e="bor der- col l apse: col l apse" bor der="1"



168

bor der col or l i ght ="#C0C0C0" bor der col ordar k="#C0C0C0">



<t d>

<GEN: Fi el dVal ue Name="Product I d" / >

</ t d>

<t d><GEN: Fi el dVal ue Name="Pr oduct Name" / >

</ t d>

<t d>

<GEN: Fi el dVal ue Name="Uni t Pr i ce" / >

</ t d>

<t d>

<GEN: Fi el dVal ue Name="Uni t sI nSt ock" / >

</ t d>

<t d>

<GEN: Fi el dVal ue Name="Di scont i nued" / >

</ t d>

</ t r></ GEN: I t emTempl at e>

</ t abl e>

</ GEN: Tabl e>

</ t d>

</ t r>

</ t abl e>

Once created, you’re then ready to bind the layout page with the




169

Iron Speed Designer binding the layout page featuring a reusable menu.

Now, you’re ready to generate the application, and preview the

page.

Generating Dynamic Context‐Sensitive Panels

This concept of defining parts of the application, and then reusing

those parts over and over again, represents an important advantage

of using an application generator. As you gain experience working

with an application generator, you’ll continually discover how you

can use the generator to increasingly automate the production of an

enterprise application.

Now that you’ve seen this powerful approach applied to the creation

of buttons and menus, we’ll look at an example of how application generation can apply the same idea to any aspect of the application

through reusable panels.

Beyond automating the production of pages that need the same

functionality, reusable panels can also be dependent on the parent

for information about the current content being displayed. For

example, if you would like to display an Employee record in the



170

same way on multiple pages, then the best way is to create a panel

that would display one record. This panel can then be used multiple

times on a page or even within a table. Note that the information

about which employee record to display will not be available to the

panel at design time; but rather provided to the panel at run‐time by

the page that includes the panel.

To demonstrate this idea, the following example shows how to

create an employee record panel, and then how to use that panel on

two different pages. The first page uses the panel twice to show

information about two employees side‐ by‐side. The second page

displays the employee panel within a table of employee records.

To get started, let’s create the employee panel layout page called

EmployeePanel.html. Once created, and bound to the data by the

application generator, it becomes easily reusable on any page.

<t abl e wi dt h=400 cel l paddi ng="5" st yl e="border - col l apse: col l apse"

bor der ="1" border col or l i ght ="#C0C0C0" border col ordar k="#C0C0C0">


<t d al i gn="l ef t " val i gn="t op">

<GEN: Fi el dVal ue Name="Phot o" / >

</ t d>

<t d al i gn="l ef t " val i gn="t op">

<GEN: Fi el dVal ue Name="Fi r st Name" / > <GEN: Fi el dVal ue Name="Last Name"

/ ><br >

<GEN: Fi el dVal ue Name="Addr ess" / ><br >

<GEN: Fi el dVal ue Name="Ci t y" / >,

<GEN: Fi el dVal ue Name="Regi on" / > <GEN: Fi el dVal ue Name="Post al Code"

/ >

<GEN: Fi el dVal ue Name="Count r y" / >

</ t d>

</ t r>

</ t abl e>

At this point, we’re ready to create a new layout page called

PageWithPanels.html (shown below). With two Gen:Use tags, this

layout page incorporates the employee panel twice to compare two

employee records side‐ by‐side. The name of the two tags will be

different, but they will both point to the same EmployeePanel.html

file.

<t abl e><t r >

<t d>

<GEN: Recor d Name="Empl oyee1">

<GEN: Use Name="Empl oyee1Panel " Fi l e="Empl oyeePanel . html " / >

</ GEN: Recor d>

</ t d>

<t d>



171

<GEN: Recor d Name="Empl oyee2">

<GEN: Use Name="Empl oyee2Panel " Fi l e="Empl oyeePanel . html " / >

</ GEN: Recor d>

</ t d>

</ t r>

</ t abl e>

Now that it’s created, we can bind the PageWithPanels.html layout

page. We’ll bind the Employee1 Record code generation tag to the

Employees table, and get the Id of the employee record from the

Emp1 URL parameter. We’ll bind the Employee2 Record code

generation tag to the Employees table as well, but this time, we’ll get

the Id of the employee from the Emp2 URL parameter.

Iron Speed Designer binding a layout file, and specifying the record ID with a URL parameter value.

We’re now ready to generate the application, and preview the page

with the following URL.

ht t p: / / l ocal host / Tut or i al / TUTORI AL%20PAGES/ PageWi t hPanel s. aspx?Emp1=1&Emp2=2

Page created with Iron Speed Designer, featuring two uses of the same panel for record comparison.



172

Note how easy it was to “re use” the panel within in the same page

by merely binding it differently within the application generator.

Now that it’s been created, this EmployeePanel.html can be used in

other layout pages. Let’s use the same panel to display a table of

employees. To accomplish this, we’ll create a page called

PageWithPanelsInTable.html. This page uses the GEN:Table tag and

the GEN:ItemTemplate code generation tags. The ItemTemplate

contains a reference to the EmployeePanel.html tag using the

GEN:Use tag. Note that the layout specifies a single reference to the

employee panel.

<GEN: Tabl e Name="Empl oyees">

<t abl e>


<t r >

<t d>

<GEN: Use Name="Empl oyeePanel " Fi l e="Empl oyeePanel . html " / >

</ t d></ t r>


</ t abl e>

</ GEN: Tabl e>

Now we’re ready to bind the PageWithPanelsInTable.html to the

database using the application generator. Here, we’ll specify the

Employees table as the source of the data for the GEN:Table code

generation tag.

Iron Speed Designer binding the GEN:Table code generation tag.



173

We’re now ready to generate the application, and preview the page

with the following:

URL. ht t p: / / l ocal host / Tut ori al / TUTORI AL%20PAGES/ PageWi t hPanel I nTabl e. aspx

Screen shot of page createdwith Iron Speed Designer thatincorporates the employee

panel into a table.

On this page, you’ll note that only four records were displayed.

Even as this simple application was created, the application

generator created the SQL query for retrieving the table, all the

cursor management logic, the pagination logic, etc. The result is that

four records contained in the table were displayed using the custom

panel we defined earlier, but we didn’t need to worry about the

query, cursors, pagination logic, or hundreds of other development

tasks normally associated with web application development.



174

Removing the complexity and the sheer amount of work normally

associated with reusable software components is a key advantage of

application generators.

In the next section, we’ll discover how this advantage can be

extended beyond templates, buttons, and panels to the world of

custom software components.

Automating Re‐Use of Custom & Third Party Controls

In many web application development scenarios, it’s common to

incorporate custom code into the application. These custom

components can be built internally, licensed from third parties, or

acquired from open source projects. Regardless of their source, such

components can provide functionality quickly and easily without

imposing additional development burdens (other than integrating

the code).

Some application generators provide a rich set of controls such as

tabbed menus, buttons, filters, and search boxes. In many cases, this

rich set of controls can be further supplemented by third‐party

controls and controls that you might have developed for other

applications. The ability to include other controls and tightly

integrate them with the application generator itself is a powerful

capability that allows you to build virtually any type of application

with ease.

When armed with such a feature, you are not limited to using

controls that

are

provided

by

the

application

generator,

and

can

even

utilize the application generator to better leverage your library of

software components.

Adding third‐party controls, grids, and other functionality to the

web pages generated by an application generator should be very

easy. By changing the layout page files or using custom panel files,

you can include whatever HTML, JavaScript, and server‐side code

you want in a page or composite component, including applet tags,

etc.

Third‐party controls can be incorporated as independent controls

included on the page or as controls that receive their data from the

database. To retrieve the data from the database and populate a

third‐party control, you should be able to use any of the application

layer classes provided by the application generator.



175

Example: Integrating a Third Party Control

Including an independent third‐party control within a page you

create should be fairly simple. You should be able to embed any

control in the HTML layout page and have it passed through to the

generated

page

un‐

altered.

Such

a

feature

would

allow

you

to

incorporate any ASPX control into your layout page or page

template.

In the following simple example, Iron Speed Designer only pays

attention to the GEN: code generation tags and only replaces those

tags with references to the relevant controls. This control integrates

into the layout page, but does not use any data from the database,

utilize any code generation tags or use any of the generated classes.

The third‐party menu control used in this example is from

CyberAKT. This third‐party menu control allows you to incorporate

many different types of menus into your application with ease. Some sample menus and tabs available from CyberAKT are shown

below:



176

The ASPNetMenu third‐party control works by putting an ASP

control in your layout page and specifying the list of menu items in a

separate XML file. The following steps demonstrate how to integrate

this independent third‐party control into pages created with an


As a first step, let’s create an HTML layout file for the reusable panel

called PageWithThirdPartyMenu.html. This layout page contains an

@Register directive to register the ASPNetMenu followed by a

reference to the control. The DLL for the ASPNetMenu must be

placed in the Bin directory of the application.

<%@ Regi st er TagPref i x="cyber akt " Namespace="CYBERAKT. WebCont r ol s. Navi gat i on"

Assembl y="ASPnet Menu" %>

<l i nk hr ef ="menuSt yl e. css" t ype="t ext / css" r el ="s t yl esheet " >

<! - - Thi s t hi r d par t y cont r ol i s avai l abl e at ht t p: / / www. aspnet menu. com

- - A sampl e DLL f or t hi s menu i s pl aced i n t he bi n f ol der of t hi s Tut ori al- - appl i cat i on.

- - The sampl e DLL i s onl y f or demonst r at i on pur poses. You wi l l need t o

- - l i cense the t hi r d par t y l i br ar y f r om t he Cyber AKT - t he manuf actur er of

- - ASPNet Menu.

- - The MenuData. xml f i l e contai ns t he menu names and t he URL' s. For more

- - i nf ormati on about t he menu cont r ol , pl ease vi si t t he ASPNet Menu. com si t e.

- - >

Without doing anything else other than putting the configuration

XML files and DLLs the control needs in the right place, you can

generate the application and preview the page.

Example: Integrating a Third Party Control with the Database

A more complex and more powerful example of a third‐party control

is a tree control similar to the one used within Windows Explorer. In

the context of a database intensive web‐application, such a tree

control is only useful when integrated with the underlying data.

Application generators should always allow such controls to

integrate into the applications they create, and make it easy to

leverage that integration in new applications once the set‐up is

complete.

The following example shows how to integrate a third‐party tree

control into a generated application. The tree control is initialized

with data from the database and the navigation URL’s are set based

on the Id’s of the records retrieved from the database.

The integration of third‐party controls can be accomplished in many

different ways. In this example, the integration is accomplished by



177

writing Visual Basic code and including it in HTML layout page.

This code will be included in the ASPX page created by the

application generator, and executed on the server to create the tree

control.

This example also uses a frame based window to show a top frame

and a left and a right frame within the bottom frame for the

generated application.

A screen shot of an example application created with Iron Speed Designer & a third party tree control.

To make this sample application, we’ll need to create the ASPX files

necessary to display the frame based window. This file specifies the

top frame, a left side frame and the right frame to display the

selection from the left frame. This file is created directly as ASPX

pages.

Our main task is to create the page to display the tree view in the left

frame. This page is created as a HTML layout file with Visual Basic



178

code as shown below. We’ll discuss the most important aspects of

this code right after presenting it.

<l i nk hr ef ="/ Desi gner / St yl es/ Desi gner . css" t ype="t ext/ css" r el ="st yl esheet ">

<%@ I mpor t Namespace="obout_ASPTr eeVi ew_Pr o_NET" %>

<scr i pt l anguage="VB" r unat="ser ver" >

Publ i c Funct i on Cr eat eTr ee( ) As Str i ng

Di m oTree As New obout _ASPTreeVi ew_Pr o_NET. Tree( )

oTr ee. ShowI cons = Fal se

oTr ee. TreeI cons_Path = " / Desi gner/ I mages"

oTr ee. Add( Not hi ng, "r oot" , "Pr oduct s by Categori es")

Di m html

Di m cat Records As Ar r ayLi st = Categor i esAccess. I nst ance. GetLi st ( _

Nothi ng, _

Nothi ng, _

0, 20, Nothi ng)Di m prodCatFk As I r onSpeed. Base. Data. Forei gnKey = _

Product sAccess. I nst ance. Tabl eDef i ni t i on. GetForei gnKey( _

Product sAccess. I nst ance. CategoryI DCol umn)

Di m catRecor d As Cat egori esRecor d

For Each catRecord I n cat Recor ds

Di m cat I d As St r i ng = "catI d" &

catRecor d. GetSt r i ng( Categori esAccess. I nst ance. CategoryI DCol umn)

Di m cat Name As Str i ng = catRecord. GetCategoryNameFi el dVal ue( )

oTr ee. Add( "r oot" , cat I d, cat Name)

Di m f As New I r onSpeed. Base. Data. For ei gnKeyVal ueFi l t er( _ pr odCatFk, _

cat Recor d. Get I D( ) , _

I r onSpeed. Base. Data. BaseFi l t er. Compari sonOperat or. Equal s)

Di m pr odRecords As Ar r ayLi st = Pr oduct sAccess. I nst ance. GetLi st ( _

f , _

Nothi ng, _

0, 20, Nothi ng)

Di m prodRecord As Pr oduct sRecord

For Each prodRecord I n prodRecords

Di m pr odI d As St r i ng =

pr odRecor d. GetSt r i ng( Product sAccess. I nst ance. Product I DCol umn)

Di m prodName As St r i ng = prodRecord. Get Product NameFi el dVal ue( )html = "<a hr ef =' Vi ewProduct . aspx?Product s=" & prodI d & " '

t arget=' Ri ght Fr ame' >" & prodName & "</ a>"

oTr ee. Add( cat I d, "prodI d" & pr odI d, ht ml )

Next

Next

Return oTree. HTML( )

End Funct i on



179

</ scri pt >

<t abl e border ="0" cel l paddi ng="2" cel l spaci ng="0" st yl e="bor der- col l apse: col l apse"

bordercol or="#111111" i d="AutoNumber1">

<t r >

<t d>

<ASP: Label i d=" i Tree" r unat =ser ver t ext="<%# Cr eateTree( ) %>" / >

</ t d></ t r>

</ t abl e>

At the bottom of the file, the Tree View is displayed as an ASP:Label

as recommended by the developer of the tree control. The text of the

label is specified by the CreateTree function.

<ASP: Label i d=" i Tree" r unat =ser ver t ext="<%# Cr eateTree( ) %>" / >

The CreateTree function defines an array of all categories by using

the CategoriesAccess class generated by Iron Speed Designer. This

class is generated when you link to the Categories table and generate

the application. There is no additional filter criteria specified, and as

currently implemented, it only retrieves the first 20 records.

Di m cat Recor ds As Ar r ayLi st = Cat egor i esAccess. I nst ance. Get Li st ( . . .

Note that the code iterates over the categories records retrieved in

the catRecords array list and added to the tree control. The parent of

this category node is the root node.

Di m catRecor d As Categori esRecor d

For Each cat Recor d I n catRecor ds

Di m cat I d As St r i ng = "catI d" &

catRecor d. GetSt r i ng( Categori esAccess. I nst ance. CategoryI DCol umn)Di m catName As Str i ng = cat Recor d. GetCategoryNameFi el dVal ue( )

oTr ee. Add( "r oot ", cat I d, cat Name)

The foreign key (created earlier) is transformed into a filter that can

be used to retrieve the products that match this key.

Di m f As New I r onSpeed. Base. Data. For ei gnKeyVal ueFi l t er( _

pr odCatFk, _

cat Recor d. Get I D( ) , _

I r onSpeed. Base. Data. BaseFi l t er. Compari sonOperat or. Equal s)

The final step is to create an array list of products for the current category within the For loop. Currently, this list only shows the first

20 products belonging to the category. You can increase this count

to a very large number to retrieve all products. The GetList function

for the RecordAccess class is used to create an array list. For each of

the products found for the category, a specific HTML link is created

and the product is added to the tree with the parent as the category.

For Each pr odRecord I n pr odRecords



180

Di m pr odI d As St r i ng =

pr odRecor d. GetSt r i ng( Product sAccess. I nst ance. Product I DCol umn)

Di m prodName As Str i ng = prodRecord. GetProduct NameFi el dVal ue( )

html = "<a href =' Vi ewProduct . aspx?Product s=" & prodI d & " '

t arget=' Ri ght Fr ame' >" & prodName & "</ a>"

oTree. Add( cat I d, "prodI d" & pr odI d, ht ml )

Next

This code iterates over the table, retrieves the product name

contained in each record, and uses that name when displaying the

leafs in the tree control. Further, as it creates each leaf, it also embeds

a link that passes the product name as a URL parameter to a

generated page (ViewProduct.aspx), and targets that page to the

right frame. Once this application is deployed, users will click on

specific leaves displayed in the tree control on the left, and the

correct records will be displayed on the right.

Summary

This chapter introduced the notion of extending application

generation technology to automate the production of custom,

enterprise‐class, web applications. We looked at several aspects of

how this can be accomplished with reusable page template, layout

pages, and panels, buttons, menus, components. We also explored

how this concept extends to custom code, and demonstrated some

examples in the form of third party controls.

Utilizing application generators makes code re‐use pragmatic and

easy. As such, IT departments can begin to realize productivity

gains that have been promised for decades. Original expectations

surrounding code re‐use were lofty only because of the pragmatic

limitations of development tools.

Now that these limitations are being removed, IT is entering a new

era of increased productivity, improved responsiveness, and greater

business impact. In the next chapter, we’ll discuss how you can

initiate this transition for your organization.



181

Part 10)

Looking Ahead

Application Generation Projects

With Maximum Impact



182

Looking back, we’ve discussed the need for application generation,

the background of technological developments leading to it, the

architectural philosophy behind it, and a myriad of technical

advantages and examples based on Iron Speed Designer.

This last

section

provides

some

hints

about

selecting

your

first

project for application generation, and then rolling out the

technology to your organization based on your initial success. We’ll

also touch upon the broader impact application generation can have

upon your business.

Selecting Your First Project

By this point, you’re probably eager to get started on a project with

an application generator. In selecting that first project, it’s to your

advantage to choose a project where you can build and deploy

something valuable,

and

deliver

it

quickly.

Consider

the

following

attributes of the application when choosing your first project.

Size & Scope

Ideally, your first project will be “smallish” in nature, and allow you

to build and deploy your first application in a couple of days. This

means your first application could involve just a few database tables.

Further, selecting a first project with limited complexity is a good

idea because of the momentum it can create for you and the

technology. Delivering a solution with speed is exciting, especially

since it exceeds current expectations, and contradicts past experience.

The last thing most organizations expect is a quick solution in the

form of a robust web application. Memories of past experiences with

web application development often include delays, cost overruns,

missed expectations, and overall disappointment. In fact, some

organizations toss out web applications as potential solutions to

business problems because of these painful past experiences.

Therefore, if you can start and finish a successful effort quickly,

you’re sure to generate positive interest in your efforts, rekindle

positive thinking about custom web applications, and accelerate

broader adoption of your techniques.

Existing Databases & Integrity

If your first application can be based upon an existing database,

you’ll be able to realize the benefits of your efforts almost

immediately. Further, if that database has good quality and integrity



183

(meaning that the data is clean and mostly error‐free), again, you can

begin to realize the benefits of your efforts without getting bogged

down in data cleansing or repair efforts.

As previously discussed, a first project should attain success quickly.

By utilizing existing databases, your project leverages database work

that’s already been done. If the data is of high quality, you

inherently avoid problems associated with data that’s stale,

incomplete, or inaccurate. Avoiding these problems, on your first

project, is important if you want the perception of the first project to

be on you and the approach you used, not necessarily the problems

that needed to be corrected anyway.

Limited Integration / Customization Work

While we’ve emphasized that applications created with application

generators can be integrated with other applications and extended

with custom

functionality,

many

development

scenarios

don’t

require this work. In such situations, it’s entirely possible that you

can build and deploy an application that solves a business problem

in just a day or two.

There are many examples of first projects where the primary

objective of the application was merely finding data in the database,

displaying it via the web, and allowing a set of users to maintain that

data more quickly and easily than before.

Often times, these applications are created from legacy applications

that were created with end‐of‐life technology (such as old client‐

server style applications held over from the 1980’s) or have

outgrown their existing architectures (Microsoft Access systems that

started out being used by a single user, that are supporting hundreds

of users).

Both of these applications are great first projects because the primary

value they provide is in finding, maintaining, and reporting the data.

They can be built and deployed with great speed, rely on production

data that’s already been created, and typically involve no code

extensions or customizations.

Clear Impact

&

Benefit

While this is an obvious characteristic, it’s so important that it’s

worth mentioning here. Any application you build should make

something easier, faster, more reliable, or more convenient for the

user community of the application.

Merely redeploying legacy database applications via the web can

reshape the impact they have upon the business. Even if such



184

applications are only used internally, remote access can empower

employees that travel to customer sites to still access data back at the

home office. Often times, however, these internal‐use‐only

applications are re‐thought to embrace access by customers and

suppliers as well.

The benefits of sharing information with customers and suppliers via

the web has been embraced by the industry and documented in

many other texts, so there’s no reason to belabor the point here.

Until now, however, custom enterprise applications have been slow

to take advantage of these benefits because of the costs associated

with developing and maintaining these applications. Application

generation technology empowers organizations to rethink how their

suite of internal applications could be recast as web applications, and

extended to better serve customers, suppliers, and other sets of users

in the community.

Neglected User Community

Speaking of users, let’s remember custom web applications are

expected from every community of users touched by an

organization. Some of the best first applications we’ve seen are the

applications that IT typically doesn’t have time or resources to

prioritize. Once such an application is built and deployed, these

users who have been neglected the most can become most

enthusiastic about the new application. Some times, they’ll even

become pro‐active advocates and evangelists for the person or

organization that delivered the new solution.

Having an enthusiastic user community behind your first

application, even if it’s a small one, can be a great asset when you’re

ready to rollout the technology to others in your organization. More

cautious user communities will want to check references, and

understand the experiences of the first users to benefit from your

approach. With such references in place, positive decisions about

future projects can be accelerated.

Keeping these characteristics in mind, let’s take a quick look at three

recent examples where developers chose to apply application

generation technology.

First Effort Case Study: Otis Elevator

Otis Elevator Otis Elevator Co., a wholly‐owned subsidiary of

United Technologies Corporation, is the worldʹs largest

manufacturer, installer, and servicer of elevators, escalators, moving

walkways and other horizontal transportation systems.



185

The Business Applications Systems Management development team

at Otis Elevator in Sydney, Australia looks after the development of

all the local business‐related software applications for all the offices

in Australia and New Zealand. More than 1,300 people rely on this

team to provide the database management and software solutions

they need to do their jobs most efficiently. Using Iron Speed

Designer, two programmers new to .NET were generating working,

custom web applications in a few hours.

Reflecting an evolutionary path over the years, the team manages

applications running on a myriad of platforms ranging from

Natural/Adabas to NT4/APPX to client server to n‐tier systems using

Visual Basic, ASP and SQL Server. The local team has lots of

experience optimizing and expanding applications on these legacy

systems.

Beginning in 2003, however, when looking to move legacy

applications to the web and the Microsoft .NET Framework, the

team faced a tricky migration challenge. The problem was that a

couple of internal applications were needed quickly, and there

wasn’t much time for training or practice.

Otis chose this challenge as their first application generation project.

ʺWe were very productive using a 4GL repository‐ based

development tool before we moved to Windows, so I knew the

benefits of code generation could be impressive. I checked out

several contemporary code generators for .NET and was encouraged

to learn that vast improvements have been made in terms of

generated code quality, the ability to customize the user interface

and to extend generated applications so that multiple apps can be

connected,ʺ the team leader explained.



186

ʺWhat I didnʹt expect to find was how easy it is to use. That opened

my eyes to a whole new transition strategy for my team. Rather than

hiring consultants, I could meet my deadlines and keep the learning

and expertise in‐house. Even if we were all .NET experts, it would

still take us three times as long to launch compared to using this

tool,ʺ he said.

ʺI have always believed in code generation, but there were very few

products over the years that I thought generated the entire

application well enough to be useful. We need a tool that very

quickly can generate the interface and application layer based on

complex database schemas. We wanted lots of flexibility and the

ability to customize every part of the generated application when

required,ʺ he said. ʺIʹm generating high quality code that we are

proud of, and allowing my team to focus on custom coding, not

infrastructure.ʺ

ʺWe are using application generation for all new Web‐ based

development projects. Our strategy is to migrate to our Intranet some key functions used by large numbers of users now performed

in legacy systems over the WAN. This technology is instrumental in

our achieving this.ʺ

ʺApplication generation helps us launch faster and with added

functionality. Weʹre being productive on .NET while maintaining

our output level.ʺ



187

First Effort Case Study: Les Schwab Tire Company

Les Schwab Tire Company operates a network of over 400 retail

locations that generate over a billion dollars in annual revenues. The

company is one of the largest independent tire companies in the

United States.

For years, every one of the store managers and assistant managers at

each of the retail stores updated the intranet data by emailing or

faxing information to the IT team, and then waited for them to have

time to input the data. Since this was just one of many document‐

centric activities at the company, the IT team was moving everything

to IIS and the .NET Framework in order to automate functions,

improve service to store management, and save time and money on

all ends of the process.

They needed a quick way to build editable ASP.NET forms to

transform a clunky, manual (but high visibility) performance

tracking process into a smooth web‐ based application.

Les Schwab Tires chose this challenge as their first application

generation project.

They chose their application generator and ended up with the forms,

all the SQL and the rest of the application in a couple of hours. The

production web application launched a day later, much to the

delight of users located in hundreds of different offices.

ʺ

We

were

using

Visual

Studio

.NET

Enterprise,

and

I

quickly

realized that building an editable data grid was hard,ʺ the team lead

said. “I went looking for a helpful tool and found an application

generator.

ʺI downloaded it and saw immediately that this was much more

than just limited components, this was really the answer,ʺ he said.

He used the application generator to quickly create an entire custom

application that linked to his current SQL Server database. Since it

was a pretty simple application involving just thousands of records,

a couple of multi‐table joins and one editable form with various

report views, the whole application was generated in a few hours. No code extensions were needed. The developer showed it to the

rest of the development team that same day and launched it to

employees the next.



188

ʺI started out thinking I just wanted an online form,ʺ the lead

developer said, ʺI found a lot of functionality in the tool that enhanced our original goal by creating new database tables,

changing the page controls, sorting and filtering, and adding custom

controls on the view report page. A painful, four‐step, manual

process is now one step, and automated!ʺ

ʺWe basically deployed the Visual Basic .NET code that the tool

generated. The generated code is smooth and sophisticated and fit

right into our network. We very quickly solved a high‐visibility

challenge, and, in fact, made a manual process simpler and more

effective for everyone involved.ʺ

Like many developers, this team evolved from mainframe roots to

application development on the .NET Framework. As the shop has

moved to adopt modern methodologies, several code generation and

component tools have been evaluated and abandoned along the

way. “The system was proprietary or too complex or the generated

code was bulky and slow, and hardly useful,ʺ the team lead said of

some of the other tools tried. “We are looking for advanced features.

We need tools that work in our current environment.ʺ

ʺI have three criteria for any tool,ʺ he said. “It has to work with my

other tools and platforms; it has to be able to deploy what is

promised in working, quality code; and I need to be able to get help

from the vendor if and when I need it.

ʺGetting anything sophisticated on the .NET Framework is great, but

what we really need on the ground right now are tools that make

.NET more usable.ʺ



189

ʺWe havenʹt even scratched the surface of this toolʹs power. The

generated code is rock solid and it deploys on .NET without a hitch.

Iʹm planning to use it for more and more complex applications going

forward.ʺ

First

Effort

Case

Study:

Open

Latitude

Open Latitude enables consumer products companies and their

partners to improve on‐time delivery and out‐of‐stock performance

by helping their customer teams manage fulfillment across the

extended enterprise. Using Open Latitude mPower, customer teams

can identify potential customer service issues early, assess the effect

of those issues on key customers, and take coordinated action across

departments and the extended enterprise to resolve issues.

Here, the team lead is a professional developer who writes large

scale, mission‐critical web‐ based applications for companies

developing CRM and supply‐chain products. “What I like to focus

on is building applications that the customer will want to use,” he

said.

In early 2003, the development team faced a tight deadline to deliver

a robust product release. Open Latitude chose this project as their

first application generation project.

“Using the application generator really compressed our

development cycle,” he said.

ʺ

The

application

generator

gave

us

a

lot

of

utilities

with

no

run‐

time

drag. We got search, pagination, navigation and other standard

page controls, transaction management and all the SQL statements

for free. It saved us weeks of not having to worry about building

those features.ʺ



190

“The standard template user interface can be easily customized and

that saved us a lot of work. We put in our own style sheet and are

using this as our final design. Much simpler, and much more flexible

than doing it all by hand,” the team lead said.

“A lot of world‐class applications and products are being developed,

but no

one

can

afford

to

spend

a year

or

more

on

development

anymore. You have to be fast in developing and deploying. And,

you have to be very responsive to customer needs.”

“When you use a code generator, you can concentrate your efforts on

building the business logic,” he said. “Using an application

generator freed us to make our product even more robust and

relevant to our customer’s needs.ʺ

He also found that generated code relieved him and the team from

the pressures of code freeze. “Sure, once you know the design,

building something is pretty straightforward,” he said. “But in

product development, the requirements are constantly changing.

The time it takes for us to turn around and add something back in is

incalculable and used to spell death for on‐time delivery.”

ʺApplication generators reduce the overall timeline, but they also let

me go back, make changes to page controls, layouts and features and

quickly regenerate. In the past six months, the application generator

has allowed us to go through a number of engineering design



191

iterations, all of which help make our product stronger for

customers. Now, I’m stretching the tool to the limit and

implementing all sorts of new ideas without restriction.”

“I’m letting my imagination take charge. I now know I can adjust to

meet the needs of my customers and the end‐users, regardless of

where we are in the development cycle.”

First Effort Case Study: Texas Youth Commission

The Texas Youth Commission is a state agency in Dallas that helps

protect, rehabilitate and guide young people in the juvenile justice

system.

The IT team helps Texas state employees work more efficiently by

automating manual systems and processes with easy‐to‐use web‐

based applications.

“Folks are used to whatever manual process they have been doing.

A web application has to do more than just deliver full functionality

and save time. It has to comfort them early in the process so that

they buy in and support the development and deployment,” the

team lead said.

The IT team helps employees in the finance department make sense

and act upon data that comes from multiple state and external

systems. With 14 facilities throughout the state, and highly

confidential information being passed intra‐agency and through

other

state

agencies,

IT

must

incorporate

all

the

data

into

a

common,

mission critical set of applications that serves a diverse set of users.

“I use an application generator to quickly generate the entire

transactional side of the application, as well as add page controls and

filters for reports,” the team lead said.

“First thing I do is generate a sample application using the default

screens that the tool generates. This is just a few quick tables with

simple functionality. It takes me about 15 minutes to generate them.

But it’s a working application.”

“I approached application generation with caution. I used code

generators years ago and was never satisfied. With the application

generator, I’ve stopped worrying about the generated code. I’m

focused instead on the other eight applications on my plate that it

can help me build,” he said.

“I’ve used every facility I can: customizing transaction management

and SQL statements, linking to multiple databases, formatting, child



192

tables, detailed edit record forms, pre‐selecting field values in a

details page, inserting tables, multi‐table joins, adding buttons,

searching categories, various reporting, code extensions… it’s all

there,” he said.

“It would have taken me maybe two months to do this right ‐‐ to

make it enterprise‐class. Using the application generator, it was

about two days, including my customizations,” he said.

“I’m a one‐man team and I really needed the help. I’m up to my

neck in it now. I’m able to tackle more projects, confirm even tight

project schedules with more confidence and be more creative.”

Organizational Rollout of Application Generation Technology

Once you’ve built and deployed your first application, and you’ve

created an enthusiastic end user community, you’ll be ready to roll

out application generation technology to others in your organization.

Basic Rollout Essentials

When entering this phase, there are a few basic assets you can create

to help other developers in your organization benefit from your

experiences. Consider creating the following assets for the rollout:

Case Studies

Case studies document your experience building the application and

help

other

developers

understand

what

you’ve

done.

Typically,

a

case study describes the problems the application addresses, details

the technical approach, and documents the impact. Case studies can

be created in a variety of formats including white papers,

presentations, even videos. Whatever the form, capturing the facts

that surround the first success is an essential step in rolling out any

new technology. Sometimes, the vendor of a tool or technology that

was used in creating the application can provide assistance in

creating these case studies.

Guest Accounts

Since this new technology involves web‐ based enterprise

applications, it’s often quite easy to create a special guest account for

developers that are interested in seeing the software you’ve created.

With a small amount of effort, you can create a user role that can

grant others access to your application, allow them to see what

you’ve done, and still restrict them from having any actual impact

upon the production data.



193

Resource Web Page

Another asset to consider creating is a resource web page for your

project. Link to resources you found helpful in learning about

application generation and creating your first application. Such a

resource page can save other developers hours of effort. Such pages

are also a great place to share case study papers, presentations, and

videos. They can also describe how to apply for a guest account, or

include source code for the application you’ve created.

Internal User Group Presentations

If your project generates a lot of interest within your organization,

you might consider forming an application generation user group.

Such an organization can facilitate interaction between people

interested in the technology, and let participants learn from each

other.

These assets will help developers throughout the organization

understand and adopt application generation technology. This effort

lays the foundation for advantages reserved for those IT

organizations that fully adopt the technology.

Advanced Platform Possibilities

Once developers have been introduced to the notion of application

generation, and have had the chance to build and deploy an

application or two, your organization will be ready to introduce

company‐specific assets that promise can make IT development even

more efficient.

User Interface Standards

Using page and layout templates that have been customized for your

organization, you can strongly encourage user interface standards

compliance through application generation. As previously

mentioned, once these files have been created, it’s actually easier to

comply with the standard than to deviate from it.

Database Standards

Application generators help alleviate bottlenecks associated with

building data‐intensive web applications. Implicitly, they enforce

integrity for SQL queries, and can explicitly enforce preferences for

custom SQL statements and data validation logic. When using a

properly configured, high‐quality application generator, database

administration responsibilities in support of web application

development efforts is greatly simplified.



194

Code Re‐Use

Once an application generator has been configured to incorporate

custom code, all future applications that it creates can include this

custom code as part of the generation process… with no additional

work. Again – this approach makes it much easier for developers to

re‐use code than to re‐write it.

Architectural Standards

Since application generators shoulder most of the burden of creating

an application, they deliver applications that conform to a consistent

and state‐of‐the‐art architecture. As the number of applications built

increases, maintaining a consistent and standard architecture across

all applications will reduce complexity, and hold down end user

support and training expenses.

Enabling a New Kind of Development Team

Once in place, application generators that have been fine‐tuned to

the needs of the organization can empower more people, even who

have not traditionally been involved in development, and enable

those people to make a real contribution to the development effort.

In the early days of personal computing, the first non‐developer

developers were similarly empowered by VisiCalc. For the first

time, professionals that had not been trained as computer scientists

were able to customize the first spreadsheet tool for a specific

purpose. Later, tools like Lotus 123 and Microsoft Excel took these

initial capabilities to new and extraordinary heights. Today, these

spreadsheet power users can create applications that do

extraordinary things without writing any code other than macros.

Development of enterprise web applications is on a similar path.

Today, while it’s still not quite pragmatic for non‐programmers to

build and deploy database‐intensive web applications, it’s certainly

possible. Application generators dramatically simplify the

development effort associated with this task, and automate much of

the effort. As a result, business analysts, software architects,

marketing staffers, and others are now able to create and deploy

basic web applications.

Organizations that recognize this fundamental shift in how such

projects can be staffed will be able to organize their efforts in a new

way. They’ll leverage non‐technical professionals early in the

development process by arming them with application generation

technology. This new class of developer will enable IT to cater to

more needs of more users. Instead of merely gathering requirements



195

and writing functional specifications, these professionals will create

and share working applications with end users.

In many cases, the simple applications they create will be adequate.

In some cases, these first pass applications will require integration or

customization, and those will be passed on to more senior

developers to complete.

The New Reality:

Competitive Advantage Requires Ubiquitous Custom Software

As IT departments empower less‐technical professionals to

contribute significantly to application development projects, they

will be able to scale their efforts. This streamlined, productive, and

powerful software development capability will enable IT to once

again meet increasingly higher expectations from everyone who

interacts with

the

business.

The Rise of “Nano” Applications

In recent years, the user community of online business applications

has dramatically increased. Back in the old days, client/server style

applications were reserved for internal employees. Even their use

was restricted to particular role or purpose.

In the 1990’s, during the last days of the client/server era, the

emergence of ubiquitous network connectivity and protocol

standards facilitated an unprecedented explosion of network‐

connected business applications. In the span of just a few years, the

internet revolution combined with Y2K‐related upgrades to recast

nearly every aspect of IT strategies and priorities. Everyone’s

expectations about the ubiquity and potential of web‐ based

applications skyrocketed.

But along with these expectations, development costs also

skyrocketed. Eventually, IT managers (or their bosses) realized that

it cost an extraordinary amount of money to build and maintain

these applications. As a result, they cut spending, and most never

realized those lofty original expectations.

The lessons learned were painful but commonplace. Using the

development tools and techniques of the last century, data‐intensive

web applications took too long to build, cost too much money, and

were too hard to maintain and enhance over time. Once faced with

this reality, development plans were shelved for all but the most

critical applications, and even then, conservative ROI analysis

became a strict prerequisite for every proposed development effort.



196

But now, it’s time to revisit those plans.

Today, developers are no longer shackled with the development

tools and methodologies of the past century, and can reliably depend

on application generation technology to shoulder most of the

development burden. As a result, a whole new class of enterprise

web application is about to emerge.

This new class of applications will be transaction‐intensive, automate

a specific business process, and change in step with the business.

And there will be thousands of them.

Business users will drive the development priorities, and developers

will cater to their needs quickly and easily, and discover improved

business processes along the way. Interaction between business

users and developers, and the speed with which they collaborate to

improve business

software

systems,

will

become

the

central

competitive issue of the day.

Enabled by new technology, small, specialized, and ubiquitous – this

new class of applications promises to be the software equivalent of

nanotechnology— hence the term “nano‐web” applications.

Nano‐web applications are economically feasible primarily because

of application generation technology. It won’t take weeks or months

to build these applications – but only days. Still – they’ll be feature‐

rich, stable, and secure.

As organizations become adept with the new technology, a huge

wave of special‐purpose applications will appear. Yesterday’s era of

costly, big, monolithic, centralized, IT projects will morph into a

distributed, efficient, networked, ever‐dynamic user‐driven age. The

original vision of internet applications being available to assist in

automating every business process will be resurrected, realized, and

even expanded upon.

Earlier in this chapter, we discussed several examples of applications

that are indicative of this impending sea change. Here at Iron Speed,

we’ve already seen hundreds of other nano‐web examples. By the

time you

read

this,

there

will

be

thousands,

or

hundreds

of

thousands, more.

Of course, the responsibilities for managing this transition will fall

onto today’s IT departments and developers. During the transition,

they will still face demands from internal users, and will also need to

find ways to accommodate increasing demands from customers,

employees, and even suppliers. Further, each of these distinct user



197

groups will need different kinds of access to different kinds of data,

and their needs will be constantly changing.

These challenges will require IT to adopt development strategies,

methodologies, and tools that are designed to support an “always

on” environment that’s constantly changing. Armed with

application generation technology, IT will not only cope with, but

lead the transition.

Those who are slow to adopt the new technology will struggle. The

common historical approach of buying an off‐the‐shelf software

package, and then customizing it in a traditional fashion, won’t be

adequate. By the time such software is installed, configured, and

customized, it will be typically obsolete (even with the support of a

well‐intentioned and capable vendor). Downstream, when the

vendor’s development path diverges from your requirements (or if

they go out of business), such an approach becomes even more

untenable.

The Application Generation Future

As application generators produce more and more successful custom

applications, IT departments will increasingly opt to regain control

of the source code powering their organization. By adopting

application generation technology, these organizations will build

and deploy more and more database‐intensive web applications,

better cater to growing user communities with constantly changing

requirements, and do it all faster than ever before.



198

Contact Iron Speed

You can get started with application generation technology today

with

free

evaluation

software

from

Iron

Speed.

To

download

the

software, visit our website at www.ironspeed.com or contact us via

email at [email protected].

We welcome your comments on this document as well as ideas for

future topics. Please email us at [email protected].

Iron Speed, Inc.

1953 Landings Drive

Mountain View, CA 94043

1 650 215 2200

email: [email protected]



199

About the Author Alan Fisher is a noted expert in commercial software development

and

a

successful

entrepreneur.

Currently,

he’s

Chairman

of

Iron

Speed, Inc., an innovative provider of .NET programming tools. The

company’s flagship product, Iron Speed Designer, is widely

recognized as one of the leading application generators available

today.

Prior to co‐founding Iron Speed, Fisher was a General Partner at

Outlook Ventures, a venture capital firm. While there, Fisher led

early‐stage investments in a variety of software, infrastructure, and

e‐commerce start‐ups. Today, Fisher serves on the Board of

Directors of Infodata Systems Inc., (NASDAQ:INFD), an electronic

document management consulting services company and previously

served on the boards of Onsale (N:ONSL), Egghead Software

(N:EGGS), and Fatbrain (N:FATB).

Before joining Outlook Ventures, Fisher co‐founded Onsale, Inc., and

was its Chief Technology Officer. As the first auction‐style e‐

commerce business on the internet, Onsale experienced meteoric

revenue growth completed a successful public offering in 1997,

acquired Egghead Software in 1999, and was eventually acquired by

Amazon. During his tenure, Fisher led a technical team of over a

hundred developers that created and managed an e‐ business

infrastructure that managed tens of thousands of transactions per

day.

At the

time,

Onsale

was

the

largest

e‐commerce

application

ever built.

In the late eighties and early nineties, Fisher co‐founded and was

President of Software Partners, Inc, a developer and publisher of

award‐winning desktop software products. Products built by

Software Partners included Timesheet Professional , and a hit series of

financial services applications marketed under the StreetSmart brand

by Charles Schwab.

Earlier in his career, Fisher played a variety of technical and

marketing roles at Teknowledge, Inc., a pioneering developer of

artificial intelligence software products. During his tenure, Teknowledge commercialized some of the first products and services

to incorporate fundamental software concepts such as object

oriented design, rapid prototyping, and iterative development

methodology. While at Teknowledge, Fisher authored CASE:

Computer‐ Aided Software Engineering , the first book on this area of

software engineering, in 1989.



200

Fisher began his career on the technical staff at AT&T Bell

Laboratories where he worked on commercial videotext applications

and expert systems. He earned his B.S in Electrical Engineering from

the University of Missouri and earned his M.S in Electrical

Engineering from Stanford University.



201

Index

.NET

Directives .................................................156

.NET cache......................................................92

@Register directives.....................................156

{0} redirect argument ..................................133

100% Access to Generated Code..................67

1980’s

IDE’s ...........................................................23

1990’s

Application Servers ..................................24

3‐tier architecture...........................................62

A Very First Step

A Functional, Bug‐Free Application ......44

About the Author ........................................199

Acknowledgements.........................................3

Active Directory and LDAP.......................117

Add record pages ..........................................34

Adding a New Record to a Database Table

.....................................................................81

Adding a Reusable Panel to a Page...........160

Adding Third‐Party Controls and

Components.............................................174

Additional Security Issues to Address .....116

ADO.NET .................................................85, 93

Advanced Platform Possibilities................193

Algorithmic Approach..................................60

An Approach to Generating Extendable

Code..........................................................125

Application

Sign‐in ......................................................114

Application generation .................................13

Application Generation Future..................197

Application Generation Process ..................82

Application generators .............26, 55, 92, 101

Application Integration Standardization ...21

Application layer ...........................................63

Application Layer Generation .....................84

Application Logic Errors ..............................89

Application server .........................................16

Application servers .......................................24

Approaches to Application Generation......60

Architectural Standards..............................194

ASP.NET .........................................................37

Directives in page template files...........156

ASPX..........................65, 67, 70, 72, 82, 83, 122

Automate C/R/U/D Page Creation ............. 32

Automated, Yet Robust UI Brings

Application Power to Light .................... 54

Automatic Data Validation & Display....... 39

Automatic Re‐use of ASP.NET Directives in

Page Template Files ............................... 156

Automatic Sign‐out .................................... 116

Automatic SQL Generation for Database‐

Connected Controls ................................. 90

Automating Application Security ............ 107

Automating Code Re‐Use with Panels &

Components............................................ 159

Automating Development

A Historical Perspective.......................... 22

Automating IT Strategies........................... 146

Automating Page Production ................... 147

Automating Re‐Use of Custom & Third‐

Party Controls......................................... 174

Automation in Action

Common Problems Solved ..................... 31

Avoids Code Orphaning............................ 124

Basic Rollout Essentials.............................. 192

Bonus Automation (Even More Code You

Don’t Have to Write ................................ 85

Boost Your Company’s ROI ........................ 55

Browser client

tier......................................... 15

Building & Reusing an Independent

Reusable Panel........................................ 159

Building Reusable Panels and Components

.................................................................. 158

Business logic ................................................ 52

Button actions and properties................... 131

Button Panels............................................... 161

Button Tags.................................................... 70

Buttons ......................................................... 161

Adding..................................................... 131

C/R/U/D pages ...................................19, 32, 64

cache ................................................55, 104, 105

CASE............................................................... 23

Case for Automation .................................... 12

Case Studies................................................. 192

Challenges of Web Application

Development ............................................ 14

Characteristics of Good Generated Code .. 47

Clear Impact & Benefit............................... 183



202

client‐side scripting .................................67, 83

Code Completeness & Organization...........45

Code generation tags.....................................68

FieldValue..................................................72

Image ..........................................................70

ItemTemplate ............................................74

Table ...........................................................74

Use ............................................158, 161, 164

Code Generation Tags.......................61, 67, 69

Code Orphaning ..........................................124

Code Re‐Use.................................................194

Code Should Meet Professional Standards

...................................................................123

Coding Examples

Display a table with multiple fields

within a sortable column...................127

Columns

Sortable.....................................................127

Common Button Actions and Properties .131

Complex Displays..........................................35

Complex, Yet Boring, Development ...........19

Component Binding Process........................77

Component interaction

Page redirection ......................................135

Composite primary keys ..............................91

Compton, Michael ...........................................3

Computer‐Aided Software Engineering ....23

Concurrency

In generated

applications.......................103

Concurrency control......................................91

Concurrency Control / Concurrency

Handling ..................................................100

Concurrency handling ................................100

Concurrency Handling in Generated

Applications.............................................103

Configuring Sign‐In Pages for Your

Application ..............................................114

Configuring Your Web Pages for Role‐Based

Security.....................................................114

Connecting

Web

Pages

and

Databound

Controls to the Database..........................65

Contact Iron Speed ......................................198

Controls

Adding third‐party controls..................174

Cookies............................................................92

Create / Review / Update / Delete pages....32

Create Hundreds or Thousands of Web

Pages...........................................................64

Creating User Accounts ............................. 112

Creating User Roles.................................... 113

Culture encoding ........................................ 144

Cursor management..................................... 91

Cursor Management................................... 103

Custom‐ build the Unique Aspects of your

Application ............................................... 51

Customizing Generated Applications ....... 66

Data Management ...................................... 104

Data Recency ............................................... 104

Data Sorting & Page Navigation ................ 87

Data sources

Adding a new record............................... 81

Parent’s record or current table row...... 79

Data Transmission Encryption ................. 116

data validation ....47, 63, 82, 84, 121, 124, 125,

128, 131

Data validation.............................................. 40

Adding custom code.............................. 128

Database

Result sets.................................................. 37

Stored procedures.................................... 92

Database Cursors in Generated Applications

.................................................................. 104

Database Exception Errors .......................... 89

Database layer ............................................... 63

Database Layer............................................ 105

Database Layer Generation ......................... 85

Database Management

Complexity ........... 18

Database Standardization............................ 20

Database Standards .................................... 193

Database table view pages........................... 33

Database tables

User role .................................................. 114

Database tier.................................................. 16

database views .........................................96, 97

Database views.............................................. 91

Database Views Provide Data Consolidation

.................................................................... 96

Date

and

time

formatting .......................... 144

DBA .....................................................65, 91, 94

Declarative application generators............. 60

Declarative method application generators

.................................................................... 62

Declarative Method Philosophy ................. 60

Delete Record Button ................................... 34

Delivering a Common Request

Exporting Application Data ................... 40



203

Design themes..............................................147

Everest......................................................148

Kilimanjaro ..............................................148

Matterhorn...............................................148

McKinley..................................................148

Shasta........................................................148

Vanilla ......................................................148

Display a table with multiple fields within a

sortable column.......................................127

Edit record pages...........................................34

Embedding controls ....................................175

Emergence of Iterative Development .........29

Enable Corporate Computing Standards...53

Enabling a New Kind of Development Team

...................................................................194

Error reporting...............................................88

Error text string translation........................144

Error validation..............................................88

Every User’s Request, ‘Can you add a

button that…?’.........................................131

Evolution of Automated Software

Development .............................................23

Example

Adding Custom Data Validation Code128

Adding Reporting to a Generated

Application .........................................137

Changing the Presentation Layer .........126

Integrating a Third Party Control.........175

Integrating a Third

Party

Control

with

the Database........................................176

Example Page Template

Automated Record Pages ......................151

Examples

Display a table with multiple fields

within a sortable column...................127

Parameter passing in URL’s ..........133, 135

Passing primary key values in URL’s ..134

exception and error handling.......................47

Exception and Error Management ..............88

Existing

Databases

&

Integrity ..................182

Export Table Wizard .....................................40

Exporting application data...........................40

Extending and Customizing Applications

...................................................................120

Extending the Code Generator Itself

(Automated Code Reuse).........................45

External applications.....................................52

Field Display Tags .........................................70

Field Validation Types ................................. 40

Fields

Data validation......................................... 40

Displaying................................................. 40

FieldValue code generation tag .................. 72

Filter Tags ...................................................... 70

filtering..........................................63, 69, 78, 91

Filters

Specifying in code .................................. 179

First Effort Case Study

Les Schwab Tire Company ................... 187

Open Latitude......................................... 189

Otis Elevator ........................................... 184

Texas Youth Commission ..................... 191

foreign key........................................76, 99, 100

Foreign key relationships .................91, 98, 99

Foreign Key Relationships Permit Multi‐

Table Joins................................................. 98

Foreign keys .................................................. 98

Explicit....................................................... 99

Passing values in URL’s........................ 133

Virtual........................................................ 99

Forward............................................................ 9

Frames .......................................................... 177

Generated applications ......................... 177

Gather Feedback Early & Often in the Cycle

with Real Software................................... 49

Generating Dynamic Context‐Sensitive

Panels....................................................... 169

Generating Navigation Menu Panels....... 164

Generating Role‐Based Application Security

.................................................................. 108

Generating Stored Procedures .................... 95

Generating the Web‐Based Presentation

Layer .......................................................... 63

GetList .......................................................... 179

Goals & Benefits of Automated

Development ............................................ 42

Grouping and Iteration Tags....................... 70

Grouping

FieldValue

Tags

with

Record

Tags73

Guest Accounts ........................................... 192

Gustafson, Paul ............................................... 3

Handling SQL Injection Attacks............... 118

How Automated Development Works...... 59

How Code Generation Tags Work ............. 68

HTML................................23, 61, 62, 67, 70, 83

IDE’s ............................................................... 23

Image code generation tag .......................... 70



204

Image Tag – A HelloWorld Example..........70

Implications for Development Methodology

.....................................................................48

Implied Security from an N‐Tier

Architecture .............................................116

Import & Export Facilities ............................87

In‐line (Embedded) SQL...............................94

Inputs to Generate Your Application .........62

Integrating Business Logic ...........................52

Integrating External Applications...............52

Internal Errors................................................88

Internal User Group Presentations............193

Internationalization.....................................143

Internationalizing (Localizing) Your

Application ..............................................143

Iron Speed, Inc. ................................................9

ItemTemplate code generation tag..............74

Keep Development In‐house........................56 Key Benefits of Application Generation

Methodolgy ...............................................52

Layout page Files

Embedding controls ...............................175

Layout Pages ..................................................67

Layout Tags....................................................70

LDAP.............................................................117

Limited Integration / Customization Work

...................................................................183

Linking Database Tables, Views and Queries

to an

Application ......................................75

Localization ..................................................143

Localizing (Internationalizing) Your

Application ..............................................143

Location of the SQL Statements...................94

Looking Ahead ............................................181

Lost passwords ............................................115

MDA..........................................................27, 60

MDA/UML Philosophy ................................60

Meeting & Exceeding User Expectations ...91

Menu panel...................................................150

Menu

panels.................................................164

Menu_Item panel.........................................150

Menu_Item_Highlighted panel .................150

Menus

Third‐party controls ...............................174

Miller, Stephanie..............................................3

Model driven architecture............................27

Modern Requirements ..................................25

Mohiuddin, Razi..............................................3

More Complex Data Displays

Table Tags & Data Grids ......................... 74

Multiple Role Authentication ................... 110

Multi‐table joins ............................................ 98

navigation .............................63, 69, 91, 95, 127

Navigation menu bars................................ 164

Neglected User Community...................... 184

NET application development.................... 61

N‐tier architecture..................................62, 116

Number and currency formatting ............ 144

Onsale, Inc. ...................................................... 9

Optimistic Concurrency............................. 102

Organizational Rollout of Application

Generation Technology......................... 192

orphaned code............................................. 124

Page encoding ............................................. 144

Page Redirection ......................................... 135

Page templates Add record pages..................................... 34

ASP.NET directives ............................... 156

Creating and customizing..................... 147

Database table view pages...................... 33

Definition ................................................ 151

Delete record function............................. 34

Edit record pages ..................................... 34

Export table dialog................................... 40

Record page templates .......................... 151

View record pages ................................... 34

Pagination panel ......................................... 150

Panels............................................................ 158

Adding reusable panels ........................ 160

Button ...................................................... 161

Menu.................................................150, 164

Menu_Item.............................................. 150

Menu_Item_Highlighted ...................... 150

Pagination ............................................... 150

Range_Filter............................................ 150

Record information................................ 169

Reusable .................................................. 159

Search....................................................... 151

Panels Requiring Record Information ..... 169

Passing data via the URL............................. 73

Passing Other Values Between Pages ...... 135

Passing Parameters in URL’s .................... 135

Passing Primary and Foreign Key Values in

URL’s ....................................................... 133

Passing Primary Key Values Between Pages

in URL’s................................................... 134



205

Password Storage ........................................117

Passwords

Lost ...........................................................115

Pessimistic Concurrency.............................102

Placing Role Information in Your Users

Table .........................................................114

Pragmatic, Yet Revolutionary, Approach to

Code Re‐Use ............................................158

Presentation layer..........................................63

Changing..................................................126

Generation .................................................63

Presentation Layer Generation ....................83

Primary Key Relationships Permit Record

Editing ........................................................97

Primary keys ..................................................97

Query string parameters...............................73

Range_Filter panel.......................................150

Record Page Templates...............................151 Record Tags ....................................................70

Redirection....................................................135

Reporting

Adding to a generated application.......137

Resource Web Page .....................................193

Result sets .......................................................37

Reusable Components ................................158

Reusable Panels............................................158

Adding reusable panels to a page ........160

Building Independent Panels................159

Buttons .....................................................161

Menus.......................................................164

Using record information ......................169

Role‐ based security .....................................114

Role‐Based Security Overview ..................108

RPG II ..............................................................23

Scalability........................................................55

Scalability Complexity ..................................18

search...................................................63, 91, 96

Search panel .................................................151

Search Tools....................................................86

Securing

web

pages.....................................108

Security

Active Directory......................................117

Configuring web pages..........................114

LDAP ........................................................117

N‐tier architecture...................................116

Role‐ based................................................108

User roles .................................................113

Security Complexity......................................19

Security Your Generated Web Application

.................................................................. 111

Selecting Your First Project........................ 182

Sign in pages................................................ 114

Sign out page............................................... 114

Signing Into Your Application & Managing

Lost Passwords....................................... 115

Simple Sign‐in Authentication.................. 109

Simplify Software Maintenance.................. 51

Single Role Authentication........................ 110

Size & Scope ................................................ 182

Sourcing From Parent’s Record or Current

Row in a Table .......................................... 79

Specifying an Application’s Basic

Functionality with Code Generation Tags

.................................................................... 61

Speed Development and Reduce Testing

Time ........................................................... 52

SQL55, 65, 73, 76, 78, 82, 85, 91, 92, 94, 95, 99,

103, 104, 105, 124

Efficiency................................................... 91

In‐line statements..................................... 94

Location of statements........................91, 94

Stored procedures.................................... 94

SQL Efficiency............................................... 91

Stand‐Alone FieldValue Tag ....................... 72

Stand‐Alone FieldValue Tag Example....... 72

Standards for Generated Code.................. 122

Standards Make

Application

Generation

Possible...................................................... 20

Starting from Scratch

The Application‐Specific Data Model... 44

stored procedures ..................85, 93, 94, 95, 96

Stored procedures......................................... 92

Stored Procedures Enhance Performance &

Maintainability......................................... 94

Summary...........................41, 89, 105, 145, 180

Tab bars........................................................ 164

Table code generation tag............................ 74

Table

Component

Tags ................................ 70

Table display ............................................... 127

Table Tag – Displaying Tabular Data ........ 74

Table Tags ...................................................... 70

Table view pages........................................... 33

The New Reality

Competitive Advantage Requires

Ubiquitous Custom Software .......... 195

The Rise of ‘Nano’ Applications............... 195



Third‐party controls ....................................174

CyberAKT ASPNetMenu.......................175

Independent third‐party control...........175

Menus.......................................................174

Three‐Tiered Architecture Complexity ......15

Today

Application Generators............................26

Transaction model .........................................91

Transaction Model and Transaction

Management..............................................92

UML...........................................................27, 60

UML & MDA – Poor Alternatives for Most

Developers .................................................27

Universal modeling language......................27

URL

Parameter passing...........................133, 135

User Interface Complexity........................... 16

User Interface Standardization ................... 20

User Interface Standards............................ 193

User roles ..................................................... 113

User Sign In Page........................................ 114

User Sign‐Out Page .................................... 114

User tables.................................................... 114

Using Data Grids to Manage Large Result

Sets ............................................................. 37

Using Declarative Methods to Specify an

Application ............................................... 67

Using the FieldValue Tag to Display Data 72

View record pages ........................................ 34

Visual Basic.......25, 66, 82, 83, 94, 95, 125, 126

Visual Basic .NET.......................................... 93

web pages .......61, 62, 64, 66, 68, 104, 124, 127

One-Day Web Apps -- Application Generation for .NET.2nd Edition

Documents