next up previous contents
Next: MICdo Up: MICsubmit Previous: Syntax   Contents

Description

This tag is used to declare how to handle submit buttons within a MIC form. Each MICsubmit must be associated with an HTML control of the same name/value designation.

The name parameter should generally be common to all the related submits (MIC and regular) buttons for the form which this tag appears on (though not expressly non-unique for other forms, even those sharing the same field name space). The recommended value for the name attribute is [page name]_submit. That is, if the submit buttons are to appear on a page called `result.html', the recommended name value would be `result_submit.' This is mainly to keep things regular and easy to follow, although just about any name will work. If one has multiple forms on a page, then the recommended naming convention is 'result_submit1', etc. This is a style issue, though.

There are reasons to have MICsubmits with differing names, however. One is if one wants to implement variable goto's. Because of the way MIC works, the goto parameter cannot be a variable. That is, `goto=``$foo''' is not valid code. One could have something of the form:

<MICsubmit name=``test_submit'' value=``Submit''
 goto=``analyze_test''>
</MICsubmit>
<MICsubmit name=``quiz_submit'' value=``Submit''
 goto=``analyze_quiz''>
</MICsubmit>
<input type=``Submit'' name=``$destination'' value=``Submit''>

The name/value pairs are used to bind the MICsubmit with the standard HTML controls. Unlike MICinput and MICdisplay, a standard matching HTML control tag must also be included and will not be generated for you. The matching control will most often be a control button, but does not necessarily have to be. It may also be an image-map designation, or even some a hidden input or radio button. When the form is submitted, the value will be resolved control will be passed to the associated MICsubmit.

Thus, when one does have different names for the MICsubmits and their associated controls, one must be careful that two can never be defined at the same time. This is also a concern, actually, if they all have the same name. Thus, while the page flow can be directed by a hidden, a radio-button group, a button cluster, or an image map, having both a button cluster and a radio-button group will have unpredictable effects as MIC will not know which parameter to use.

The goto parameter defines the absolute URL within the system to go to after a successful submit. Refer to MICinclude for an example of this. This page does not necessarily have to be in the same directory and multiple submits can have pages in various directories (which is a win over regular HTML submits and form control). Realize however that each submit will share the target of the form tag, so to support multiple targets, it is still necessary to break the control over multiple forms.

If the attribute `unconditional' is included with the value of `true', then the goto parameter will be invoked even in case of error. This should be included only in the case where you want to go to the next page even if there are errors produced by the verifications associated with the MICsubmit where the unconditional parameter appears. This may be the case with certain styles of error reporting.

Note that old errors (from previous pages in a series) will not cause execution flow to redirect to the error page. Only errors produced by the current page/submit will be redirected.

The three optional included tags, vpage, vfield and vverify define pages (e.g., relative URLs), MICdefine'd fields and MICverify's, respectively, that need to be checked to see if there was bad data entered in the form. You may have as many or as few of these optional tags as you wish. These tags, and the vpresent tag, are discussed in section 4.4. Note that these tags only have meaning in the context of a MICsubmit and that no other tags or naked text has any meaning when contained by a MICsubmit.

Finally, the no-reset-dynamic attribute should be included if one wishes to start counting dynamic fields from the current dynamic field. This should generally only be included if a page is self-referencing, in which case MICrollover and MICrollback should most likely be used.

An example of a MICsubmit would be:

...
<MICsubmit name="application_submit" value="Submit"
 goto="application/process_application">
<vfield name="applicant_name">
<vfield name="applicant_ssn">
<vverify name="enough_money">
</MICsubmit>
<input type="submit" name="application_submit" value="Submit">

<br>

<MICsubmit name="application_submit" value="Cancel"
 goto="home">
</MICsubmit>
<input type="submit" name="application_submit" value="Cancel">
...


next up previous contents
Next: MICdo Up: MICsubmit Previous: Syntax   Contents