Difference between revisions of "User:Robinrichm"

From TNG_Wiki
Jump to navigation Jump to search
Line 99: Line 99:
 
Example 1:<br>
 
Example 1:<br>
 
Some mods show multiple downloads links, including variants that are intended for a particular purpose.  For instance, a mod might have two download links like this:
 
Some mods show multiple downloads links, including variants that are intended for a particular purpose.  For instance, a mod might have two download links like this:
<div style='background-color:#eee; width:20em; border:thin solid grey;'>[[#|best_mod_ever_v12.0.0.1]] &nbsp;&nbsp;&nbsp;&nbsp;<span style='background-color:cyan'>&nbsp;TNG12&nbsp;</span><br>
+
<div style='background-color:#eee; width:20em; border:thin solid grey;'>[[#|best_mod_ever_v12.0.0.1.zip]] &nbsp;&nbsp;&nbsp;&nbsp;<span style='background-color:cyan'>&nbsp;TNG12&nbsp;</span><br>
Version that is compatible with Ugly Mod:<br>
+
Version that is compatible with Useless Mod:<br>
[[#|best_mod_ever_v12.0.0.1-ugly]]</div>
+
[[#|best_mod_ever_v12.0.0.1-useless.zip]]</div>
If you don't have Ugly Mod, you don't care about the second link, and you may already have Best Mod Ever v12.0.0.1. But since the second link has what turns out to be a ''higher'' version "number" than the first link, the Mod Comparison Report will tell you that you don't have the latest version, when, practically speaking, you do.
+
If you don't have Useless Mod, you don't care about the second link, and you may already have Best Mod Ever v12.0.0.1. But since the second link has what turns out to be a ''higher'' version "number" than the first link (counting'-useless'), the Mod Comparison Report will tell you that you don't have the latest version, when, practically speaking, you do.
  
 
Example 2:<br>
 
Example 2:<br>
Line 115: Line 115:
 
<!-- ***End Collapsible Content*** --></div></div><!-- ***End Toggle*** -->
 
<!-- ***End Collapsible Content*** --></div></div><!-- ***End Toggle*** -->
  
=== The "Code Inspector" ===
+
=== The "Code Inspector" ===
 
'''Finding the style rule that defines the color of a particular element in a web page:'''
 
'''Finding the style rule that defines the color of a particular element in a web page:'''
  
Line 129: Line 129:
 
*  
 
*  
 
The answer is that it comes from a rule that starts on line 297 of css/modmanager.css.
 
The answer is that it comes from a rule that starts on line 297 of css/modmanager.css.
 +
 +
== TNG Search Program & Background Colors ===
 +
 +
The Admin and End-User programs that search for database objects and display search results in a "results table" are all quite similar. There are a couple of consistent different between Admin and End-User search programs, but those difference are easy to reconcile. Here are the two primary differences:
 +
 +
'''1. Template Layout'''
 +
* End user program use the template scripts top-menu.php and footer.php to generate the outermost structures of end-user pages. The headings and most navigational elements are consistent in all end-user pages (for a given template), except for the the home page.  Those headings and navigational elements are generated by TNG system functions that are called by each program.  The HTML &lt;div> element that wraps the content of each page begins in the last of those system functions, and ends in footer.php.  ''Within'' that &lt;div> element, the contents of end-user search pages match the contents of admin search pages very closely.
 +
* The outer navigation of admin pages is provided by a single admin frameset that wraps all admin pages. Just like the end-user pages, the admin pages call TNG system functions to generate their page heading and additional navigation menus.  But, as in end-user programs, there is a main content &lt;div> element. ''Within'' that &lt;div> element, the contents of admin search pages match the contents of end-user search pages very closely.
 +
* Here are side-by-side examples of an end-user search program
 +
{| class="wikitable"
 +
! End-user Branch Search !! Admin Media Search
 +
|- style="vertical-align:top;"
 +
| [[Image:tablecolors-branches-page.jpg]]
 +
| [[Image:tablecolors-media-page.jpg]]
 +
|}
 +
  
 
== document.ready function ===
 
== document.ready function ===
Line 144: Line 160:
 
Note that the so-called "document.ready" function is really defined as "$('document').ready();"
 
Note that the so-called "document.ready" function is really defined as "$('document').ready();"
  
An example document.ready that cleans up some aspects of the web page that just loaded:
+
'''Example 1''': A document.ready function that suppresses printing of the Inner menu and Tab menu in TNG pages:
 +
 
 +
First, here is a style class that I typically define to suppress printing of selected elements on a page.
 +
<syntaxhighlight lang="css" enclose="div">
 +
@media print {
 +
    .rrnoprint {display:none;} /* Styling for other things we don't want to print */
 +
}
 +
</syntaxhighlight>
 +
This style rule, which takes effect only when a web page is being printed, simply hides elements it is applied to. I typically apply this class to forms and navigation menus, which ''are'' displayed in a web browser; but this class prevents them from printing.  The effect of this class is very similar to the effect of TNG's "Format for Printing" feature, which sets a querystring parameter (tngprint=1), reloads the page, and depends on PHP to omit such structures from the HTML page altogether. The .tngprint class takes effect even when the "main" TNG page is printed. It is particularly handy in Admin pages, since they don't implement the TNG Format for Printing feature.
 +
 
 +
Here is a document.ready function that applies this class to the two navigational menus (The Tab menu and the Inner menu) that are present on most HTML pages.
 
<syntaxhighlight lang="javascript" enclose="div">
 
<syntaxhighlight lang="javascript" enclose="div">
 
$(document).ready(function() {
 
$(document).ready(function() {
    //1. Apply the "don't print on printer" class to the tab menu and innermenu
 
 
     //(In TNG pages, the Inner menu has id="adm-innermenu", but the tab menu
 
     //(In TNG pages, the Inner menu has id="adm-innermenu", but the tab menu
 
     //doesn't have an ID.  However, the tab menu is the only sibling of the
 
     //doesn't have an ID.  However, the tab menu is the only sibling of the
     //Inner menu.  That is, they form the entire content of their parent element.
+
     //Inner menu.  That is, the Tab menu and the Innermenu for the entire content
     //(Note that the class .rrnotprinter is not a TNG class; it would have to
+
    //of their parent div (which also has no ID).
     //have been defined through a mod.)
+
     //This statement finds the immediate parent of the Inner Menu, and applies
 +
     //the .rrnoprint class to it.
 
     $('#adm-innermenu').parent().addClass('rrnoprinter');
 
     $('#adm-innermenu').parent().addClass('rrnoprinter');
+
}); //End of document.ready
     //Apply the 'fieldname' class to all of the th cells in the results table.
+
</syntaxhighlight>
 +
One of the very significant things about this document.ready function is that it can apply the .rrnoprint class to the Tab Menu and the Inner menu in ''any'' TNG program, ''without touching the HTML code''.  A more traditional way to add a class to an HTML element would be through a .cfg file target location. But
 +
# Without an ID on the HTML element that contains the menus, it is difficult to find short target location search text that is unique to the desired element, and
 +
# If the HTML of the desired element were to be changed, other mods that try to modify the same HTML code would fail.
 +
Fortunately, if two (or more mods) each created a document.ready function that did the exact same thing as this one, nothing bad would happen.  The .rrnoprinter class would be applied three times, but once it has been applied to an element, additional application do nothing.
 +
 
 +
'''Example 2''' - More document.ready cleanup
 +
<syntaxhighlight lang="javascript" enclose="div">
 +
$(document).ready(function() {
 +
     //1. Apply the 'fieldname' class to all of the the cells in the results table.
 
     //Most TNG programs specify the .fieldname class and .fieldnameback class
 
     //Most TNG programs specify the .fieldname class and .fieldnameback class
 
     //in all of the heading cells in the program's results table; like this:
 
     //in all of the heading cells in the program's results table; like this:
Line 169: Line 204:
 
     // So these two statements add .fieldnameback to each table header row,
 
     // So these two statements add .fieldnameback to each table header row,
 
     // and assign .fieldname to each table header <th> cell.
 
     // and assign .fieldname to each table header <th> cell.
     // I use "child" instead of "descendant" selectors so that tables within
+
     // I use "child" instead of "descendant" selectors here so that tables  
     // the result table are not affected by these style rules.
+
     // within the result table are not affected by these style rules.
 
     $('#results>tbody>tr').addClass('fieldnameback');
 
     $('#results>tbody>tr').addClass('fieldnameback');
 
     $('#results>tbody>tr>th').addClass('fieldname');
 
     $('#results>tbody>tr>th').addClass('fieldname');
  
     //Erase an HTML element that was used to show program as the program was running
+
     //2. Erase an HTML element that was used to show program as the program was
     //and the HTML code was being generated.  I'm not really sure why I didn't
+
     //running and the HTML code was being generated.  I'm not really sure why I
     //remove the element altogether.  
+
     //didn't remove the element altogether.  
 
     $('#initialcounts').hide();
 
     $('#initialcounts').hide();
 
}); //End of (document).ready function
 
}); //End of (document).ready function
 
</syntaxhighlight>
 
</syntaxhighlight>
  
 +
=== Document.ready and striping ===
 
Here is another document.ready function that I use in my Mod Comparison Report to define
 
Here is another document.ready function that I use in my Mod Comparison Report to define
 
the same "striping" as in the Mod Manager List. It uses two Mod Manager options:
 
the same "striping" as in the Mod Manager List. It uses two Mod Manager options:
Line 223: Line 259:
 
(In the CSS nth-child selector, 'n' automaticaly counts from 0 to the end of the table, and the table row number calculated using 'n' needs to start with row 1, not row 0. Also 'n' is a syntactic element of the )
 
(In the CSS nth-child selector, 'n' automaticaly counts from 0 to the end of the table, and the table row number calculated using 'n' needs to start with row 1, not row 0. Also 'n' is a syntactic element of the )
  
images is A so-called document.ready function is triggered after a web page loads (shortly after the onload event in the <body> tag, and after the page content has been loaded into the DOM.  At that point, you can modify the web page with javascript and JQuery. That is, you can add classes to specific elements (or remove them), and you can add or remove elements from the web pageI now use the document.ready function to make HTML changes that would otherwise require a target location in the .cfg file, and that might conflict with other mods. Also, in rradmin_modcomparereport.php, I use a JQuery $(document).ready function to apply the fieldname class to all <th> cells in the results table (which is identified with id='results'). The relevant lines are 280 and 281:
+
==== Application of .databack in the code above ====
//Apply the 'fieldname' class to all of the th cells in the results table
+
When I assembled the example above, I was struck by the realizations that
$('#results th').addClass('fieldname');
+
# I was applying .databack to rows, rather than to cells, where it is normally appliedThe .databack class has border attributes that are used to apply borders to each data cell in the results table. Applying .databack to the row ''does'' apply .databack's colors to each cell in the row, but ''does not'' apply .databack's border attributes to each cell.  So where to the table cells' border attribute come from?
 +
# The PHP code above doesn't apply the .databack (or .databackalt) to the results table cells except when striping. So when there is no striping, how do the results table get their colors?
  
PHP code in lines 286-295 that adds Javascript statements to the $(document).ready function, but ony if the MM "striping" option is set. Those statements assign style classes to the table rows so that striping works. For striping every 3rd line, the PHP code generates a series of JQuery statements like this:
+
The answers to both questions is supplied by the code inspector. First, I'll show three inspections of unmodded TNG Admin program, admin_sources.php:
$('#results tbody tr:nth-child(6n+1)').addClass('databack');\n";
+
  and add a couple of TNG page screen clips to help illustrate what is going on.
$('#results tbody tr:nth-child(6n+2)').addClass('databack');\n";
+
 
$('#results tbody tr:nth-child(6n+3)').addClass('databack');\n";
+
First, a screen clip from an arbitrary TNG Admin page, with a results table.  I'll pick Sources...
$('#results tbody tr:nth-child(6n+4)').addClass('databackalt');\n";
+
Then the mod comparison report and the style inspector...
$('#results tbody tr:nth-child(6n+5)').addClass('databackalt');\n";
 
$('#results tbody tr:nth-child(6n+6)').addClass('databackalt');\n";
 
  
I'll add some notes about the PHP code in lines 286-295 and the JavaScript/JQuery code above:
+
Now the styles again
The echo statements that write the Javascript code are inside the for loop, but are not indented properly.
+
s.  Applying them to rows works only because
Because the value 3 is hard-coded in the statement $iii=$ii+3, this PHP code should give strange striping results if the "stripe after number of rows" option is not 3.  As I look at the comparison report now, when I set "stripe after..." to 5, the first block of striping is only 3 lines, but it continues in 5-row blocks.  That doesn't seem like what the code would do, but there it is.
 
This code applies the .databack class only if there is striping.  But when there is not striping, it seems to me that all rows should have the .databack class.  The screen clip above does show that I used a style rule in rradmin_modcompare.css to apply the borders that would ordinarily be applied by .databack to table cells. But I haven't found any code that applies .databack to the rows or cells.
 
The Javascript code above applies the .databack  and .databackalt styles to table rows, though native TNG code normally applies them to table cells.  Applying them to rows works only because
 
 
The rule I mentioned above, at line 65 of rradmin_modcompare.css, applies the border attributes that .databack would normally apply to cells, and  
 
The rule I mentioned above, at line 65 of rradmin_modcompare.css, applies the border attributes that .databack would normally apply to cells, and  
 
When I apply .databack to a table row:
 
When I apply .databack to a table row:

Revision as of 21:44, 16 November 2018

Robin Richmond

My Contact Form
Location: Cleveland, Ohio
Occupation: College Information Technology Instructor
Programming:

  • Learned FORTRAN in (OMG) 1970, and did my first Family Tree-related programming in Fortran in about 1976.
  • Wrote my first PC genealogy software with QuickBasic for 8-bit CP/M machines in the early 1980's. (I used essentially that same application, with static charts copied to the web, until I started using TNG in 2013!)
  • Ph.D. Dissertation dealt with MUMPS programming language (now known as M or Cache').
  • Used MS Basic family of languages (esp VB Script/ASP) in the '00's.
  • Learned PHP after I bought TNG in August, 2013.

Sites

  1. My TNG site
  2. My vanity site

My Mods

The following links use my Mod Manager Compare mod to compare my mods to the Wiki:

To find out what a mod does, you can click on the mod filename to display the .cfg file, and read the mod's description inside the .cfg file.

You can also go directly to [https://www.robinrichmond.com/family/admin_modcompareform.php the Kickoff Form for the report to request a report with other options.

Unpublished Upgrades

What can I say? It takes some time to publish an upgrade, and I don't always do it when I should. If you want to use the new version of a particular mod, let me know, and I'll prioritize that mod.

  • Add Name to PersonID v12.0.0.2 - works in TNGv12.0.1 and TNGv12.0.2
  • Admin Media Search 12.0.0.11 - changes the missing thumbnail message, and handles medialinks to Citations (which are new in TNGv12)
  • Admin Places Date 12.0.0.3 - Changes the database definition of the Creation Date timestamp so that
    • The database stores a timestamp if a value is not provided, but
    • Programs such as the Gedcom Import can provide a value that is constant for all records created in a batch.
  • Admin Thumbnails 12.0.0.4a - Small improvements, but I'm having terrible problems with the thumbnail process, both with the native code, and the code affectedby my mod.
  • Admin Users-More 12.0.0.4b - Fixed a bug that prevented the program from handling sort by the home tree in a user record.
  • Admin Branch Timestamps 12.0.0.2 - No functional changes.
    • Updated the cust_text.php search strings & author tag
    • Renamed the files installed by this mod to have the common prefix rrbranch_timestamps_
  • Cemetery Edit 12.0.0.8c - No longer automatically displays the Placename Lookup & Copy Widget for new cemeteries & Fixed a bug that prevented the Placename Lookup & Widget from setting the State or County in some cases.

Several other mods have changes that aren't fully tested.

Mods in development

Please let me know if you see something that you would like for me to prioritize.

Name Description Status
Admin Places Copy Copy certain fields from one TNG site (for example, a production site) to another (such as a development site). This is not the same as, backing up the table on one site and then loading the table on another. For instance, it lets you keep non-empty values, or only copy values that are not empty. Working fine for me; just needs a Wiki article
Place Name Format (upgrade) Upgrade to Place Normalization that
  1. Standardizes Placename formats interactively - not just in the Gedcom Converter, and
  2. Handles non-USA places.
Almost working
File Browser Browses through TNG files & folders, displaying descriptions of them based initially on the appendix.html file that is supplied with TNG releases. Working prototype
Places Topdown Search tweaks the end-user Places report to explain what "Localities" are. Working prototype
Track Relatives Uses a variant of ajx_labels.php to count all relatives (not just descendants) of a person by generation. Had a working program; I may have trouble finding it. Not implemented as a mod
Browse Branches Restricted In browsebranches.php, shows only those branches that the user has rights to. Searches for partial match in branch ID and in branch name separately. Also shows full branch membership count, not just count of records the user can see. Still only lists records the user can see. Incomplete
Snapshot Saves snapshots of database counts into two snapshot tables, to provide a historical record of the growth of the database. For now, the Gedcom Import Monitor mod takes a bit of a snapshot when a Gedcom file is imported. Barely started
Events Table Store primary built-in events into the same table as custom events to facilitate analysis. It's awkwardly challenging, for example, to write a query that looks at all burial events, especially if citations and notes are involved. I don't know yet whether this will wind up being a brand-new table for analysis only, or whether I can add built-in events to the existing events table and flag them so they are not misinterpreted as custom events. Conceptual

Wiki Templates

These are templates I use in web pages, whose names I keep forgetting:

  • V12_cust_text - Goes at the top of TNGv12 mods to remind users about the need to upgrade cust_text.php files.
  • construction - Hard to believe that I forget this one, but I keep trying to capitalize the C.
  • RobinInstallationBoilerplate - A template that I use to display standard installation instructions in three subsections under a single "Installation" section. If the mod just has a .cfg file without a subfolder or related .cfg files, I say so. Otherwise, I add a message describing the subfolder or other .cfg files. See, for example TextPlus Charts#Installation.

Wiki Pages Under Construction

  • Incorrect Living - SQL queries that look at Living flags that might not be correct
  • lots more...

TNG Technology Notes

Each section below is derived from an email message or TNG Community posting. They could become Wiki articles some day.

MM Comparison Report Notes

When a mod article has more than one download link in its right-side panel, the Mod Comparison Report can produce false negatives in its "Site1 vs Wiki" column.

Example 1:
Some mods show multiple downloads links, including variants that are intended for a particular purpose. For instance, a mod might have two download links like this:

best_mod_ever_v12.0.0.1.zip      TNG12 

Version that is compatible with Useless Mod:

best_mod_ever_v12.0.0.1-useless.zip

If you don't have Useless Mod, you don't care about the second link, and you may already have Best Mod Ever v12.0.0.1. But since the second link has what turns out to be a higher version "number" than the first link (counting'-useless'), the Mod Comparison Report will tell you that you don't have the latest version, when, practically speaking, you do.

Example 2:
If you do not have the latest version of TNG, many of the Wiki articles for your mods will have downloads for the newest TNG version, and you will find that many or most of your mods are reported as out of date. So, really, if you don't have the latest version of TNG, the Mod Comparison Report might not be useful to you.

Toggle Examples

Note that the Mod Compare Report can produce false positives in its comparison between the version number of your mod and the Wiki version number. This most frequently occurs because the sidebar in mod articles can contain multiple download links, and the Comparison Report always compares your mod's version number to the highest mod version listed in the Wiki download area.

  • Some mods have variants, such as v10.1.0.4 and v10.1.0.4cl, where the file with the cl suffix has a special purpose. If you have v10.1.0.4, which is the highest version number of interest to you, the report will say that there is a higher version number in the Wiki article.
  • If you do not have the very latest version of TNG, the Mod Compare report will be of limited use to you, because it is likely that a number of mods will have new versions that are of no interest to you.

The "Code Inspector"

Finding the style rule that defines the color of a particular element in a web page:

In the web browser, right-click on the content you want to know about, and select "Inspect" from the context menu. In this case, I wanted to know how the pink color in certain table cells was defined, so I right-clicked on one of those pink cells.

The inspector in Chrome showed me this: (Other browsers would produce similar results)
Code inspector-badcfgs.png
In this screen clip:

  • The first outlined area shows the HTML element I right-clicked on.
  • Below, in the styles section, you can see that a rule at line 65 in rradmin_modcompare.css affects all <td> elements within the element with ID='results". That's not the rule we are looking for
    • (Unfortunately, it doesn't show the path to that css file. Other components of the Code Inspector can show you the path to each component of a web page, but in this case, I already know where those file are.
  • Then, the .badcfg background color is defined in line 297 of modmanager.css.

The answer is that it comes from a rule that starts on line 297 of css/modmanager.css.

TNG Search Program & Background Colors =

The Admin and End-User programs that search for database objects and display search results in a "results table" are all quite similar. There are a couple of consistent different between Admin and End-User search programs, but those difference are easy to reconcile. Here are the two primary differences:

1. Template Layout

  • End user program use the template scripts top-menu.php and footer.php to generate the outermost structures of end-user pages. The headings and most navigational elements are consistent in all end-user pages (for a given template), except for the the home page. Those headings and navigational elements are generated by TNG system functions that are called by each program. The HTML <div> element that wraps the content of each page begins in the last of those system functions, and ends in footer.php. Within that <div> element, the contents of end-user search pages match the contents of admin search pages very closely.
  • The outer navigation of admin pages is provided by a single admin frameset that wraps all admin pages. Just like the end-user pages, the admin pages call TNG system functions to generate their page heading and additional navigation menus. But, as in end-user programs, there is a main content <div> element. Within that <div> element, the contents of admin search pages match the contents of end-user search pages very closely.
  • Here are side-by-side examples of an end-user search program
End-user Branch Search Admin Media Search
Tablecolors-branches-page.jpg Tablecolors-media-page.jpg


document.ready function =

A document.ready function is a Javascript function that handles the document "ready" event that is triggered after a page has loaded. It is useful for manipulation the HTML DOM to add and remove style attributes and style classes within HTML elements, and to add and remove HTML elements.

When a web browser finishes reading the HTML file, it triggers the "load" event for the <body> tag. At that point, the external files (images, JavaScript files, and external style sheets) have not necessarily been loaded into the browser, but the HTML code has. Still, the HTML code has not yet been compiled into the DOM.

Once the HTML code is compiled into the DOM, the browser triggers the "ready" event, which is not tied to an HTML element, but just to the document itself. As a result, the ready event handler cannot be defined in an "onready" attribute in an HTML element. Instead, it generally defined with jQuery code within a Javascript block this way:

$(document).ready(function() {
  //The body of the function goes here
});
}); //End of (document).ready function

Note that the so-called "document.ready" function is really defined as "$('document').ready();"

Example 1: A document.ready function that suppresses printing of the Inner menu and Tab menu in TNG pages:

First, here is a style class that I typically define to suppress printing of selected elements on a page.

@media print {
    .rrnoprint {display:none;} /* Styling for other things we don't want to print */
}

This style rule, which takes effect only when a web page is being printed, simply hides elements it is applied to. I typically apply this class to forms and navigation menus, which are displayed in a web browser; but this class prevents them from printing. The effect of this class is very similar to the effect of TNG's "Format for Printing" feature, which sets a querystring parameter (tngprint=1), reloads the page, and depends on PHP to omit such structures from the HTML page altogether. The .tngprint class takes effect even when the "main" TNG page is printed. It is particularly handy in Admin pages, since they don't implement the TNG Format for Printing feature.

Here is a document.ready function that applies this class to the two navigational menus (The Tab menu and the Inner menu) that are present on most HTML pages.

$(document).ready(function() {
    //(In TNG pages, the Inner menu has id="adm-innermenu", but the tab menu
    //doesn't have an ID.  However, the tab menu is the only sibling of the
    //Inner menu.  That is, the Tab menu and the Innermenu for the entire content
    //of their parent div (which also has no ID).
    //This statement finds the immediate parent of the Inner Menu, and applies
    //the .rrnoprint class to it.
    $('#adm-innermenu').parent().addClass('rrnoprinter');
}); //End of document.ready

One of the very significant things about this document.ready function is that it can apply the .rrnoprint class to the Tab Menu and the Inner menu in any TNG program, without touching the HTML code. A more traditional way to add a class to an HTML element would be through a .cfg file target location. But

  1. Without an ID on the HTML element that contains the menus, it is difficult to find short target location search text that is unique to the desired element, and
  2. If the HTML of the desired element were to be changed, other mods that try to modify the same HTML code would fail.

Fortunately, if two (or more mods) each created a document.ready function that did the exact same thing as this one, nothing bad would happen. The .rrnoprinter class would be applied three times, but once it has been applied to an element, additional application do nothing.

Example 2 - More document.ready cleanup

$(document).ready(function() {
    //1. Apply the 'fieldname' class to all of the the cells in the results table.
    //Most TNG programs specify the .fieldname class and .fieldnameback class
    //in all of the heading cells in the program's results table; like this:
    //   <tr><td class='fieldname fieldnameback'>Person Name</td>, or
    //   <tr><th class='fieldname fieldnameback'>Person Name</td>
    //In the programs that I write and install (as opposed to programs that I mod), I
    // - assign id='results' to the results table, 
    // - always use <th> elements in the table heading rows (if I want them 
    /    highlighted like column headings),
    // - put the heading rows in a <thead> element.
    // I have also learned that the class .fieldnameback can be applied to the
    // header rows; it doesn't have to be applied to each element.
    // So these two statements add .fieldnameback to each table header row,
    // and assign .fieldname to each table header <th> cell.
    // I use "child" instead of "descendant" selectors here so that tables 
    // within the result table are not affected by these style rules.
    $('#results>tbody>tr').addClass('fieldnameback');
    $('#results>tbody>tr>th').addClass('fieldname');

     //2. Erase an HTML element that was used to show program as the program was
     //running and the HTML code was being generated.  I'm not really sure why I
     //didn't remove the element altogether. 
     $('#initialcounts').hide();
}); //End of (document).ready function

Document.ready and striping

Here is another document.ready function that I use in my Mod Comparison Report to define the same "striping" as in the Mod Manager List. It uses two Mod Manager options:

  • $options['use_striping'] is a flag that tells us whether to stripe the rows.
  • $options['stripe_after'] tells us how many consecutive rows use the same color.
    (For simplification in the explanation below, I'll assume that this option value is 3.)

The colors are defined by the two TNG class "databack" and "databackalt".

<script>
$(document).ready(function() {
<?php
#Apply striping to the results table rows if the striping flag is set
if ($options['use_striping']) {
    $n = 2*$options['stripe_after'];
    #The for statement loops the 3 times, since (we assume) $options['stripe_after']=3
    #Each time through the loop, two JQuery statement are created. One JQuery statement
    #applies .databack to every sixth row in the body of the results table,
    #starting with row 1.  The second JQuery statement applies .databackalt to every
    #sixth row, starting with row 4.
    for ($i=1; $i<=$options['stripe_after']; $i++) {
        echo "$('#results tbody tr:nth-child({$n}n+{$i})').addClass('databack');\n";
        $ii=$i+$options['stripe_after'];
	echo "$('#results tbody tr:nth-child({$n}n+{$ii})').addClass('databackalt');\n";
    }
}
?>
}); //End of (document).ready function
</script>

If striping is turned on, and the striping count is 3, then this PHP code generates the following document.ready function:

<script>
$(document).ready(function() {
$('#results tbody tr:nth-child(6n+1)').addClass('databack');\n";
$('#results tbody tr:nth-child(6n+4)').addClass('databackalt');\n";
$('#results tbody tr:nth-child(6n+2)').addClass('databack');\n";
$('#results tbody tr:nth-child(6n+5)').addClass('databackalt');\n";
$('#results tbody tr:nth-child(6n+3)').addClass('databack');\n";
$('#results tbody tr:nth-child(6n+6)').addClass('databackalt');\n";
}); //End of (document).ready function
</script>

(In the CSS nth-child selector, 'n' automaticaly counts from 0 to the end of the table, and the table row number calculated using 'n' needs to start with row 1, not row 0. Also 'n' is a syntactic element of the )

Application of .databack in the code above

When I assembled the example above, I was struck by the realizations that

  1. I was applying .databack to rows, rather than to cells, where it is normally applied. The .databack class has border attributes that are used to apply borders to each data cell in the results table. Applying .databack to the row does apply .databack's colors to each cell in the row, but does not apply .databack's border attributes to each cell. So where to the table cells' border attribute come from?
  2. The PHP code above doesn't apply the .databack (or .databackalt) to the results table cells except when striping. So when there is no striping, how do the results table get their colors?

The answers to both questions is supplied by the code inspector. First, I'll show three inspections of unmodded TNG Admin program, admin_sources.php:

 and add a couple of TNG page screen clips to help illustrate what is going on.

First, a screen clip from an arbitrary TNG Admin page, with a results table. I'll pick Sources... Then the mod comparison report and the style inspector...

Now the styles again s. Applying them to rows works only because The rule I mentioned above, at line 65 of rradmin_modcompare.css, applies the border attributes that .databack would normally apply to cells, and When I apply .databack to a table row: The .databack border attribute only apply to the row, not each cell, but, best I can tell, they don't really do anything, and The .databack background color attribute does apply to every cell in the row.

==