Directions

In the transition to Freemarker, we worked to remove business logic from the display layer. Now it seems that we have mingled display logic into the business layer.

In several examples, we have created functions in the Java or Freemarker code that are specific to the pages we want to create, instead of enabling the creation of pages in general.

We need to provide a suite of general-purpose classes and methods, making it easy for a theme designer to realize their vision.

New data objects

Data objects and TemplateModels

Currently, the data passed to the templates is in a collection of objects that are also Freemarker TemplateModels.

It would be good to use POJO data objects that are not tied to Freemarker, but which are coded according to convention, so one of the standard TemplateModel will wrap them neatly. Or perhaps, POJO data object and a single custom TemplateModel written to work with them.

Data objects and Controllers

Currently, the data objects contain a lot of methods that are used to populate them. It would be better if the data objects were just collections of data and means of extracting the data. Leave the populating code in the controllers

Data Hierarchy

• Individual
  
  • Property Group
    
    • Property
      • Subclass (only if collated)
        
        • PropertyStatement

Is the Subclass actually a layer in the hierarchy? Or is it only a display function of how the Property Statements are shown?

Currently, each layer has a method that gets the list of items beneath it, but each item should also list its parent, so we can travel up or down the list. So for example, a template might choose not to break the properties into groups, but rather to display all properties alphabetically, with each property stating the name of its property group.

Variations from Vitro to VIVO

The current method of using BaseIndividualTemplateModel with an empty extender (IndividualTemplateModel) is bogus. How can we get around it?

Skip or revise the DAO layer?

Can we populate the Individual from a single SPARQL query against the RDFService Dataset? Would that improve performance over the current model-based method of populating?

Unified customization techniques

A custom list view is a SPARQL query (or more than one) and a Freemarker template. A Short view is a DataGetter and a Freemarker template. Custom Individual pages per class are special Freemarker templates. Can't we combine some of these techniques?

This seems like something that the Application Ontology should handle:

• In this situation (the profile for an Individual of this type)
• We should execute these (0 or more) DataGetters
• We should display using this (exactly 1) Freemarker template.

How can we express the "situation"s in a way that covers all three techniques, and provides more general options as well?

One approach to the Application Ontology

A Freemarker directive that allows you to provide:

• Situation name
• Additional info

And to determine whether there is an applicable custom setting. If so, then use it.

<#assign display = customDisplay("PropertyGroup", group.getName(), individual.getMostSpecificClasses()) />
<#if display??>
    ${showCustomDisplay(display}
<#else>
    ... do the standard display here
</#if>

Display logic in the display layer

Currently, the controller and the data objects include a lot of the display logic.

It could be argued that the controller and the data objects are part of the display layer, but I don't believe that holds up. We permit multiple themes in a VIVO, but not multiple sets of controllers. If we want people to contribute their own themes, they need to be self-contained.

As a practical matter, different skills are required to edit and compile Java code, versus Freemarker templates or JavaScript scripts.

For example, if a property is annotated as "collated", then Freemarker receives a CollatedObjectPropertyTemplateModel instead of an UncollatedObjectPropertyTemplateModel. This means that the template writer does not get to decide how to display the data.

Similarly, if a page is editable, Freemarker is given a list of all possible properties for that individual. If not editable, Freemarker is given only a list of populated properties. What if the theme author would like to show unpopulated properties even on a non-editable page? We need to give the data to the template, and let the template author make the decisions.

In general, rather than the controller deciding to pack a data structure in a certain way, the data structure should be fully packed and as uniform as possible across all settings. The data object may include convenience methods such as getProperties() and getPopulatedProperties(), but the display decisions should be made in the display layer.

Themes should override the core

Currently, a Freemarker template in a theme will override one of the same name in the core code. However, the same behavior does not exist for CSS, JavaScript or image files.

If these files are in the theme, they lie in a different URL space than those in the core. So there is no override. Instead the template must be modified to reference the custom image or CSS file.

<!-- an image file -->
<img src="${urls.theme}/images/arrow-green.gif"/>
 
<!-- a CSS file -->
<link rel="stylesheet" href="${urls.theme}/css/screen.css" />
 
<!-- a JavaScript file (create a js directory in your theme) -->
<script type="text/javascript" src="${urls.theme}/js/my.js"></script>

<!-- an image file -->
<img src="${urls.base}/images/arrowIcon.gif"/>
 
<!-- a CSS file -->
<link rel="stylesheet" href="${urls.base}/css/login.css" />
 
<!-- a JavaScript file -->
<script type="text/javascript" src="${urls.base}/js/browserUtils.js"></script>

These namespaces should be merged and simplified so no prefix is needed, and so true overriding is possible

<!-- an image file -->
<img src="/images/arrowIcon.gif"/>
 
<!-- a CSS file -->
<link rel="stylesheet" href="/css/login.css" />
 
<!-- a JavaScript file -->
<script type="text/javascript" src="/js/browserUtils.js"></script>

In each case, this code would look for the requested file in the theme, and if it doesn't find it there, look in the core area.

Improvements to the theme

In general, the thought is to simply the code in the templates and the controllers, without changing the functionality at all. Perhaps there is work to be done on the wilma theme, but that would not be directly related to this effort.