Clarion/ASP: Code Generating ASP Business Applications

Transcription

Clarion/ASP:
Code Generating ASP
Business Applications
White Paper
June, 2002
Page 1
Copyright © 2002 Softvelocity Inc. http://www.softvelocity.com
Contents
Abstract .................................................................................................. 3
Current State of ASP/ADO Development ............................................ 4
Overview: Clarion/ASP Development ................................................... 16
Details: Clarion/ASP Development ...................................................... 21
Application Elements ............................................................................. 24
Conclusion ............................................................................................. 37
White Paper
June, 2002
Page 2
Abstract
ASP is a web scripting architecture, which in combination with
ADO (Active Data Objects) for database support, allows web
designers to create browser based data centric applications. ASP is
highly scalable and widely deployed.
Clarion/ASP is a code generating tool for ASP applications which
provide query, navigation and editing procedures for client/server
databases over the web. It is geared for desktop developers or web
designers who wish to automate the production of ASP
applications through the use of re-usable code. It allows business
application developers to easily “translate” behaviors normally
found in line of business desktop applications to the web.
Currently, ASP applications are usually the product of “one-off ”
development using a variety of hand coding techniques, simple
wizards, and to a limited extent, code generating tools. The typical
ASP developer may be a web designer, starting the development
process using an HTML layout tool which provides wizards which
creates “starter code” for the ADO data acess. ASP applications
typically are limited in scope compared to desktop based business
applications, and are more likely to be focused on a single data task
than maintaining many tables.
The Clarion/ASP “finished product” consists of ASP pages,
HTML templates, and cascading style sheets. Business logic and
user interface are completely separated, allowing developer or
designer to work on one without affecting the other, protecting
such customizations upon subsequent generations, and aiding the
integration of Clarion/ASP procedures into existing sites both in
looks and via links to and from existing pages of the site.
White Paper
June, 2002
Page 3
Current State of ASP/ADO Development
ASP (Active Server Pages) is a scripting architecture developed by
Microsoft for creating dynamic web pages. Its original use was for
web site animations and transitions. The addition of ADO (Active
Data Objects) to ASP allows for web based access to SQL client/
server databases via OLE DB (Object Linking and Embedding/
Database).
ASP/ADO provides excellent scalability, excellent compatibility
with browsers, and in most cases, rapid access to data.
Typical Use
As with other web scripting languages, the typical ASP/ADO
developer is a web designer using a site layout tool who wishes to
add database access to one or more pages at the site.
The typical ASP/ADO application may be said, therefore, to focus
on a single task, such as a simple table query, a lookup from a table,
and perhaps an update to another table.
Most such applications are one-off projects. Starting with a page
layout, data access is subsequently either hand coded or created with
White Paper
June, 2002
Page 4
the help of a wizard which creates the “base” database access code,
which is then refined by hand.
In many cases, it is expected that the web designer, whose only
function (most likely) is publishing web pages and applications,
interacts with the DBA when creation or modification of a database
structure such as a VIEW is necessary.
Current ASP Development may thus be said to be characterized by:
•
High Degree of Hand Coding/Customization for Each Project
•
High Degree of Effort on Layout
•
Little Reusability From Page to Page
•
No Direct Interaction With Existing Repositories for Business
Rules (such as those already kept in desktop development tools
by the same enterprises deploying ASP applications).
•
Little Cross Development Effort With Desktop Development
Teams (the primary consumers of desktop development tools).
White Paper
June, 2002
Page 5
Web Server (IIS)
t
s
t
e
s
u
q
ra
te
e
R
e
l
n
ia
it
G
e
e
S
lt
u
s
L
Q
S
Browser
e
R
s
In
s
te
ra
rn
e
tu
n
e
R
e
G
H
T
M
L
Processes Script
DBMS
Deployment
ASP and ADO technologies are widely deployed by virtue of being
included in Windows NT Server and Windows 2000 Server.
Commercial sites which utilize tools such as Microsoft Commerce
Builder or SharePoint rely on ASP in combination with ADO to
provide end user database access. Many other sites which depend
on Microsoft for web server and/or database server software use
ASP and ADO for data access. ADO usage is almost a given for MS
SQL Server sites with a need to access data via the web.
Because the ASP applications themselves execute on the server and
display inside most web browsers, deployment of the application to
the client is in most cases not of concern to the developer.
Development Tools
ASP Development tools are widespread, and stem from HTML
layout and site deployment tools.
White Paper
June, 2002
Page 6
Such tools range from Microsoft Script Editor, which ships with
MS Office, to Visual Studio .NET. Many non-Microsoft
environments such as C++ Builder also allow for generation of
ASP code.
There are many tools such as ColdFusion which provide data access
via specialized HTML tags without the use of ASP.
Within the Microsoft-centric segment of the web server universe,
however, Visual InterDev (included in Visual Studio .NET) is the
most widespread tool for creation of ASP/ADO applications.
Visual InterDev relies upon layout tools and hand coding for its
ASP support, and includes additional wizards to help include
database access on a page by page basis. There are also third party
tools which allow for page layout plus additional wizards to help
include database access on a page by page basis.
There are few ASP/ADO code generator tools outside of the
wizards included in script layout tools.
•
1 Click DB Wizard Edition, from 1 Click DB Solutions,
provides wizards which lay out entire pages and provide for
navigation between browses (recordset tables), forms and
queries.
•
The ASP DataForm Wizard, specializes in generating form fill
in access to SQL tables.
•
Code Charge, from YesSoftware is a combination of wizards
and a site-map like layout tool. Of these three products, it is the
most comprehensive and produces an end result rivalling
Clarion/ASP in breadth of the application procedures
produced. It produces a variety of script target outputs.
White Paper
June, 2002
Page 7
Current Development
Methodology
Use of ADO access within ASP pages is generally a one-off
process, in which a page provides access to a single table or stored
procedure.
This fits in with the approach to web development as a publishing
process driven by designers rather than as a production/hosting
environment for data access as designed and deployed by
application developers. The look and feel of database forms or
tabular data display must fit into the general design of the site.
Using tools such as those described above, designers custom build
data access pages. Many sites prefer to create parameterized stored
procedures and simply display record sets to better fit data access
functions to the tools used to create page layouts. Each page layout
therefore requires either hand coding of ADO access or the use of
a one time wizard, plus any additional DBMS based coding such as
stored procedures. In these cases, most if not all data validation is
performed at the DBMS.
Yet even for these one-off page layout/data access tasks, there are
common database functions such as logins, tabular data display,
query, add, edit, delete. Business developers have long been familiar
with client server tools which automate the production of forms
for such functions.
If these tasks could be automated, yet still offer the customization
opportunities for their appearance which site designers demand, the
productivity of the designers producing such pages would improve.
White Paper
June, 2002
Page 8
Current Business
Database Access Use
The ASP/ADO page-by-page development methodology described
in the previous section is in sharp contrast with most client server
business applications, which generally access several or more tables
from a corporate database per application, in the form of lookups,
drilldowns, etc.
Though many desktop and Java Rapid Application Development
environments support a procedural architecture which makes it
possible for users to progress from query to form to lookup, and to
traverse tables along relationships, this has been more difficult to
achieve in ASP/ADO applications due to the stateless nature of the
web. Part of this may be due to Microsoft’s original
recommendations to developers to limit the use of session
variables, the easiest, most straightforward way to record status
between page navigations, though that recommendation has been
greatly relaxed recently.
Such development environments, moreover, provide greater
organization through improved project management, greater re-use
of code from project to project, and sometimes via businessapplication-specific productivity aids such as database dictionaries
which store business rules as kept by the DBMS.
Desired Development
Methodologies
The number of web sites utilizing ASP for database access, the fact
that such sites generally rely on one-off or “hand coding” for the
production of ASP applications, and the fact that such sites
generally may be said, by virtual of also developing Client Server
desktop applications, to (at minimum) be aware of greater
productivity in the development environments which produce these
desktop applications indicates the following desired traits:
White Paper
June, 2002
Page 9
•
Accelerated development cycle: such sites are familiar with
the benefits of rapid application development environments,
and most likely produce in house desktop applications. Such
sites could benefit from a similarly accelerated ASP application
development cycle relying on reusable code, as used in desktop
development in place of one-off wizards, hand coding, and
individual design/layout customizations by page.
•
Shared appearance with current site: in the same way that
desktop applications by nature of their development tools
integrate into the windows desktop, these sites would justifiably
expect a similar integration into their existing web sites.
•
Quality of finished product: the reusable components of
desktop development environments are generally very advanced
and reliable. Any ASP development tool considered as an
analog for such tools should therefore be able to produce
advanced and reliable ASP code.
•
Implementation of business logic across multiple projects:
this may be the current ASP development model’s weakest
point. Given the use of meta repositories in popular desktop
development tools, expectations for a development
environment for ASP would center on the storage of business
rules defined within the DBMS or data dictionary and their use
in multiple applications. Current ASP coding practice, via
wizards and hand code, is unique to each project.
ASP and Clarion/ASP
Clarion/ASP may has been designed with the following goals:
•
Accelerate development of ASP projects through the use
of reusable ASP code. The ASP code is stored in Clarion
templates. By interaction with the same data dictionary which
also produces desktop applications, the Clarion development
environment reads the dictionary symbols which represent the
database, business rules and database structures and merges
White Paper
June, 2002
Page 10
them with the template ASP code according to options chosen
by the developer through a design time template interface,
outputting a mix of ASP and HTML pages accessing the
database structures.
•
Merge Database Access Into the Current “Look” of a
Given Site: using a combination of customizable design time
HTML templates (for general page “setting”), run time HTML
templates (for precise control layout), and standard cascading
style sheets (for formatting), the ASP output may match the
look of other pages at the site perfectly. Additionally, the web
designer may add links to and from any part of the application
(including individually specified data rows) and the rest of the
site, “exchanging” field data via URL parameters and POST
variables.
•
Reliable, Modular, Useful Code: the generated code has been
tested thoroughly and avoids common ASP coding mistakes
such as returning null data. Common functions are kept small
and stored in separate include files used by multiple pages.
Extensive security checking, common database functions, etc.
are built in.
•
Integration with Business Rules Repository: the Clarion
data dictionary queries the DBMS for a number of business
rules. Once stored in the dictionary, upon generation the system
implements client side validity checks in accordance with the
business rules. Implementing the logic client side reduces
communications between client, web server and DBMS and
results in a more responsive system for the end user.
•
Efficient Use of Programming and Design Resources:
Clarion/ASP completely separates the business/application
logic from the user interface. It stores the user interface into
HTML templates which may be edited using standard HTML
layout tools. This allows the web designer to provide for any
desired customization of the look of the application with no
effect on the application itself. Additionally, the application can
White Paper
June, 2002
Page 11
later be modified without overwriting any customizations that
the designer has already done. This allows a desktop application
developer to work within the Clarion development environment
to focus on the business/application logic, which is the
developer’s strength, and the designer to focus on the layout,
which is the designer’s strength, each collaborating on the
overall design of the application.
Generated Product
The ASP/ADO code generated by the application generator is
highly compact and efficient, yet features robust error checking.
The following provides a more detailed look:
•
“Processor Pages,” which complement each of the .asp pages
that Clarion/ASP generate for your procedures contain the
database access code. The processors consist of small, tight
loops which smoothly handle difficult access issues such as
column names with embedded spaces, null values, which are
particularly troublesome in .ASP, and type conversions.
•
Client side validation via compact Javascript functions. (see
example message below):
•
Customization support within the template interface which
allows the developer at places to write their own HTML/
VBScript code to execute alongside the Clarion/ASP code
White Paper
June, 2002
Page 12
without harming the generated code, and without risk of
overwriting the customizations at generation time.
•
Rich support for displaying images, whether displayed from
a database row or external file.
•
A flexible security model which provides up to 99 security
levels per procedure, along with options to allow viewing,
adding, editing or deleting data according to the level of the
user. (Template interface for defining the security table below):
•
Automatic calls to login screens and user validation from
within all pages using security, so that the proper security is in
place even if the ASP page is called from a page not generated
by Clarion/ASP.
•
Extremely flexible interaction with URL parameters (and
POST data), making it possible to identify record(s) for use
when called from other pages at the site not generated by
Clarion/ASP. Note: from the opposite direction, to POST data
from the Clarion/ASP form to another form at the site not
generated by Clarion/ASP, all naming conventions for Input
elements are thoroughly documented, so that the web designer
may “receive” their values on their own target page.
•
Extremely flexible layouts via HTML run-time templates
which allow layout modifications beyond the many options
already available through the template interface.
White Paper
June, 2002
Page 13
•
A high degree of flexibility in appearance via use of style
sheets that work along with the ASP pages allowing the
developer and designer to define exactly the look desired, and
which allow for the “blending” of the pages into an existing
web with the same look and feel.
The following charts a request for data (such as a single view-only
form or navigable data table), as received from the client browser,
using the authorization, access, and display logic generated by
Clarion/ASP:
Clarion/ASP
Browser Client Data Request
Browser
Client
Requests
Information
Results
Returned to
Client as a
New Page
Page Builder
Checks for
User
Authorization
Runs
Authentication
Routine and
Returns
Page Builder
Loads HTML
Template and
Merges the
Dynamic Data
Page Builder
Performs
Data Access
and Resolves
Data Symbols
Similarly, a request for an action (a submission by HTML for of an
add, change, or delete), as received from the client browser, using
White Paper
June, 2002
Page 14
the authorization, access, and display logic generated by Clarion/
ASP can be charted as follows:
Clarion/ASP
Browser Client Form Action Request
Browser
Client
Submits
HTML Form
Results
Returned to
Client as a
New Page
Processor Page
Checks for
User
Authorization
Runs
Authentication
Routine and
Returns
Processor Page
Performs
the Requested
Data
Update
Processor
Page
Performs
Data
Validation
Data
Validation
Error
Error
Message
Returned to
Client
White Paper
June, 2002
Page 15
Overview: Clarion/ASP Development
The goal of the Clarion/ASP development process is to automate
the process of creating attractive data-driven page layouts that
integrate into existing webs, to apply the productivity expectations
of modern business application development environments to the
current hand coding/layout/wizard driven method of creating
ASP/ADO applications, and to simulate some of the normal
procedural flow of a desktop application via page to page
navigation through data display, query forms, and input forms.
Clarion/ASP application pages provide an application-like
experience within the confines of the stateless browser experience.
Application
Considerations
Clarion/ASP applications are by necessity always browser based
applications, whose purpose is to query and display information
quickly, and allow updates where permitted. In general these
applications are for use with and SQL DBMS plus a separate web
server. The following displays a framed based application showing a
query page at left, and a browse table (navigable list) at right.
White Paper
June, 2002
Page 16
Because Clarion/ASP can quickly and easily generate pages for
many procedures, each of which can add, insert, view or delete data
from any table, as well as link to other procedures passing
parameters as necessary, Clarion/ASP applications can be more
readily adapted for use by business to extend the use of in house
desktop applications to outside users.
The most important concerns in this scenario are performance and
security:
•
In general, ASP/ADO applications can be fast and scale well,
assuming that page design is not overloaded and hardware is
appropriate.
•
Clarion/ASP enhances performance via a small but
sophisticated data validity checking library of java script
functions which reduce communications between client, web
server and DBMS by performing validity checks on the client.
In addition, the ASP Processor page performs validation just
prior to submission.
•
Security of Microsoft Internet Information Servers, which are
the exclusive hosts of ASP/ADO applications, have come into
question recently. With proper application of hot fixes, the
basic server security issues have been addressed.
•
Application level security is provided in Clarion/ASP through
an enhanced security model, in which user ID’s and access
levels are stored in a database table. Then, at two levels:
entrance to each procedure, and access to individual table rows,
Clarion/ASP generates code to present or not present
procedures to the end user based upon their user ID and access
level.
White Paper
June, 2002
Page 17
Clarion/ASP Generation
Process
The Clarion development system, at heart a code generation system,
has always been envisioned to generate any type of database
oriented code and has always been language independent. This
product combines highly sophisticated template writing and highly
sophisticated ASP coding, interacting with ADO to produce pages
which mimic an equivalent procedure within a desktop application.
The procedure, in fact, includes window controls and structures.
The application generator analyzes the data-aware controls within a
given window, creates HTML analogs for them, looks to the Clarion
data dictionary for descriptions of the appropriate appearance and
behavior for controls referencing the data, then creates ASP pages
that process and the data, and merge these behaviors into a
procedure-specific HTML template.
Many customization options are available for each control,
including the placement of “custom controls” which may provide
links (dynamic or static, via text or graphic) to other procedures or
pages, optionally passing data values for a given row/column as a
parameter. The illustration below is of the properties for a custom
control:
White Paper
June, 2002
Page 18
Also during the design process, the Clarion/ASP developer creates
a style sheet which aids the process of integrating the Clarion/ASP
pages into an existing site via appearance options. Another part of
the design process allows for an underlying HTML template, upon
which all the Clarion/ASP data can be displayed, in effect allowing
the data to be merged into a standard page or frame background
shared by other pages at the site.
The end result is an ASP page that populates controls, calling
“processor pages” (in the case of a form) which in turn control the
row update. The developer working on Windows NT workstation,
Windows 2000 Pro, or Windows XP Professional then tests on the
local machine using IIS via the localhost IP address.
Customization and
Deployment
After generation and testing of the pages, the Clarion/ASP
developer may work with the web designer to further enhance the
look of the page, make it work well with current site frames, prepopulate form data from other site forms or vice versa, and more.
Clarion/ASP also supports a debug process, though one limited by
the limitations imposed by a script based application.
At that point the developer and web designer may deploy the pages.
In case of major failure, such as inability to access the database, the
Clarion/ASP code automatically emails the web administrator.
The illustration below displays an HTML frame at left, and a
Clarion/ASP page at right: The end user has pressed a button
which was automatically placed to the right of a data field. A popup
calendar (javascript) appeared, ready for the end user to click a date,
which will be returned to the date field.
White Paper
June, 2002
Page 19
White Paper
June, 2002
Page 20
Details: Clarion/ASP Development
This section provides details of the development and deployment
cycle for Clarion/ASP application pages.
Roadmap
Detailing the actual steps summarized in the “conceptual” overview
above, this section provides a simple overview of the development
and execution of an application, from “scratch.”
•
The developer starts with a Clarion database dictionary
describing the structures in an SQL DBMS (hereafter, DBMS
will refer to any client server relational Database Management
System such as MS SQL Server, Oracle, IBM DB2, etc).
•
The developer pre-formats the dictionary to include all
relations, business rules, additional indices where a sort order
request is expected, plain english descriptions for tables and
fields, and control pre-formatting, as in the illustration below:
•
The developer optionally adjusts the field order within each
table as well as sets the “do not populate” options as
White Paper
June, 2002
Page 21
appropriate, in preparation for running the application wizard.
Clarion/ASP, when applied, will read the list boxes (for
browses) and entry controls (for forms) generated by the
application wizard in order to determine which fields it should
populate in its tables (for browses) and forms, in the order that
the fields appear in those structures.
•
The developer runs the application wizard (or creates an empty
.app file and manually populates browse and form procedures).
•
The developer applies the Clarion/ASP global extension
template, specifying, at that time, the DSN, the HTML design
time template, and the style sheet options, i.e., the global
connectivity, look and feel options.
•
The developer decides which procedures require ASP page
equivalents.
•
The developer applies the browse and form procedures
respectively to the browses and forms in the application.
•
The developer customizes the various fields within each
procedure where necessary, using the design time interface, as in
an example illustrated below.
•
The developer links additional procedures as needed using the
design time interface. (As an example, a navigational list view
(browse) of a “products” table might link not only to the
update form for the product, but also to a browse of all
products by the supplier of the original product, and/or a
White Paper
June, 2002
Page 22
browse of all products in the same category as the selected
product).
•
The developer tests the various procedures locally using the
Clarion/ASP generated menu page and a local copy of Internet
Information Server.
•
The developer fine tunes each procedure as necessary, whether
for application logic, or look and feel.
•
The developer generates the pages and tests them locally.
•
The developer and web administrator together may optionally
“fine tune” the generated pages.
•
The developer and web administrator together provide links as
needed, to/from the rest of the site to the ASP pages, and
upload the ASP pages for deployment.
White Paper
June, 2002
Page 23
Application Elements
This sections describes Clarion/ASP essential features and program
elements.
Security
Clarion/ASP provides for a straightforward yet highly flexible
security scheme based on a pyramid of user/group access rights
with up to 99 user levels.
When you enable security on a global level, each generated
procedure will include a login routine. Access by the end user to any
procedure page with security enabled will invoke a login screen.
Once the user enters a successful login on one page, they may
access any page their security level allows rights to, providing that
any period of inactivity does not extend beyond a configurable
timeout. If it does, they must log in again.
You may designate a table within the database to store a user ID
(we suggest that an email address is highly useful for general public
web applications), password, and access level (an integer between 1
and 99). Optionally, the table may store the user name (either first
and last names separately, or first and last combined), and an email
address if not used for the user ID.
The login messages/instructions are configurable, as in the
illustration below:
White Paper
June, 2002
Page 24
After specifying that security is to be enabled, and designating the
table which holds the user information, the developer may then set
custom access levels by procedure (the default for all, once security
is enabled, is 1). Within each procedure, the developer may
separately specify separate access levels for viewing, editing, adding,
and deleting data.
Thus, should the developer specify that ordinary users are level 30,
supervisors level 50, managers level 70 and senior managers level
90, a developer may specify that a particular form might be viewed
by all, a new record added by supervisors and higher, an existing
record edited by managers and higher, and deleted only by senior
managers. With 99 possible values and four possible access levels
per update form, the security system allows for many possible
access scenarios.
Login traffic between the browser and the server is unencrypted.
My Records Security
The purpose of “My Records” filtering is to limit the viewing and/
or editing of data to the “owner” (a single person or a group of
users), as in the following examples:
•
A column on any table can include a user ID (typically an email
address). Enabling the “My Records” filter on any procedure
White Paper
June, 2002
Page 25
referencing the table can therefore restrict access to any row
that matches the user ID to the user ID with which the user
logged in. Thus in a table of “tasks,” user one views only those
tasks belonging to user one, and user two, only those belonging
to user two.
•
The Microsoft SQL Server Northwind sample database’s
employee table contains a “reports to” column. You may filter a
browse which allows “managers” to see only their “direct
reports” by specifying the “reports to” column as the data
column to compare, and using the employee table as the
security table, the employee ID as the user ID, and then using
the “UserID” session variable to test against the “reports to”
column. Similarly, you may declare an additional session
variable, such as “Department,” edit the login.asp page to assign
the session variable based upon department data which you
would store in the security table, and then choose that session
variable to compare to a department value in your primary
browse table. You could similarly substitute “region,” “sales
territory,” etc.
Once you’ve correctly set up the “My Records” options for each
procedure, you need do no more; Clarion/ASP automatically hides
the necessary fields, applies the necessary query filters, and takes
care of setting the data defaults for new records. The illustration
below shows the “My Records” field in a tasks table:
Note that should you be applying the functionality to existing data
and are adding a column to a table that you must add the values
White Paper
June, 2002
Page 26
necessary for the existing records, else they will not appear within
any users’ “My Records” filter.
Finally, note that you may place “My Records” on a form yet not
place it on a browse, due to the fact that each “procedure” within
Clarion/ASP is isolated from the other due to the nature of the
web. This means that you may allow an end user to view all records
within a browse, but restrict editing, deleting, or viewing details by
placing the “My Records” filter on the form.
User Interface
Because the entire user interface is contained in HTML and CSS
files separate from the application logic (contained in the ASP files),
a web designer may customize the user interface in any standard
HTML layout tool (and/or CSS editor) without affecting the
application. The example below shows a runtime template being
edited in an HTML layout tool. Note that the runtime colors and
fonts are not visible because the layout tool doesn’t display the
formatting from the CSS file:
White Paper
June, 2002
Page 27
An application option allows subsequent regeneration of the
project without overwriting the web designer’s customizations,
should it be necessary to change any of the application logic.
Another key concept for developers used to creating desktop
applications to understand when creating ASP applications is that
HTML controls are different than Windows application controls.
There is significantly less capability for customization and far less
control over positioning. This leads us to a “good news and bad
news” situation for desktop developers familiar with Clarion.
The good news, despite these limitations, in Clarion/ASP we’ve
accomplished an extraordinary amount of mimicry of control
formatting and layout using HTML 4.0 and stored it all in in the
HTML page and style sheets for maximum flexibility. The bad news
is that because there’s no way to equate all the properties in the
dictionary control formatting options with HTML we can’t
guarantee that everything will be perfect. For example, we can’t
provide for transparency, immediacy, selected coloring, or controlspecific cursors, to name a few. We can’t recreate controls such as
regions.
Developers will find that your control formatting will be less visual,
and more dependent on selecting properties from lists. Layouts are
either horizontal, as in a browse, or vertical as in a form, one
control to a line. You may specify the types of control, and a
number of options for appearance and behavior, but it’s not the
same as designing a dialog box. Good use of style sheets, however,
can make for a very attractive page.
HTML Templates
Though it may seem that everything is being called a template,
Clarion templates and HTML templates are different things. This
section focuses only on the HTML template.
White Paper
June, 2002
Page 28
When a user requests a page with data, the ASP code gathers the
data and merges it into a standard HTML page. The merge “target”
is called the runtime HTML template. The template is a normal
HTML page, which contains a symbol for each piece of data which
the merge function replaces with the actual data (either as text or a
control) and formatting instructions (i.e., CSS style) during the
merge process.
In browse procedures, for example, you will find tokens in the
format @TablenameFieldname@ occupying the table. Each token
stands for the data which will replace the token. Should you wish to
modify the layout, you may modify the HTML page.
The runtime HTML template is a standard HTML file. The web
designer can edit the runtime template with a standard HTML
editor, moving and formatting the symbols as desired, without
affecting the application.
These HTML files are regenerated. The developer, however, may
turn off HTML generation at the procedure level so as not to
override the web designer’s customizations.
Cascading Style Sheets
HTML style sheets, known as cascading style sheets (because one
style may cascade its characteristics into another, and so forth), play
a large role in many sites, and a large role in the Clarion/ASP pages.
The style sheets declare classes, which consist solely of formatting
instructions. You can then apply the style to a tag (be it a paragraph,
cell in a table, a table, etc.), and that element will then be formatted
according to the instructions in the style sheet. This allows any site
to greatly change its look simply by substituting a new style sheet
for an old one.
Clarion/ASP allows you to define styles for elements such as table
column headers, update form control labels (prompts), data rows,
etc. You may then integrate an existing site style sheet with the one
White Paper
June, 2002
Page 29
Clarion/ASP produces or vice versa. You may also place references
to both your Clarion/ASP produced style sheet and your corporate
style sheet in each file, and the browser will merge the attributes of
each when displaying the page to the end user.
The pages that Clarion/ASP creates have a look and feel almost
entirely governed by style sheets and a base HTML template. The
goal is that a developer can start with two things: a copy of a
representative page from the web and the global style sheet for the
site, and with them, quickly make the Clarion/ASP pages look like
the rest of the site.
Browse
This section describes the Clarion browse table, as implemented in
Clarion/ASP.
Purpose
The browse presents an easy to use means to display and navigate
tabular information. It presents the user with a page of data at a
time (the number of rows for which are specified by the developer).
The developer specifies a filter condition, which selects a subset of
rows from the database. A navigation bar allows the end user to
forward or reverse by a page, or jump to the end or back to the
beginning. A query by form button allows the end user to select a
subset of the subset by entering a sample value(s) for a field(s). A
locator entry optionally allows the end user even quicker navigation,
allowing them to type in a portion of data for a particular field, and
then presenting the new subset immediately. Each row of data may
White Paper
June, 2002
Page 30
optionally allow for links to other browse tables or forms. For
example, clicking on a company name may provide the end user
with a detailed view of the company data. Similarly, each row may
contain a link(s) leading to another browse(s), containing data from
related tables, such as that company’s products, or its orders, and so
forth. In the illustration below, each row contains links to four
related tables, plus, at far right, an automatically generated link to an
update form for the row.
Because the Clarion data dictionary is conversant with the table
relations in the database, the developer may easily display a
denormalized view of the data within the browse by specifying
fields from multiple tables. Clarion/ASP automatically creates the
proper JOIN statements for ADO access.
Clarion/ASP also refers to the Clarion data dictionary for options
to format the data on a field by field basis.
In many cases, a Clarion browse allows the end user to proceed to
an update form (or a view only form) by clicking on a data row. It
takes only a small number of mouse clicks for the developer to
implement this functionality.
White Paper
June, 2002
Page 31
Filtering
Filtering the browse is accomplished through the where clause in
the SQL query. It is, of course, also possible to create a view or
stored procedure in the database to accomplish the same means.
Clarion/ASP provides several levels of filtering opportunities.
•
No filter at all.
•
A view declared in the dictionary.
•
A default where clause placed on the browse procedure
properties.
•
A called procedure placed on the browse procedure properties.
•
A locator filter based upon text typed by the end user into a
field associated with a specific column (as in where fieldname
like ABC%).
•
A Query by Form filter based upon example values typed into a
form by the end user
•
ID values: at the procedure level, the developer specifies a
specific field may be identified to act as a URL parameter for a
where clause value, as in URL?ID=value, where columname =
value. Once the field is so identified, any linking page can pass
the where clause value without even revealing the name of the
field. The browse will then display. Clarion/ASP uses this
method to pass data from procedure to procedure. In fact,
Clarion/ASP can even pass a row value without displaying the
value to the end user (for example, displaying a graphic instead).
•
A specific where clause passed as a parameter from a linking
page, via URL?WHR=clause.
White Paper
June, 2002
Page 32
•
A MyRecords filter, as described in the section on security,
above. This is an important feature for sites which wish to
manage user data in isolation from data belonging to other
users.
•
A combination of all the types of filters as described above.
Links
Links are the conduits through which one page leads to another on
the Internet. There is no program flow like a desktop application.
An important concept for database developers to grasp about ASP
is that, like web pages, the browser and web server do not maintain
a continuous connection. Further, the web server and the database
do not maintain a continuous connection per each user.
The only limitation on linking to a Clarion/ASP page is a logical
one: if you wish to display a form containing only one record, or
display a filtered browse, you must supply a way to identify the
record(s) within the link. You can do this as a simple HTML
parameter. The parameter will always be called “ID.” The field it
refers to will be the unique ID field which you defined for the
procedure extension.
Optionally, a link from an outside page can pass a snippet of SQL
which can then be appended to the WHERE clause. In Clarion/
ASP, this parameter is ?WHR. You may, for example, have a several
links to a single browse. One link may have a parameter such as
?WHR=dbo.contacts.state=NY, another
?WHR=dbo.contacts.state=CA, etc. In each case, the same ASP
page is the target, but each link returns different data (contacts
from New York, contacts from California).
White Paper
June, 2002
Page 33
Conditional Formatting
The browse procedure feature a rich array of conditional
formatting options. The developer creates specific data row
substyles in the style sheet for the project. Then, the developer may
specify that the ASP applies styles according to:
•
Provide a greenbar effect, applying two styles (usually the same
text formatting, but with different background colors) to
alternating rows. Greenbar formatting is the default, but can be
overridden.
•
Highlight specific rows which meet a test condition, such as the
value in a particular column is equal to or greater than another
value.
•
Highlight specific “grid cells,” based upon a data value meeting
a test condition. (This is the same as the second option, but
applies the second style to a table cell instead of the entire row).
Form
The Clarion/ASP update form also provides for additions,
deletions, and view only mode, in addition to allowing the end user
to simply update the data.
The update forms are actually four separate pages, one for each
“mode:” add, delete, change, view. Each procedure may override
security and style sheet preferences within an application, allowing
you to make an update for a particular table different. The security
options also allow you to specify which level of user access can call
for each type of update.
Appearance
The default update form allows for a column of labels and a
column of entry controls. The runtime HTML template is fully
editable in most HTML layout tools. This allows the developer/
White Paper
June, 2002
Page 34
designer to move data and column label tokens to wherever they
wish. All formatting is applied via style sheets.
In the example below, a view only update form contains a link (at
bottom, not visible) to an editable update form. This link appears
only when the end user has sufficient security rights. The updatable
form would contain entry fields with the data (which appear only as
text fields in this illustration).
Selects
Where a foreign key/primary key constraint between two tables
specifies that a value in the child table must be present in the parent
table, Clarion/ASP can place a list box containing those values in
the update form. In fact, the list box may contain a completely
different field in the related table, yet return the value
corresponding to the proper field. This is important in working
with normalized databases. An order form, for example, may
contain a product ID number; yet it’s much easier for the end user
to choose by product name than by number. This is illustrated
below. The end user selects “Queso Cabrales” from a dropdown
White Paper
June, 2002
Page 35
list, but the ASP page writes product number 12345 to the row
when the end user presses the select button.
Alternatively, the developer may choose that a popup window
appear with a navigable table, so that when the end user clicks on a
choice, the popup closes and the proper value is transferred to the
edit box. This is the default because it is most suitable for cases in
which the related table may have many rows.
The select functionality is also provided for lists of items which
may be entered in the dictionary directly, as opposed to existing
within another table.
Validity Checking
An intelligent but compact Javascript function library allows for
validity checking on the client side, reducing unnecessary network
traffic. Functions may check data entry for numeric ranges, nulls,
and more. When an error is encountered, Clarion/ASP
automatically displays a message detailing the error so that the end
user may correct the entry. Formatting functions are also applied
both on read and write, allowing, for example, the limiting of a date
entry in a field, even though the DBMS sees it as a date/time field.
White Paper
June, 2002
Page 36
Conclusion
Clarion/ASP Provides a rich array of options for generating many
ASP pages each of which corresponds to a common business
application task such as querying a database, displaying rows of data
from a table or view, and displaying and or editing a single row.
The depth of automation in the process, the degree to which the
resulting pages can be integrated into an existing site, and the level
of customization offered to the web designer provide for superior
productivity with a high degree of “attractiveness” in the end result.
White Paper
June, 2002
Page 37
White Paper
June, 2002
Page 38

Clarion/ASP: Code Generating ASP Business Applications

Transcription

Similar documents

Contact no.(M):9780893349 jalandhar city

Kuluin prep powerpoint

assistant head/upper school director ap/ib news from the academic

Mikko Hypponen Chief Research Officer, F-Secure Mikko

assistant head/upper school director ap/ib news from the academic

ASPects July 2012 Convention Special Issue

CLARION HOTEL ARLANDA AIRPORT

Graduation Edition: Class of 2012

Quelques approches formelles pour tester la robustesse de