next up previous contents
Next: Data Propagation Up: Special Concerns Previous: Shared Variables   Contents

Regarding Values from Fieldspaces

Programmers must realize that MIC 2.0 implements a conservative instantiation routine. This brings up a couple of issues worth noting.

First, $fs-$>$get_field('field_name')-$>$value() and $fs-$>$field_name() might cause runtime errors as the field, though defined, might not be present at the time it is called, and thus calling an object method of nothing will cause your program to break.

The recommended solution is the use of exceptions, which, in Perl, are handled through the use of eval. One should learn about this command if one is not already familiar with it.

Secondly, even using evals, if one has code like:

my $var;

$var = 
  eval {$fs->get_field('acc_number')->value();};

$account->set_acc_number($var);

then although one will not have a runtime error, unexpected behavior will most likely occur. Remember that fields are only loaded if they are changed from their initial value, are in error, or a member of a group where one or more members fall into the previous definitions.7.4

Let us say that the acc_number field is intially blank or set to the value of the current account, if there is any. The customer goes in to page, fills in the account number, and it gets updated. The next day, the customer goes back to the page. We find that we already have an account number associated with the customer, so the account number will display the number that they filled in the first visit. After hitting submit (or whatever), when the above code is called, if the user has not changed the account number, then it will get set to blank. This is because the field will not be instantiated, so the eval statement will return undef and $var will get set to undef. To avoid this problem, one might check $@ or rethink code.


next up previous contents
Next: Data Propagation Up: Special Concerns Previous: Shared Variables   Contents