Next: Writing Pile Source
Up: Using MIC
Previous: Using MIC
  Contents
Execution Flow
Of course, it is important to understand how the myriad of pages,
fieldspaces and bits will be executed. The first thing that
happens when a page is requested is that the web server will receive
the request and do its thing. Presumably, it will have some way of
knowing that the request should be handled by a pile, say an extension
or a certain directory and will redirect the request to the pile
driver.
The pile driver then picks it up and will do its stuff. As far as the
MIC coder's code goes, this involves:
- the setup subroutine in the control file is called
- the page (.html or .mic) is called
- if there is a form tag which has a MICfieldspace associated with
it, then:
- the code within the MICfieldspace tags, but external to all
groups and all MICdefines is called (this is the fieldspace setup
code)
- if one or more dynamic field groups are requested or mandated to
be instantiated, then the group setup code is executed for each, with
the appropriate index number being specified as is proper for the
above mentioned field groups; the resulting object definition, if any,
is retained for the next step
- all field default code, both static and dynamic, is called
unless MIC finds any given field to be internally maintained, in which
case the initial value is loaded from some external, fieldspace
implementation specific data retention object (e.g., a CGI object or a
database table)
- all arbitrary field code is run for instantiated objects
- the cleanup routine is called
For more on the rules and specification governing fieldspaces and
forms, see section 4.3 for more on forms, section 4.3.4 for more on default and arbitrary field code, and section 9.2 for specifics on MIC-compliant fieldspace
implementations.
Next: Writing Pile Source
Up: Using MIC
Previous: Using MIC
  Contents