The Embedded Page Pull Apart

As a college, my employer has to put up ready made gainful employment ‘templates’ that they receive from the Department of Education for our certificate offerings. These ‘templates’, really an all-in-one web page, come with all of the CSS, Javascript, and HTML all smashed together in one file. The problem with these is that they where designed to be used on sites that serve regular static pages. The site that I manage uses a CMS. What to do? The answer is simple, pull it all apart.

As stated above, the ‘templates’ include two HTML files, one for viewing and the other for printing. They are made up of three sections; CSS, Javascript, and HTML. There was also an images folder, which I renamed to ‘gedt’, and I copied to the main images folder.

After looking through a number of these ‘templates’ that I received from my financial aid office, I discovered that 95% of these files are the same across ‘templates’. The 5% difference is about 20 lines of Javascript that defines some parameters, and the print file not having Javascript popups. This means that I can separate them into their own separate files and containers and reuse almost all of it.

The CMS that we use is Joomla, and the techniques and terms are tailored to that CMS. However, this will work with most other CMS’s as most work in a similar way.  With the disclaimer out of the way, let’s get to work.

First, I copied the HTML from both files and pasted them into their  own articles (i.e. posts in other CMS’s). You will end up with two articles, one for the viewing HTML and the other for the printing HTML. This HTML is identical for all the ‘templates’ as the actual content is located inside the ‘parameter blob’ in the Javascript that came each individual ‘template’. I changed the image paths so they pointed their new locations inside of the site’s main image folder. I made additional changes to the viewing HTML by adding ‘gedt.’ to the front of all of the Javascript calls so they will be in the correct namespace when we are done.

Other than these small changes, I left the HTML alone, as awful as it is partially do to the large amount of inline CSS. I chose to leave it there to make updating it easier as I get updated ‘templates’ in the future. You can pull this CSS out if you want to, but it would require adding class and id attributes to the HTML as these don’t exist.

Second, I copied the CSS block out of the header, and put it into its own SASS file. This allowed my to greatly compact the CSS while making it easier to maintain.  The resulting CSS file is located in the site’s default template CSS folder. I referenced it by using the Add CSS module.

There will be CSS issues once the template is viewed inside your CSS environment, unless you have lived a really pure life and you are ready for sainthood. I had to modify it so it would work better with the site’s template I am using (i.e. the theme for non-Joomla users).  I also grafted in the differences from the print HTML’s CSS under the .gedtPrint class. I will use this class later to make sure these styles are not used when viewing the regular version.

    @extend %programFont;
    .gedtPrint & {
        font-size: 17px;

Third, I copied the all of the Javascript , except for the parameters blob, and put it into it’s own file located in the site’s default template js folder. This file is reference by placing the script tag into a custom HTML module located in a site template position located after the main content. This is to make sure that the scripts load after the HTML it references does. I named the modules for the view javascript ‘Gedt Javascript Link’, and the print ‘Gedt Print Javascript’.

In my opinion, the Javascript needed some help. By default, they are in the global scope, which is OK when they are isolated on a static page. However, not so fine when being served by a CMS with many other scripts running. That scared me enough that I spent some time to bring them into their own scope.  I called the view’s javascript object view’s Gedt, while print’s object was called GedtPrint. I then published the objects to the global scope so they could be accessed by the scripts in the parameter blobs. Both the view and print Javascripts where re-formatted the same way, as shown in the example below.

(function() {
    "use strict";

    var currenGuid, dict=[];

    var Gedt = function() {


    Gedt.prototype.dict = [];

    // display information on page
    Gedt.prototype.displayTemplate = function(guid) {
    ... // code here

    Gedt.prototype.openPopUp = function(divId, enableOverflow, headerTitle) {
    ... // code here

    Gedt.prototype.clearPopUp = function() {
    ... // code here

    Gedt.prototype.closePopUp = function() {
    	... // code here

  ... // more functions here

    window.Gedt = Gedt;
    return Gedt;

Lastly, the parameters blob Javascript is put into its own custom HTML module. This blob of Javascript contains all of the information that will be displayed when a user visits the page. If only the information is updated, then I should only have to update this. You will have to have one for each ‘template’. In my case, I had to create 5.

I added to the bottom of each blob some additional scripting to help the browser invoke the correct Gedt or GedtPrint objects, and set the parameters. For my purposes, I also included a line to change the href for the print icon to point to the print menu item (more about this below). You can some of the changes in the example below.

<script> var dict = [], dictKey = '{some key value here}';
  dict[dictKey] = {};
  ... // more parameters here

  // to change the print link.
  // Sniff out if we are going to use the regular or print javascript.
  if(typeof Gedt !== 'undefined') {
    gedt = new Gedt();
  } else if (typeof GedtPrint !== 'undefined') {
    gedt = new GedtPrint();
  gedt.dict = dict; // pass the parameters to gedt.
  gedt.displayTemplate(dictKey); // render the parameters

After all the pieces have been broken out into their own separate files and locations, it is now time to tie it all back together. We are going to do this by using  the magic of menus and module assignments. If you are using Joomla, having Regular Labs’ Advanced Module Manager will make this task a lot easier.

Create a hidden menu, if you don’t have one already. I won’t go into much about what they are here, other than they help create links for menu items that you don’t want displayed anywhere. If you don’t know what they are, I suggest you read the article that I have linked to.

Inside the hidden menu, create a menu structure that looks something similar to this:

  • Gainful Employment
    • Certificate 1 Gainful Employment
      • Certificate 1 Gainful Employment Print
    • Certificate 2 Gainful Employment
      • Certificate 2 Gainful Employment Print

All the menu items above are single article menu types, except for the first one, which is a menu heading. The Certificate {n} Gainful Employment menu items link to the view HTML article, and the Print items link to the print HTML article. You can name them what ever fits your organization. Just remember that what ever you name them, is what will show up as the browser title for the page.

With the print menu items, assign it a page class of ‘gedtPrint’. This class will be automatically inserted into the article tag surrounding the print HTML so we can use our print specific CSS.

After the menus are created, it is time to link the appropriate modules to the menus. The CSS gets assigned to each menu item. The regular Gedt javascript is assigned to the  Certificate {n} Gainful Employment menu items, while the print Gedt javascript is assigned to the print items. As for the parameters blobs, they are linked to both the Certificate {n} Gainful Employment menu and it’s associated print menu that they belong to.

I hope this helps somebody dealing with the Gainful Employment templates and trying to get them to work with your CMS. It requires a little work, but the results make the code a lot more manageable.