Kexi/Plugins/AutoForms: Difference between revisions

Latest revision as of 21:49, 7 October 2024

AutoForms are not implemented in KEXI but will be very useful.

History

2005: There was old code in plugins/autoforms/ directory in Kexi 0.x quickly disabled
2005: Form Templates/Wizards discussion started by ccpasteur, jstaniek
2014: plugins/autoforms/ removed in Sep in Kexi 2.9. Original maintainer was Adam Pigg.

Introduction

For a quick introduction to AutoForms see this find a book or tutorial for MS Access.

To automate forms creation, one needs some sort of template that can be used to generate the form when only input data source and certains form configuration/parameters are available.

There are several approaches to form templates. Two main approaches can be identified: real AutoForms and forms generated by an assistant.

Real AutoForms gives a certain amount of automation and round-tripping. A user access to certain settings provided by a template, visual or behavioral. There is no generation of physical form that can be later edited by the in the Design view. Instead the user can further alter the settings later. So Autoform is a form generated by KEXI each time it is opened by user.

Advantages:

The change of form's data source is reflected in form design automatically. For example, new fields are added, removed fields disappear, changes made to types are recognized in the choice of form widgets.
Potentially, the form design can be later used to automatically generate forms for different media such as web or mobile interfaces with similar look and feel.

Disadvantages:

The user is unable to edit deep details of every fragment of the form, such widgets or their relative position, as long as the template parameters are not sufficient to perform the task. So the feature set of templates should be sufficient for real use cases.

An action is needed to enable the user to edit the form. The opposite action (turning edited form into a generated autoform) may also be possible, but all user changes would be lost.

Note that all the differences between KEXI and MSA's autoforms are also valid for KEXI and MSA's autoreports.

Types of AutoForms

A number of predefined properties are available to change visual and behavioral aspects of such a form, e.g.:

data source - a query or table
form layout: at least three layout types would be possible:
- 'columnar' mode, with widgets displayed in columns (the most basic)
- 'grid' mode with the possibility of putting widgets into a grid by lines or columns,
- 'justified' mode, the same same as in MSA
- 'flow' mode, a grid which numbers of lines and columns change dynamically depending on the available area; it is inspired by the a flow layout of a Qt example app; this layout cam be also added as a new item in the Layout menu; to store it and for compatibility reasons, it can be saved as a 'grid' type, with additional "customLayout" property set

Forms generated by an assistant

These forms are fundamentally different from the "real" AutoForms because after the form generation, ordinary form is created and saved in the project. Such form can be then open the Design view and modified as it would be created by hand from scratch by the user.

Advantages:

The user has power to deeply alter the form design according to the needs, copy, remove or duplicate form's elements

Disadvantages:

Subsequent changes to the form's data source have no effect on the form's layout at all. This is not different from forms created by hand.

Common aspects of AutoForms and Form assistants

Regardless of the type of the form automation, the routines that generate forms based on data source design and metadata can be a single shared code. (this aspect shall be in sync with the planned use of Python as the KEXI-wide scripting standard)
It is advised that the logic of templates is implemented in a scripting to facilitate modification of power users and partners.

@@ Line 11: / Line 11: @@
 To automate forms creation, one needs some sort of '''template''' that can be used to generate the form when only input data source and certains form configuration/parameters are available.
-There are several approaches to form templates. Two main approaches can be identified: real AutoForms and forms generated by an assistant.
+There are several approaches to form templates. Two main approaches can be identified: real '''AutoForms''' and '''forms generated by an assistant'''.
-== AutoForms ==
+Real AutoForms gives a certain amount of automation and round-tripping. A user access to certain settings provided by a template, visual or behavioral. There is no generation of physical form that can be later edited by the in the Design view. Instead the user can further alter the settings later. So Autoform is a form generated by KEXI each time it is opened by user.
-Real AutoForms. A user access to certain settings provided by a template, visual or behavioral. There is no generation of physical form that can be later edited by the in the Design view. Instead the user can further alter the settings later.
+Advantages:
+* The change of form's data source is reflected in form design automatically. For example, new fields are added, removed fields disappear, changes made to types are recognized in the choice of form widgets.
+* Potentially, the form design can be later used to automatically generate forms for different media such as web or mobile interfaces with similar look and feel.
+Disadvantages:
+* The user is unable to edit deep details of every fragment of the form, such widgets or their relative position, as long as the template parameters are not sufficient to perform the task. So the feature set of templates should be sufficient for real use cases.
-The advantage here is that change of a data source's schema causes immediate update of form's layout. Other advantage is that a form design can be later used to automatically generate a web page with pretty the same look and feel.
+An action is needed to enable the user to edit the form. The opposite action (turning edited form into a generated autoform) may also be possible, but all user changes would be lost.
-Disadvantage: user is unable to do "anything" regarding to widget's positioning. To wipe out this disadvantage, we're allowing subforms to put inside (a subform do not need to be an autoform) and providing fairly rich set of autoform's settings.
+Note that all the differences between KEXI and MSA's autoforms are also valid for KEXI and MSA's autoreports.
+==Types of AutoForms==
+A number of predefined properties are available to change visual and behavioral aspects of such a form, e.g.:
+* data source - a query or table
+* form layout: at least three layout types would be possible:
+** 'columnar' mode, with widgets displayed in columns (the most basic)
+** 'grid' mode with the possibility of putting widgets into a grid by lines or columns,
+** 'justified' mode, the same same as in MSA
+** 'flow' mode, a grid which numbers of lines and columns change dynamically depending on the available area; it is inspired by the a flow layout of a Qt example app; this layout cam be also added as a new item in the Layout menu; to store it and for compatibility reasons, it can  be saved as a 'grid' type, with additional "customLayout" property set
 == Forms generated by an assistant ==
-These forms can't be called "real" AutoForms because after the form generation, user ordinary form is generated. Then it can be open the Design view and edited as it would be created by hand from scratch by the user.
+These forms are fundamentally different from the "real" AutoForms because after the form generation, ordinary form is created and saved in the project. Such form can be then open the Design view and modified as it would be created by hand from scratch by the user.
+Advantages:
+* The user has power to deeply alter the form design according to the needs, copy, remove or duplicate form's elements
+Disadvantages:
+*Subsequent changes to the form's data source have no effect on the form's layout at all. This is not different from forms created by hand.
+== Common aspects of AutoForms and Form assistants ==
-Advantage of this form type: obviously, user has power to tweak a form _if_ she wants to.
+* Regardless of the type of the form automation, the routines that generate forms based on data source design and metadata can be '''a single shared code'''. (this aspect shall be in sync with the planned use of Python as the KEXI-wide scripting standard)
-Disadvantage: subsequent changes to data soruce's schema have no effect in form's layout.
+* It is advised that the logic of templates is implemented in a scripting to facilitate modification of power users and partners.
-Main common feature of most templates is that these are procedural templates, i.e. number, source and type of database fields depends on data source user picked on creation.