Skip to content
Snippets Groups Projects
Select Git revision
  • f4f32732349daf215e00b7aa76b08c09a493011d
  • develop default
  • documentation
  • B21786-wrapUnexpectedException-fatal-error
  • F10114glyphiconToFontAwesome
  • F21622-settings-table-changes
  • F17481_BS_Modal_window
  • F20975_Dynamic_DateTimePicker
  • revertB5221downloadModal
  • B21533-Hidden-Pill-Required
  • B21510_Validation_error_when_date_field_is_left_empty
  • F8044-Transactions
  • master protected
  • F12532-view-sip-in-Browser-consol-log
  • S21288-Store-Parent-Remove-Prefix
  • F21203-Render-MultiSql-Columns-like-Subrecord
  • F11535_ipa-qfq-db-editor
  • F21130-multiform-toggle
  • S20463-V-Store-not-updated-after-form-save
  • B18601-typeahead-sanatize-applied-to-value
  • F16113-MultiAction
  • v25.6.0
  • v24.12.0
  • v24.10.0
  • v24.7.0
  • v24.5.1
  • v24.5.0
  • v24.3.0
  • test-alfred20
  • v23.10.1
  • v23.10.0
  • v23.6.4
  • v23.6.3
  • v23.6.2
  • v23.6.1
  • v23.6.0
  • v23.3.1
  • v23.3.0
  • v23.2.0
  • v23.1.1
  • v23.1.0
41 results

Form.rst

Blame
  • Form.rst 217.75 KiB

    Form

    General

    Important

    Primary key: QFQ expect that each table, which will be loaded into a form, contains a primary key called id. That one should be autoincrement. It's not necessary to create a FormElement id in a form.

    • Forms will be created by using the Form Editor on the Typo3 frontend (HTML form).

    • The Form editor itself consist of two predefined QFQ forms: form and formElement - these forms are regular updated during installation of newer QFQ versions.

    • Every form consist of a) a Form record and b) multiple FormElement records.

    • A form is assigned to a table. Such a table is called the primary table for this form.

    • Forms can roughly categorized into:

      • Simple form: the form acts on one record, stored in one table.
        • The form will create necessary SQL commands for insert, update and delete (only primary record) automatically.
      • Advanced form: the form acts on multiple records, stored in more than one table.
        • Fields of the primary table acts like a simple form, all other fields have to be specified with action/afterSave records.
      • Multi form: (multi-form) the form acts simultaneously on more than one record. All records use the same FormElements.
        • The FormElements are defined as a regular simple / or advanced form, plus an SQL Query, which selects and iterates over all records. Those records will be loaded at the same time.
      • Delete form: any form can be used as a form to :ref:`delete-record`.
    • Form mode: The parameter 'r' (given via URL or via SIP) decide if the form is in mode:

      • New:

        • Missing parameter 'r' or 'r=0'
        • On form load, no record is displayed.
        • Saving the form creates a new primary record.
        • E.g.: http://example.com/index.php?id=home&form=Person or http://example.com/index.php?id=home&form=Person&r=0
      • Edit:

        • Parameter 'r>0'
        • On form load, the specified record (<tablename>.id= <r>) will be loaded and displayed.
        • Saving the form will update the existing record.
        • E.g.: http://example.com/index.php?id=home&form=Person&r=123
      • Providing additional parameter:

        Often, it is necessary to store additional, for the user not visible, parameter in a record. See :ref:`form-magic`.

    • Display a form:

      • Create a QFQ tt_content record on a Typo 3 page.
      • Inside the QFQ record: form = <formname>. E.g.:
        • Static: form = Person
        • Dynamic 1: form = {{form:SE}} (the left form is a keyword for QFQ, the right form is a variable name)
        • Dynamic 2: form = {{SELECT f.name FROM Form AS f WHERE f.id=...}} (the left form is a keyword for QFQ, the right form is a variable name)
      • With the Dynamic option, it's easily possible to use one Typo3 page and display different forms on that specific page.
    • If a form is edited using the JSON form editor then a backup of the previous version is saved. See :ref:`formAsFile`.

    Form process order

    Depending on form load / save or record delete, different tasks are performed. Processing is divided into:

    • Native FormElements like: input, select list, checkbox, radio, ....
      • upload elements are categorized as native FormElement, but will be processed later.
      • pill, fieldset and subrecord elements are only processed during form load, they do not impact save or delete.
    • Action FormElement like before..., after..., sendmail ...

    Each FormElement has an order.