The examples below use functionality from the
sadjcore Django app, which is intended to provide a useful set of utilities for your application construction: you may have your own alternatives or preferred solutions. Feel free to use them, or not, in your application as you wish.
Frame and User Interaction
The Sadj default application frames contain a
sadjHiddenControls Django form, allowing the use of simple ajax calls via the Django forms architecture, without having to implement new forms for specific tasks, see Ajax Django Access for more details.
extractJsonFromRequest routine pulls the request body content into a regular Python dict, regardless of whether it originated in the hidden form or a dedicated inline form.
initialReturn routine extracts keys such as 'page' from this dict into the standard Json response format expected by many of the
sadjcore.js functions, to help control and debug asynchronous message flows.
default_user_parameters function returns key template parameters, including user-specific theme settings for authenticated users. It is recommended that Sadj views use this function if you wish to take full advantage of other Sadj features.
Save and Get Settings
sadjcore contains the definition for a generic user settings table, and the following:
user_can_save_settings(user)- Whether the user is allowed to save settings
save_setting(request, name="theme")- Sets a value in the table
get_setting(request, name="theme")- Retrieves a value from the table
Table Update Utilities
This is a generic helper routine, to enable easy updates from the UI; you will see it used in the
update_demo_data function in the demonstration site to enable editing from a table in the browser without any requirement for explicit naming of fields in the server code.
It accepts a request such as:
"page" : "devices" - UI page to echo back results
"element" : "table6" - UI HTML element to echo back results to
"type" : "athletes" - meaningful name associated with the data type/table
where 'updates' is a list of dictionaries, each containing a lookup key and name:value pairs of updates to make.
key="(new)" triggers new-record creation.
update_demo_data function illustrates accessing the data model via a lookup based on the incoming data-type name, so that a range of different tables can use the same update call.
update_one_record, created_one_record, delete_one_record
These are called by
update_multiple_records, but are also accessible directly, as shown in the demonstration routines.