Tuesday, 22 April 2014

Adding More Interactivity to Your Forms

How to use Xataface, AJAX, and the export_json action to dynamically load data into your forms fields

The Xataface new record and edit record forms provide you with an easy (code-free) way to insert and update records in your database.   The fields.ini file enables you to customize which fields should be editable, and which widgets should be used to edit them.  In some cases you may find that you need to add more interactivity to the form than is provided out of the box.  One of the most common requests, for example, is to make a set of select widgets whose options are dependent on one another (e.g. If you have a "country" and "province" field, you want to automatically filter the options in the "province" select list to only show those provinces in the selected country).   I ultimately developed the depselect widget to address this use case, but there are still edge cases where the depselect might not be a perfect fit.

The Problem

Another request I sometimes get is to enable the user to load data into some fields of the form that is dependent of some partial data is has already been filled in.  Take, for example, a university job posting application where departments advertise their TA and Sessional Instructor positions each semester.  Every semester, the department administrator would add a new record to their "job postings" table that includes instructions for applicants, deadlines, etc...  In order to make the department administrator's job a little bit easier, they requested to have a button added to the form that would copy the posting instructions from a previous job posting into the current form's instructions field.  Then they could just make a few small changes to the instructions rather than starting from scratch each semester (or having to manually copy and paste from a previous record).

One option that is *very* easy to implement in Xataface is provide a default value for the instructions field.  This would almost solve the problem, but not completely.  Default values are loaded when form is generated.  But we may not know which instructions to "copy" into our field until the user has entered some data into the form (e.g. the department, semester, job category, etc...).  We really needed to add some dynamic behaviour to the form to allow the instructions to be populated after the form is generated, but before it is submitted.  Xataface provides the tools to achieve this without great difficulty also.

The Solution

  1. Use the before_instructions_widget block (read more about blocks and slots) to insert a button into the form.
  2. Add a javascript "click" handler to our button that takes some of the values entered into the form, makes an AJAX request to retrieve appropriate instructions, and replace the contents of the "instructions" field with the instructions that were retrieved.

Adding the Button

Reloading the form for the job_postings table reveals that the button has been added.

Notice, on line 2 of the above snippet, that we use the Dataface_JavascriptTool class (read more about JavascriptTool here) to include a custom javascript file that we will create next.

The Custom Javascript

There's a fair bit of code here, so let's go through it line by line.

Lines 1 to 3 show our "require" statements.  These are a special feature of the Dataface_Javascript tool to be able to use libraries that are included in Xataface, installed modules, and the application.  Here we require jQuery (because it just makes everything easier), the xatajax.form.core.js library (which provides some convenience functions for interacting with Xataface forms), and ckeditor.js (because the instructions field in this app happens to use the CKeditor widget and we need to use its API for setting the data in that field properly).

Line 4 is just the opening of our anonymous Javascript function which is used to provide a local scope to our Javascript.  This is best practice so that you don't pollute the global namespace.  This function is closed and executed on line 66.

Lines 5 and 6 is where we make local references to some global objects and functions.  Xataface's version of jQuery doesn't assign the jQuery object to the "$" alias by default.  This is to maintain compatibility with other libraries that may use this alias.  To make our lives easier, we assign a reference to the jQuery object that is only accessible to our local scope.

The Xataface.form.findField function (line 6) is a convenient Xataface function for finding the HTML fields on a given form that correspond with fields in the database.

Line 8 shows another level of wrapping and scoping inside the registerXatafaceDecorator() function.  This function takes a function as a parameter which will be executed when the body is finished loading in the browser.  It is very similar to jQuery's $(document).ready() method except that it is called when a document fragment is loaded by AJAX as well as when the document is initially loaded in the browser.  Notice that the callback function that is passed to registerXatafaceDecorator takes a single "node" parameter.  This represents the root node of the document fragment that was loaded.  This allows you to target your document decoration to only include the fragment that was loaded - rather than the entire document.

On line 9, we obtain a reference to the button that we added in the before_instructions_widget block.

On Lines 10-14, we obtain references to the fields in the form that we will need for building our AJAX request.  Notice that we use the findField() function (we made a reference to this on line 6) to obtain these fields.  In this case we make references to the semester_id, job_type, and department_id fields because we may need to pass these values as part of our AJAX request to determine which instructions we want to load.  E.g. If the job posting is for the "CMPT" department, then it wouldn't make sense to load previous instructions for the MATH department.

On line 16, we attach a click handler to the import button.  This handler is what will be called when the user clicks on the button to load instructions.  These is where we build the AJAX request to load the previous instructions.

Lines 17-27 show the basic GET parameters that I plan to pass to as part of the AJAX request.  Let's take a look at these parameters and discuss what they do.

The -action parameter (line 18) shows that we intend to pass this request to the built-in Xataface action "export_json", which will return the found set as a JSON data structure.  This is a very useful action for serving AJAX requests.  In some cases you may still need to create your own custom actions to return the data that your AJAX request requires, but in most cases this built-in action should do just fine.  When using the export_json action, you can just follow standard Xataface URL conventions for specifying which records to include in the result set.  E.g. here we specify that we want to fetch records from the "job_postings" table (line 19) , we only want one record (line 20),  and the results should be sorted by semester id in descending order (line 22) -- effectively this means we want only the most recent match.

The export_json action also takes some additional parameters.   For a full list, and some documentation, you can check out the action's source itself.   In this example, we set "-mode" to "browse" (line 21) so that the instructions won't be truncated.   By default export_json uses list mode which only returns the first 255 characters of text fields.  Also, since we only need the "instructions" of the job posting, we use the "--fields" directive to declare that we only need this one field.  We could have listed multiple fields here separated by spaces.

On lines 23-25 we initialize query values for the department_id, job_type, and semester_id fields.  This is optional and only added for readability.  Passing a blank value for a query field (following Xataface URL conventions) doesn't affect the query at all.  We set these query parameters to more specific values based on the current form data on lines 29-44.

On lines 29-31, we check to see if the semester_id field is filled in.  If it is, we add a filter to the query to only return job_postings in semesters earlier than the current one.  Notice the use of the '<' less than prefix in the query value to indicate a search for semesters less than the given semester.

Lines 32-27, we check if the department id field has been filled in.  If so, we add it to the filter parameters of the query.  If not, we throw an error .

Lines 39-44 show similar handling for the job type field.

Finally Lines 46-56 show the actual AJAX request.  The response will be an array of objects, where each object contains an 'instructions' property.  The following is a screenshot from the Chrome network inspector to show what the response will look like.

In this handler we first check that the response exists and that its length is greater than 0 (line 47).   On line 48 we use the CKEDITOR api to get the CKeditor instance for the 'instructions' field.  If it can be found, we set the data using the CKeditor setData() method.

Now, if we load the form, enter the required fields, and press the button, it should load the instructions field with the data that we want.

No comments:

Post a Comment