Introduction
The cost and problems of building
applications that can be used on multiple platforms, such as Macintosh and
Windows machines, has caused many organisations to consider the Web as an
alternative for application development. In an environment like a
University, where there is a mixture of different hardware and software
platforms that cannot easily be controlled or standardised, the use of the Web for
deploying applications is very appealing. Until recently, developing for
the Web has meant moving into an immature environment, lacking the tools that a
lot of us have grown to expect in the client/server world such as CASE tools,
debuggers, etc. In some cases, leaving us with simple text editors as our main
programming tool.
Curtin has been quite keen to provide a Web
interface to it's administrative systems for some time. However, it has
only been in the last 12 months that tools have started to become available
that provide a productive development environment for this to take place.
Having adopted Oracle 7 as Curtin's preferred database for administrative
systems and chosen Designer 2000 as our preferred CASE tool, Oracle's Web
Application Server and Designer 2000 Web Server Generator were of great
interest to us. We have now used these tools to commence work on several
Web applications, some of which are nearing implementation.
Although Curtin is not specifically trying
to achieve 100% generation (although that would be great), we are keen not to
perform any customisation of generated code that interrupts the generation
process. In this paper, I will briefly discuss the basic concepts behind
using Designer 2000's Web Generator, and discuss the issues and problem areas
when trying to remain in the "generation loop", whilst providing the
necessary security and functionality required by most application systems.
Designer
2000 and the Design Process
Designer 2000 is Oracle's CASE (Computer
Aided Software Engineering) tool which provides quite a number of tools
covering things such as process modelling, logical data modelling, physical
data modelling and generators, to name a few. In this paper, I will
concentrate on the Web Server Generator tools in Designer 2000. However,
I will also discuss other parts of Designer where they have a significant
impact on the output produced by the Web Server Generator.
Being a key product in Oracle's development
suite, Designer 2000 is tightly integrated with Oracle's DBMS (DataBase
Management System). It can make use of Oracle specific facilities such as
Triggers, Constraints and Stored Program Units. In fact, the Web Server
Generator actually creates Oracle Packages containing procedures and functions,
which will produce dynamic HTML containing or based on data retrieved from an
Oracle database.
Most of the design process is exactly the
same as it is when using Designer 2000 to develop any other type of
application. For example, using the Entity Modelling tool is exactly the
same as if you were using Designer to generate an Oracle Forms application, or
even just a database. After all, that's what that component of Designer
is for, and is largely independent of whether it will be used for a Web
application or any other type of application. The Upper CASE tools in
Designer, such as the process modelling and entity modelling tools, can largely
be used without much consideration of their impact on the Web Server
Generator. In the few cases where there is an impact, I will make
specific mention of them in the following pages.
Likewise, in the main, the physical
database modelling tools can be used in the same way as for any other
development. The process used for the definition of tables,
relationships, constraints, domains and triggers is the same as for a non-Web
application. There are however, some decisions you can make whilst
designing your database that may make or break your Web application, at least
in terms of it working the way you expect. I will try to provide you with
some tips on what to consider when designing your database for use with the Web
Server Generator.
Besides "tweaking" your database
design to get the desired output from the Web Server Generator, the main
components of Designer 2000 that you will use when developing a Web application
are the Module Data Diagrammer, the Module Structure Diagrammer and the Web
Server Generator Preferences (See Figure 1). Once you have designed and
created your database, the basic development process for developing a Web
application is to set-up your application preferences and use the Module Data
Diagrammer to design each module of your Web application. It is largely
an iterative process of manipulating the settings in the Module Data Diagrammer
until the desired result is achieved. Changes to the generator
preferences can be made during development, but require existing modules to be
re-generated to make use of the new preferences.
Figure 1: Web Server
Generator Tools
Designing a module using the Module Data
Diagrammer basically consists of choosing a Base table for the module.
This table is the central table of the module, with other tables and List of
Value (LOV) tables also being added to provide look-up tables and master-detail
links to child tables based on their relationship with the Base table.
You can use the diagrammer to indicate whether various tables are to appear on
the same Web page or on separate Web pages. The diagrammer allows you to
specify which columns are to be used for the module, whether inserts, updates
or deletes are allowed. It also lets
you set a number of other settings that determine how each page for the module
will look and function.
Figure 2: Setting a
Base Table and Some LOV Reference Tables
The Module Structure Diagrammer can be used
to build a menu structure for your Web application, but from my experience this
is not really satisfactory, as it proves difficult to customise to any great
extent. It also lacks the ability to
take into account any parameter passing that needs to be done between modules
or from the security login screen. I have instead built a menu screen
using the Module Data Diagrammer based on a menu table in the database that
defines each menu item, including an appropriate image and can pass the appropriate
parameters to the next called module such as the employee number.
Web
Server Generator Preferences
Getting to know the Web Server Generator
Preferences before you start a Web application is a very good idea. There
are a lot of settings that you can use to standardise your application
and control the way it looks and functions. These preferences can be set
across the whole application, by module or for areas within a module.
Most of the preferences deal with how your application will look such as
colours, captions on buttons, which buttons will appear, standard headers and
footers.
Figure 3: Web Server
Generator Preferences
Screen
Design
The Web Generator will produce a Web
application with a pre-defined approach to screens and their layout.
Although some aspects of screen layout can be modified, you cannot really vary
too much from the default without incurring the cost of major
customisation. An application built using the generator can basically
have the following screen flow for each module generated:
1. Query screens, allowing the user to enter some selection criteria to
restrict the records retrieve on the Record List screen.
2. A Startup screen that is like an "About" page which is
linked to the Record List screen.
3. A Record List screen that displays a list of records according to
selection criteria passed.
4. An Update screen which appears when a record is chosen from the
Record List screen, allowing the user to update or delete the selected record.
5. An Insert screen which appears if the "Add New Record"
link is clicked on the Record List Screen.
6. A Delete screen which is really more of a delete processing screen
as the actual delete is initiated from the Update screen, with a success or
error message following the delete appearing on this screen.
In addition to these screens, the module
may also have some List of Value (LOV) windows defined for particular fields on
the Update or Insert screens that allow the user to choose from a list of
values. These LOV windows are defined based on the relationship between
the field in the base table and it's relationship with another
"look-up" table using a foreign key relationship.
Figure 4: Record List
with Custom Headers and Footers
Figure 5: Insert Screen
with Custom Headers and Footers
Figure 6: Update Screen
with Custom Headers and Footers
Figure 7: Delete
Processed Screen (Note lack of specific headers)
Of the above screens, all besides the
Startup screen can be made available by selecting the appropriate setting in
the Module Data Diagrammer. As stated in the section on generator
preferences, the Startup screen is made available by setting the MODALR
preference. You cannot alter the order in which the screens will appear,
but you may choose a Frames or Non-frames version, which have slightly
different screen flow.
Herein lies a basic question as to whether
the generator should be used. If you are not happy with the screen flow
it produces, changing it would involve significant customisation of the
generated code which can be a few thousand lines in length! If this is
the case, it is probably best that you consider using another development tool
or writing the application by hand as this would probably prove easier to
control and quicker overall. It all depends on how far from the generator
you want to deviate.
Another thing to consider regarding screen
design using Designer's Web Generator is it's reliance on the relationships
defined in it's repository. It will determine how a LOV window should
operate based on the relationships defined between the base table and it's
reference or child tables. The generator deals best with situations where
a page gets it's data from a single table as opposed to using table joins
between a number of tables. Using views to make your data appear as
though it is from a single source is quite useful, especially for
look-ups. You can also define relationships between the views and tables
that are not actually implemented in the database, but purely exist in the
repository to allow look-ups to be built. It is best that you design your
application so that each page of a module is updating only one table at a
time. There are restrictions on applying updates to views, and building a
module based on multiple tables does not generate an application where the data
appears as to come from one source.
Surrogate
Keys vs. Natural Keys
In my discussion of the design process, I
said that generally you could design your database without too much
consideration of whether you are building a Web application or some other
application. The use of surrogate keys or natural keys is one area that
can affect how your application eventually works. One thing to remember
if you are planning to use natural keys such as employee numbers, invoice
numbers and dates of processing, etc. is that the generator will produce an
application where these fields are not updateable. This makes sense, but
may catch you unaware if you assume that you will be able to update a field
that is part of a table's primary key.
There are some other implications of using
surrogate keys or natural keys. When natural keys are used, it is often
possible to provide a better "drill-down" type effect when moving
from one module to another and using LOV windows. For example, it is
possible to have two look-ups on a screen, one for building and one for room,
and if you choose a building using the building LOV window, the room LOV will
only show you the rooms that are related to that building. This does
depend on this information being built into the database design. However,
if you had used surrogate keys, the LOV for room would not provide this
capability due to the use of a simple sequential number as the room look-ups
key instead of a combination of building number and room number.
Another problem that may occur is to do
with security. The keys used by a module are usually passed around as
parameters from page to page either as hidden fields, which are not visible but
are contained within the HTML produced, or as part of the URL (Uniform Resource
Locator). When building your application, you will need to be very cautious
about checking the parameters being passed to each page to prevent security
breaches. There are still some areas where this parameter checking is not
entirely foolproof and it is debateable as to whether the use of natural keys
or surrogate keys offers better security.
As an example, if using natural keys, you
would need to provide a valid combination of parameters to a page in order for
the page to display the information for that record. This may be more
difficult to guess than a sequentially generated number. However, if
you're dealing with a situation where the person attempting the breach knows
their "victim" and can determine things such as their employee number
and other key components, this may be more of a problem than a random number
where the attacker cannot associate it with a particular person. For
these reasons it is very important that you check the key information being
passed before displaying a record.
In all the Web applications that Curtin has
developed up until now, we have opted to use surrogate keys. There are
some cases in which we are or have considered using natural keys, but have not
done so as yet. I'm afraid the jury's still out as to which is the
recommended approach as both offer their own advantages.
Menus
& Navigation
Using the Module Structure Diagrammer in
Designer 2000, you can define a hierarchical diagram between the modules of
your application as well as some menu modules that form the basis of
sub-menus. This will generate menu pages that are fairly simple and
contain basic links to each of your modules using a description or even an
image. Although this seems useful, in it's current incarnation it is
pretty limited. This is due to the lack of customisation that can be
performed and it's inability to use the parameters defined between modules.
Figure 8: A Sample
Module Structure Diagram
At Curtin, for example, a user must first
logon using a security screen which prompts the user for their employee number
and PIN. Validation of this information is performed and, if successful,
they are to be presented with a personalised menu of only the options that they
can choose. Also, when the user clicks an option off the menu, we want
them to only see data belonging to them. This means that the module being
called needs to know who they are so that a restricted number of records are
returned. This cannot be easily accomplished using the Module Structure
Diagrammer. Instead, I have used a table to define all the items that are
to appear on the menu, and used the Module Data Diagrammer to build a module
based on that table. I then use some custom routines that are called by
the module to define whether the item is a heading or menu item and attaches
the users ID to the call to the module to be selected.
Figure 9: Menu
Generated Using a Table as per Curtin Technique
So, at this point I have stepped outside
100% generation, although I've remained in the generation
"loop". That is, I can still use the generator without fear of
loosing any custom routines. They can be thought of as external
libraries. It is areas such as dynamic menu creation, security and
dynamic headings and footers that you are really left with no alternative than
to write your own routines, although this shouldn't scare you as you can achieve
quite good results by doing so.
As for navigation, the generator doesn't
really provide any, relying on the user to use the navigation controls provided
by the browser. In some ways this is understandable, but in other ways
it's a bit lacking. For example, if in attempting to update a record, a
user makes several unsuccessful attempts producing errors, they will need to
press the "Back" button several times in order to return to the
record list and see ungainly messages along the way. Likewise, there is
no provision to return back to the main menu or the beginning of that
module. The way that we have done this without customising the generated
code is to build a navigation bar as part of the standard header on all pages.
We tried using a facility in Designer to
specify particular text to be place at the top of each particular type of page
(E.g.. Record List, Insert, Delete), however we found that the Delete page
would never use the text that we specified, leaving that page without
navigation controls whilst all others worked. This was not satisfactory
for our application, so we had to use the standard header setting in the Web
Server Generator Preferences to call a routine which produces the header and a
navigation bar depending on which page it's called from. This was not
easy, as trying to use the Oracle Web Server routine
"owa_util.get_cgi_env" to tell us which page was making the call
wouldn't work due to the way the generator nests it's routines. Instead,
we had to use Oracle PL/SQL Web packages to generate dynamic HTML containing
JavaScript to determine which page we were on and display the appropriate
navigation controls. This is a little messy, but produces the desired
results.
Calling
External PL/SQL Routines
Calling external PL/SQL routines from
your modules to add extra functionality to your Web application is quite useful
and powerful. There are however, some limitations on how this can be
done. The following is a list of things you need to remember when trying
to use external routines in your application:
1. It must be a function which returns a value, even if only a space or
NULL.
2. The function must be within a package.
3. You need to add the name of the package to the PKGLST preference for
the Web Server Generator.
4. If you have multiple packages listed for the PKGLST preference,
ensure that they are comma-separated and that there are no spaces or special
characters in the package names or separating the listed packages.
5. You can make calls to the package in the Preferences Diagrammer (for
headings, etc.) or in the Module Data Diagrammer (when defining "Page
Text").
6. You need to call the function in the format package.function(param1,
param2, ....)
7. Note: Do not place a semi-colon at the end of the call.
8. You may need to specify a PRAGMA_RESTRICT for some functions to
guarantee that they do not update the database as, depending on where you place
the call, the function may be generated as part of a SELECT (derived fields).
9. If you try to pass one of the module's columns as a parameter in a
call using the "Page Text" tab in the Module Data Diagrammer, you
will get a generation warning and the module wont auto-install. However,
if you manually click the "install" button, it will install and work
fine. To pass a column as a parameter in this way, it is always prefixed
with "p_". This will only work for the Query, Insert and Record
List pages.
In the applications that we have developed
so far, we have used calls to external routines to perform security checking,
provide navigation controls and create custom headers and footers. We have also used custom routines to create
links to special pages that could not be produced using the generator, such as
employee pay slips.
Security
This is a key concern when building
Internet applications, and Intranet applications for that matter. It is
also one of the areas which is still to prove itself robust compared with
traditional forms of application development. The stateless nature of
general Web applications introduces several problems associated with having to
"re-check" everything passed from one page to another, regardless of
whether it was checked on the previous page. There have been some
attempts to address this problem such as the use of hidden fields in HTML,
Cookies, state tables on the server and more "stateful" Internet
programming environments such as Java and ActiveX. In my work with the
Oracle Web Generator, I have not made use of the latter two, but have used a
combination of the first three.
Hidden fields are the least secure of the
alternatives, simply hiding the parameters and their values in the HTML
source. The HTML page may be saved, it's parameters modified, and then
re-submitted to the Web Server. This should only be used for passing
background parameters that you don't want the user to see, but you will
probably need to verify when received by the Web Server anyway. The
generator uses quite a few hidden fields to store various types of information
in the generated application.
Cookies are a slight improvement on hidden
fields in that they are a bit more difficult to manipulate, but it is still
recommended that you cross-check key information against data stored in the
server (state tables). This is the approach we have adopted to use in
conjunction with the Web Generator. When the user logs into the system, a
unique session ID is generated for them and stored in a cookie along with an
expiry time. As the user moves from page to page, the values stored in
the cookie are checked against database tables to compare their values as well
as the IP address of the client machine and several other bits of
information. The session expiry is also updated on each page access so
that, following a prolonged period of inactivity by the user, it has the effect
of logging them out so that they need to be re-authenticated. The bottom
line is that, in the Web environment, you cannot trust anything being sent by
the client machine whether it is a Cookie or a hidden field. You have to
make it as difficult as possible for a potential attacker to determine a valid
combination of parameters and crosscheck these parameters wherever possible.
This is an area which proved quite
difficult to address using the Web Server generator due to it's lack of
sufficient parameter passing and checking facilities, and with problems being
able to write cookies on each page using the generator. The only way that
we were able to use Cookies to check the user's state before displaying each
page was to modify the WSGL library provided by Oracle to write the Cookie as
part of the page open function. This is because you can't just write a
Cookie from anywhere in your HTML source, you need to write it in the header
information for the page, even before the first HTML tag is used. No
matter where you place a call to an external routine in the Module Data
Diagrammer or preferences, it will always be too late to successfully write the
Cookie.
Another problem with using the generator
was actually checking the parameters being passed from page to page. The
following section discusses some of the problems that I have encountered in
trying to make our Web applications secure when using the generator.
Parameter
Passing
One of my biggest complaints about using
the Web Generator is its lack of provision for developers to be able to define parameters
to be passed between modules and to allow the checking of parameter
values. The generator will usually decide which parameters it will pass
from page to page within a module, usually dependant on the type of keys used
by the tables (surrogate or natural keys) and which columns are allowed to be
inserted or updated. There is a provision for you to indicate columns as
being "input parameters". This means that the generator will
generate the required code to limit the records returned to the Record List
screen based on a value provided for that column. You cannot however
specify that the parameter must be passed. For example, if you specify
that the employee number is an input parameter, it will show only that
employee's records if a number is passed, but will show you ALL if not.
To force particular parameters to be passed
in our applications, we have had to make calls to custom routines in the Page
Text area of the generator to see if the particular parameter was passed, and
raise an exception if not. This generally works well, except for the
Update screen tab, where you cannot pass a column as part of the parameter list
to an external routine. This is a bit of a problem, as this happens to be
the most damaging screen. If this screen is called without sufficient
checking, a malicious user can view, update or delete someone else's
record!
About the best you can do is have triggers
and audit trails that check the user's ID using the Cookie and state table, and
determine whether it is valid for them to be updating or deleting that
row. If they are not allowed to
manipulate that record, produce an exception or record the access in the case
of viewing the record. You also need to remember that for them to be able
to do this, they would need to have successfully logged into the system and
have a valid session established in order to pass the session checking.
You may choose to trust your employees or adopt a strong "post-audit"
philosophy where you don't prevent this from occurring, but deal harshly with
people who breach your company's policy on such matters J
Figure 10: Using the
Page Text tab to call an external routine to check parameters
The Web Server Generator also has no
provision to indicate that you want a column to be "insertable" or
"updateable", but not displayed such as when using hidden
fields. This could prove useful in setting some parameters in the
background for use on subsequent screens or as part of keys for look-up
windows. Instead, you are usually only left with database triggers to set
background values, which is not always sufficient for producing the desired
results at the client end with such things as list of values.
Setting
Default Values
When using Designer 2000 to generate Web
applications, there are a number of places where you can define the default
values to be used for particular fields. In a lot of cases, it would make
the most sense to define these at the table level so that they are applied
throughout your application. There does however seem to be a problem in
the release of Designer that we are using (release 1.3 for Win95), where if we
specify a default value for a column with anything but the most simplest of
defaults (E.g. sysdate), we will get errors generating the module's API. The API (Application Programming Interface)
defines validation rules against the fields in a table using a package.
This seems to extend to defaults such as 'N', since the generator produces code
where it places this in another set of quotes (''N''), producing errors.
We have decided that it is best practice to
define any defaults for the Web application using the default field provided in
the Module Data Diagrammer. This seems to work with the least number of
problems, but hopefully this will be corrected in future releases of Designer -
fingers crossed.
Derived
Fields
The Module Data Diagrammer has a provision
to specify derived fields for a module. These are so that you can create
your own fields, derived from the columns that you have selected for your
module, as the name suggests. What can be done using these fields should
not be under-estimated. For example, this is how we built a list of
employee pay slips with a link to an external routine that actually formatted
the pay slip based on the parameters passed. It is also how we managed to
build a dynamic menu, generated from a table containing the menu titles, their
respective URL and an image. In both cases, column values were passed to
external PL/SQL routines to generate dynamic HTML.
Figure 11: This is
where you enter derived field expressions
The generator places the text you type in
here as part of a SELECT statement as it expects that you are going to perform
some sort of manipulation on one of the fields used by the module. This
means that if you are going to use a derived field to do a call to an external
routine, you will need to remember that it will need to guarantee that it will
not update the database. To do this, you will need to specify
PRAGMA_RESTRICT_REFERENCES for that routine, as well as any routine that it
calls.
Data
Entry Validation
There are several options available to
allow you to perform data entry validation on the Web pages generated using
Designer. The first is to use Check Constraints. These are used to
validate input to a particular column in your database. There are a
number of limitations when using constraints. Firstly, a constraint
cannot refer to a system variable such as sysdate. It is also applied at
the table level and therefore across the whole application, with fairly limited
logic that can be associated with it. The generator will use the error
message defined against the constraint in the Repository Object Navigator (RON)
for the error message displayed on violation of the constraint. A key
advantage to using constraints is that, in some cases, the Web Generator will
be able to generate JavaScript to perform the validation in the client's
browser (provided it supports JavaScript) without having to return to the
server for validation.
Designer will not always produce JavaScript
to validate a check constraint. For example, it will not produce
JavaScript to validate constraints that use date fields or commands such as
"BETWEEN" and "LIKE". There is a full list of the
supported, and unsupported, functions that can be used with JavaScript
validation in the online help within Designer. Another thing to remember
is that the validation is not performed until a button is clicked such as
"Insert", "Update" or "Delete", whereby it will
pop-up an error message dialogue and move to the first field failing validation.
There is no "gain focus" or "loose focus" JavaScript
validation in the current release of the generator.
Designer will also generate JavaScript to
ensure the following:
¨
Mandatory fields are entered;
¨
Correct precision is used for numbers
where precision has been specified;
¨
Number fields are not longer than the
underlying table will accept as defined in the RON;
¨
Text fields specified as upper-case
are converted before being applied to the table; and
¨
Number fields are within the range
specified by low and high value properties.
So that the validation can be performed on
browsers that don't support JavaScript, the generator also produces an API
package for each table that will perform the validation if it cannot be done
using JavaScript.
Another method of performing data
validation is to restrict what the user can enter using Pop Lists, Radio Boxes,
List of Value windows, etc. All bar the LOV windows can be created using
either domains or a reference table in the database. If a domain is used,
it can cause values to be hard-coded into the generated application or use a
codes table called CG_REF_CODES. Using domains can be quite useful, but
is best for small, reasonably static code sets. With domains, the code
and not the description will also be shown on the Record List if it is displayed
there. This may be alright for domains such as "Y" or
"N" for "yes" and "no", but is not really
satisfactory for codes such as "0345" for "Hungary".
If you use your own reference tables, with
relationships defined with your module's base table, you can create LOV windows
or any of the previously mentioned controls such as Pop Lists. This is
preferred for large code sets as the LOV window will have a selection criteria
option to allow the number of records returned on the list to be reduced.
It also allows you to specify a column or columns on the LOV window to appear
on the pages of the module. For example, if the reference table contains
a list of positions with their title, commence date, salary, etc., this
information may be displayed on the Record List, Update or Delete screens when
a record is selected from the list. You need to be a bit careful when the
LOV is mandatory and the user can type in an invalid value. In this case,
you will also need to perform some validation using the final method of data
validation - Triggers.
Figure 12: A LOV Window
showing several fields from the reference table
Triggers are the most powerful of the data
validation methods, as you are able to use almost all the capabilities
available to you with PL/SQL. If no other method of validation will work,
this is usually the last resort before resorting to customising code. If
you use triggers to perform data validation, you will need to use the raise
application error command to cause the Web Server Generator module to cease
execution and display the error message.
The display of error messages was another
area where we chose to modify the Oracle WSGL packages. Although we could
use Triggers and our external routines to halt execution using the raise
application error command, due to the often very nested nature of the
generator's calls to procedures, it would quite often produce a number of other
messages following the initial message.
This was especially the case if the error resulted from a Trigger.
This was quite untidy, and made it difficult for the user to know exactly what
the error was, especially if it was something as simple as the "job number
you have entered does not exist". We modified one of the packages so
that it would only show the first error produced, which would be our message.
Conclusion
So, to the question of whether it is
actually possible to achieve 100% generation using Designer 2000's Web Server
Generator. As you can see from this paper, there are quite a few areas
where the generator will not be able to do some of the things you might want it
to - at least, not yet. It does raise an interesting point though.
The generator is actually capable of generating a working application, and if
this is your definition of 100% generation, then it can achieve 100%
generation. What needs to be remembered when using a generator, is that
it will generate output to a pre-defined methodology or approach.
If the approach Designer takes is
acceptable for your application, then you are likely to gain significant
benefit from what a generator such as Designer 2000's has to offer. If
not, and you want to make your application work in a different manner, you are
likely to encounter many problems and spend more time and money trying to get
the generator to work the way you want (if that's possible at all).
In the applications that we have developed
at Curtin, we still have to write some routines manually and then try to find
ways in which to call them from the generated application. So, in that
sense, we have not managed to achieve 100% generation, as we still have to
hand-write some routines. But this has come about because we have not
been happy to accept the "default" way the generator works. We
have expected greater functionality and a different look-and-feel in some areas
than what the generator is able to provide easily. With the Employee Web
Kiosk project, we have largely managed to stay in the generation
"loop" whilst incorporating these custom routines, so we are still
able to achieve significant benefits from it's use.
The closer you're willing to stay to the
generator's way of working, and therefore remain in the generation
"loop" where you can regenerate your application over and over again
in an iterative process, the more benefit you will get from it. The
biggest benefits gained from using the generator aren't so much in the initial
generation of the application, but in the maintenance and future enhancements
of your application where you can build on what has already been set-up.
If you get into the position where you're only using the generator to create a
"first-cut" of your application, and then customising the generated
code to achieve "your" approach, then you're probably not going to be
getting any real gain from it. If this
is the case, perhaps you should look at other alternatives such as tools that
provide a more productive environment in which you can write custom
applications.
Abbreviations
|
Abbreviation
|
Meaning
|
|
URL
|
Uniform Resource Locator
|
|
HTML
|
Hyper-Text Mark-up Language
|
|
PL/SQL
|
Procedure Language/Structured Query
Language
|
|
CASE
|
Computer-Aided Software Engineering
|
|
LOV
|
List Of Values
|
Table 2 - Abbreviations Used Through This Paper
References
¨
Oracle Designer 2000 Online Help
(release 1.3.2 for Windows 95).