Here's the form itself — the input fields, the validation, the layout.

1 ADDING A NEW CONTACT

This is the input block itself — the fields, the validation, the footer buttons. Trimmed to the fields that matter:

emxml_ajxInpFcontact.xml
<block>

    <form type="form" id="addcontactform" name="addcontactform"
          app="bcforms" submod="insertcontact">

        <div class="modal-body">
            <table id="ft1" class="table">
                <tr>
                    <td>
                        <label for="contact_name">Name *</label>
                        <input id="contact_name" name="contact_name"
                               placeholder="Full name"
                               mandatory="Name is required" />
                    </td>
                </tr>
                <tr>
                    <td>
                        <label for="email">Email *</label>
                        <input id="email" name="email"
                               placeholder="Email address"
                               mandatory="Email is required" />
                    </td>
                </tr>
                <!-- department, job_title, phone follow the same pattern -->
            </table>
        </div>

        <!-- Footer inside the form, so validation and submit stay wired -->
        <div class="modal-footer">
            <button type="button" class="btn-ghost"
                    onclick="bcModal.close('bcmodaloverlay')">Cancel</button>
            <button type="submit" class="btn-primary">Save Contact</button>
        </div>

    </form>

</block>
<block> root
Modal input files root at <block>, with a real <form> nested inside — same rule as every other block file in this arc.
one real <form> tag
Everything the old wrapper carried in child elements — the action, the method, the validation script reference, the single-page panel declaration, the setup…() call — is gone. The engine derives all of it from id= and submod= and generates the submit handler itself.
type="submit", no onclick
This is what fires the generated validation and AJAX submit. Adding an onclick here would either skip validation or fire the submit twice — Cancel is the only button that needs a manual onclick, because it just closes the modal.
mandatory="…"
Validation is a plain attribute on the field, and the attribute's value is the failure message. No separate validation block to write and keep in sync. numeric=, date=, alpha=, mask= and chkfld= work the same way.
submod="insertcontact"
An attribute on the form now, not a hidden input. It names the processor block that handles this submission — the piece post 7 builds. Any other hidden field you need is still written as a real <input type="hidden">, as the edit form below does with contact_id.
2 Updating an existing contact

Updating one is different — the form needs to display the current record before anything can be changed. That's where a form's own SQL block comes in, and the same applies to any form that needs to show existing data, not just this one.

emxml_ajxUpdFcontact.xml
<block>

    <!-- Prefill first: runs before the form renders, so every field opens filled -->
    <sql>
        <query name="contact_prefill"><![CDATA[
            SELECT contact_name, email, department, phone
            FROM   contacts
            WHERE  contact_id = '%contact_id%'
            AND    dept_id    = '%deptid%'
            LIMIT  1
        ]]></query>
    </sql>

    <form type="form" id="editcontactform" name="editcontactform"
          app="bcforms" submod="updatecontact">

        <input type="hidden" name="contact_id" value="%contact_id%" />
        <div class="modal-body">
            <table id="ft1" class="table">
                <tr>
                    <td>
                        <label for="contact_name">Name *</label>
                        <input id="contact_name" name="contact_name"
                               value="%contact_name%"
                               mandatory="Name is required" />
                    </td>
                </tr>
                <tr>
                    <td>
                        <label for="email">Email *</label>
                        <input id="email" name="email"
                               value="%email%"
                               mandatory="Email is required" />
                    </td>
                </tr>
                <!-- department and phone follow the same pattern, each pre-filled with its own %token% -->
            </table>
        </div>

        <div class="modal-footer">
            <button type="button" class="btn-ghost"
                    onclick="bcModal.close('bcmodaloverlay')">Cancel</button>
            <button type="submit" class="btn-primary">Save Changes</button>
        </div>

    </form>

</block>
<sql> at the top
Same rule as post 5's detail screen — a single-row query, run once, before anything renders, and written as the first child of <block>. Put it after the form and every value="%token%" below opens showing the literal token text instead of the record.
value='%token%'
Every field's starting value comes straight from that query — %contact_name%, %email%, and so on are filled in before the form ever reaches the browser, so the user sees their existing data, not empty boxes.
hidden contact_id
Doing double duty — it's what the prefill query filters on (WHERE contact_id = '%contact_id%'), and it travels back out with the submission too, so the processor in the next post knows which row to update rather than insert.
Validation is declared per field, right where it lives — not written separately and kept in sync by hand.
3 Rendered live
app.example.com/manager/contacts
Add Contact
×
Full Name*
Email*
Department
Phone

And the Edit form, opened for an existing contact — every field already filled in by the prefill query above:

app.example.com/manager/contacts/1042
Edit Contact
×
Full Name*
Email*
Department
Phone

Click Save on either form right now and nothing happens — there's no processor behind either one yet. That's deliberate: the next post is entirely about what submod='insertcontact' and submod='updatecontact' actually route to, and what "Save" needs to do once it's clicked.