Building the Dijit – UI with PyYAML markup and Django Templating
Get the PyYAML file from Git Hub Repo : get it here.
This is the file that generates the Patient Pane which is brought up after searching.
This is the UI it generates:
- This Patient Pane’s UI widgets, layout etc is partly generated from the PyYAML
This pane.yaml file is a Django template that leverages Django’s templating features as well as PyYAML‘s object mark up to generate a rendered JSON. This JSON is then returned on AJAX call to help the UI building. JSON is parsed by the Javascript file here to help build the Dijit UI, Widgets etc…
PyYAML file
Let us examine the PyYAML file markup
Comments and Verbatim Code
At the top, {% verbatim %} Django Template tag allow the developer to put some code / comments
Declaring Variables
Variables that can be used all over the YAML file can be declared at the top. This is where PyYAML markup scores over Django Template. Django Template restricts variable naming and prevents you from doing Python stuff inside the template. This is ok for most templates that output HTML where the relevent code can be put inside the views.py. However, for it is also convenient if the option exists on the template. PyYAML allows us to call random python objects, declare variables that can be used through the template, use aliases in YAML file and even instantiate Python objects. Coupled with Django Template, it can be used powerfully.
# VARS
Variables can be declared with the expected type just to be sure. Aliases created can be used like Variables throughout the YAML file. Of Course we can just use {{{<some_var>}} Django template variable to do the substitution as well without creating any alias.
VARS:
clinic_id: &CLINIC_ID
!!int {{clinic_id}}
patient_id: &PATIENT_ID
!!int {{patient_id}}
URLS:
This calls the Django reverse method and allows calling with arguments. The results is stored as the PATIENT_PANE_URL alias.
pane: &PATIENT_PANE_URL
!!python/object/apply:django.core.urlresolvers.reverse
args: [ render_patient_pane_with_id ]
kwds: { kwargs : { patient_id: *PATIENT_ID } }
Using Django {%url%} template tag, the code below can be rewritten more elegantlyas:
pane: &PATIENT_PANE_URL # creates the Alias of PATIENT_PANE_URL
{% url 'render_patient_pane_with_id' *PATIENT_ID %}
YAML Header and Describing the Layout of the UI, widgets inside each DOM
YAML Header describes which module the pane belongs to, what are requisite modules to be loaded before this loads and whether this loads on AuShadha start. This is something like a basicinformation about the pane.
# YAML
depends_on: [ search ] #Requires that the Search Module
load_after: search #Requires that Search UI should be loaded before this
load_first: !!bool False #Prevents loading this first explicitly
#Following markup start the description of the Patient UI Pane
id : PATIENT #ID of the DOM Element
type : bc # Type of Dijit Layout Widget this is bc = Dijit BorderContainer
title : Patient #Title Attribute
url : *PATIENT_PANE_URL #The URL attribute which equals href of the widget
closable : !!bool True #Whether the tab is closable
widgets: [] #Whether there are child widgets (exludes layout widgets)
panes: #Describes the child layout Panes / DOM Nodes
- id: PATIENT_DETAIL_ACTIONS_ICONS #DOM Element Id of the pane
type: dom #Says that this is only a DOM Node not Dijit
domType: div #Specifies the DOM node type
style: #Specifies the CSS styles
position: relative
top: 10
zIndex: 1000
float: right
width: 200px
height: 1.8em
- id : PATIENT_TOP_CP #Describes a Dijit Layout Widget DOM Id
region: top #Region attribute of the widget
type: cp #Type of widget cp = dijit ContentPane
splitter: False #Splitter attibute
url: *PATIENT_INFO_URL #href attribute
widgets: [] #Contained non-layout widgets
panes: [] #Contained Dijit panes, DOM nodes
class: topContentPane selected #CSS class
style: #CSS styles
height: 1.8em
The resulting PyYAML file can be parsed and UI created by the Javascript file. As you can see the method is easy and the markup is certainly more readable than an HTML file with Dijit declarative markup interspersed with Django template markup etc..
It can certainly be argued about the need for a PyYAML use when HTML can be used. However, to change a layout and to see switching layout / per -user customisation it is much easier to move the YAML blocks to and fro the nested levels than to switch HTML blocks with all the declarative markups. Of course we can use Django Template {% include %} to create a basic HTML file that will do the job. It is up to developer preference. I found this much easier on the eye.
The current limitation is regarding inline javascript. This can be solved through custom Dojo Modules using AMD loader. Dojo’s dojoConfig attribute allows runtime loading. The pane’sattribute can allow import of specifically needed JS modules / classes. This is a thought. I have not implemented this fully. However, the proof of concept of this exists at the Pluggable module aushadha_demographics_us tree.yaml file.
More on that on a later post.
Next Tutorial will be based on the core of AuShadha and its bundled apps
Dr. Easwar T.R 