Design best practice for CYPEX applications is split across five tutorial areas. Each covers one recurring pattern you can reuse to build applications faster and make them more flexible.
Wiring GUI elements together
Two of the patterns deal with connecting screen objects so they feed each other with data.
- Autocomplete fields. A drop-down field can be added to an existing application by linking GUI elements together. Drop-down elements are fed from standard data sources, i.e. queries.
- Related table views. Two tables can be linked so that they depend on each other. The same idea behind linked objects applies to other types of GUI elements as well, and the method does not change; this is what gives developers flexibility and makes full use of the graphical editor.
User data and interaction behaviour
CYPEX handles a great deal of internal user and authentication management itself. One sample shows how to surface that data so it is quickly accessible to end users: the application is built by creating queries in the admin panel and laying out the screens in the visual editor.
Defining how elements on a screen interact is the real challenge in application building, and CYPEX offers various methods to configure those dependencies. The most common one is a dependency in which one object must refresh when some other object changes.
Scheduled email and refresh patterns
Sending an email is a so-called “built-in” task in pg_timetable. Once pg_timetable has all the configuration needed to send mail, SQL is used to populate the pg_timetable infrastructure that performs the sending; a CYPEX form is then built to display and gather the information required for those emails.
For on-screen dependencies, the refresh-after-save case is the standard example: a form is refreshed following the “Save” action.
