- Assertions are not something most java programmers have dealt
with because assertions
are not part of the java language. Assertions are used usually at entry and exit points in
a function, they make an assertion about the incoming or return value. They must -always-
evaluate to true, otherwise the execution of the program halts. You could imagine writing a square
root function which only works with positive numbers. You could place an entry assertion
which asserts that the number presented to the function must be greater or equal to zero. You could also
place the same assertions on the return value since a square root cannot be negative. You can imagine how this aids in debugging;
if the exit assertion fails, you know your square root function has a bug. Or if the entry assertion fails, you know
the number passed in is bogus. This prevents the program from continuing operation in a known
bogus state and helps isolate the problem.
- The EntryAssertionManager (EAM for short) is similar to assertions in other languages, but stretches
the definition some. Web programming is the ideal environment for assertions. The webbrowser
is an untrusted source of information. If you are writing an online calculator, you may have
a field where the user can enter a number. However, the user could really enter in
a string, and possibly crash your program. If you've done any web programming before,
especially in java, you know you spend a considerable amount of time checking
types, null testing, and converting data into it's appropriate format. It would be much
easier if you could simply program your code, assuming everything is fine, and have
something else take care of converting formats, and confirming the data is not bogus.
- The EAM also stems from the idea that a single broker [or page] is may
actually have more then one action. The EAM allows you to define a name for each of the actions
which that Broker can perform. For each action you define, you also declare what form elements
are required for that action to function , as well as the type of each of those elements. When a web request
is sent into the Broker, it runs the request through the EAM, and the EAM determines what
action [based on the previous definitions] is actually occurring in this request. By passing
the EAM test, you know the form elements you declared are of the correct type, and the
required elements are present. This means you do not need to spend any time converting variables
or testing to see if required variables are present, because the EAM will
automatically convert the incoming variables to the type you defined. The EAM gives appropriate feedback to
tests which fail, so you can remind the user that they cannot take the square root
of a string.
- Declaring what form variables you use and their type ahead of time may seem like a tedious process.
It's something which programmers coming from the Perl and CGI world might be
particularly not accustomed to. However it makes code incredibly easier to read, much safer to
execute, and easier to maintain. Most web applications
trust the browser far too much. The user can easily tamper with hidden variables and add
unexpected elements to select boxes. Once you have declared all of the variables for a particular
action, anybody can walk up to the code and clearly see what variables are required to
function. They can
see that a Integer MessageID is required for the delete message button to work. A
startdate, endstate and message body are required for the create announcement button to work.
- With the EAM you get the best of both worlds. You get the added debugging facilities
of assertions, coupled with the manageability of code. However the extra time you spend
configuring the EAM is saved by the convenience functions it provides. Such as variable
conversion, and action recognition. The result should be cleaner more manageable
approximately the same time.