Class nwcItem_Driver

Class nwcItem_Driver

Object
   |
   +----nwcItem_Driver

public class nwcItem_Driver
extends Object
This "Xml translator" is a stop-gap solution so that we can use .Xml data in the V3 site, paving the way for us to move to a server-side Xml engine in the V4 site even when we don't have any such capability in V3. For now, this only applies to the "Leadership BIOs", and the reason we get away with this is that the BIOs change so infrequently that we can "pay the price" of running this translator each time the .Xml source for any of the BIOs change.

This was called: "Xml_to_Asp_Driver.java" and now is "nwcItem_Driver.java".

Putting this another way... we don't really have any live .Xml mechanism in V3 - because we didn't have time to implement that - but we did move the BIOs into .Xml because this allowed us to worry about how the formatting should be done only once, giving us a way, then, to "apply the template" en masse and quickly. Moreover, this strategy wets our appetite for the process - beyond just how the technology works - so we can prepare for that aspect during the transition to V4.

 
Usage: java nwcItem_Driver [ -P | -X | -M nn | -S | -v | -V ] [whichBio]
             Translate the built-in set of nwc Items objects (in .Xml) into
             their correspoinding .html equivalents for std browsers such as IE..
             If whichBio is given ... I'm not sure
             what will happen because this is an artifcat from the past that
             I expect to change for this incarnation of this source.
  
       Options:
         -P ("ParseFile .Xml"); Parse the input data files and generate the
            corresponding .asp files (in V4, we'll also need the .Wml files).
            Variation: -p is for debugging; it only parses the 1st file.
         -X ("Xml Menu"); This asks for the In-Page Navigation menus to be 
            included in the output that is generated.
  
         -v ("Verbose"); this option and any others not described above
            are only for debugging purposes; see details herein.
            Variation: -V lets me control different output independently.
  
         -D ("Delete Semantics"); Delete all nwc Items > N days old from the 
            database.  See: deleteBefore_date and delete_If_N_days_old == 8.
            Variation: -d Fake out the N days so that all Items are deleted.
         -M nn ("Max") Passes on the int nn to override: maxCgiQueryHits.
         -S ("Summary"); A statistics Summary msg is produced specifying
            the number of articles found in each of the 'known' categories.
         -Q ("Query"); Run weekly URL-based queries; normally done with -P, too.
            Variation: -q  Requests a Full database Load; See longer description.
 
Further details of the command-line interface are TBS.

There are two aspects to the Data Model that is implemented by this translator. First, there is a built-in (for now! ddd) set of metadata objects (called "Xml_to_nwcItem" because this is based on code that was set up to do [database] queries). In this case, these Xml_to_Nwc objects simply describe the set of .Xml files that are navigated wrt a single top-level "parent" .html page. This is necessitated by of the requirement to have "in-page Navigation objects" generated as part of each BIO. To do that you need to know about all of the metadata - the complete set of BIOs - at once. Moreover, this built-in set lets you just run the translator without having to give any notion of which files are to be translated. (Of course, the down side of this is that to add a new BIO you have to add a row to this table, herein. But you have to re-run the translator in this case anyways, so a quick recompile is not, IMHO, a big deal.

Next level down, the feed manipulates nwcItem objects (which are really the ".Xml Objects" and are called "nwc Items", herein, for historical reasons) as the 'atomic' object that it gets from a parse. We know out about a sequence of these nwcItem objects because they map 1:1 with the Xml_to_Asp objects. The further mapping of this metadata to actual files is done by convention. That is, from the seed (each BIO has an "ID" or "seed") e.g. dfriedman we deduce that the input file is "myNWCs\\dfriedman.xml" and the output file is generated in "myNWCs\\dfriedman.asp" -- hard-wired, no IFs, ANDs, or BUTs. It's the KISS model, taken to the extreme. I was tempted to do the picture (.jpg file) connection this same way, but decided to make it an explicit .Xml attribute just so our hands are not tied wrt this in the future.

This collection of Xml_to_nwcItem objects is set up in the feed's constructor because it is (for now) pretty much fixed. There are 3 pieces of metadata for each one, even though only the seed is really necessary. This is primarily because I intended that the navigation menu would be "text" in which case you need the person's full name and job title as well as the seed. As long as graphics are used to do this menuing, only the seed is actually required.

For NwcItems, I'm thinking that the "seed" might be useful inside as well as being more associated with the "Qry" (which I need to think of a better name for). So I pass this thru in TBS. tttt

Note this Caveat: there is a lot of code - and especially comments - herein that are "left over" from the fact that I produced this translator by starting with the "Feed" that I implemented for the Healthgate / planetRAD project. Since this translator is a stop-gap solution anyways, it just doesn't make sense to spend the time doing anything further about this. [Except that for Nwc, this is really the NEXT next generation beyond that so it's even more important that I weed out this stuff sometime... TBS-kgp]

To be summarized (perhaps) here, later..., is the Categorization mechanism that really holds the whole thing together.

Further details of this FEEDs processing are TBD.

Version:
"Initial version: July 26, 2001."

Author:
Kevin G. Pammett, Pammett Family Enterprises.
Copyright © Kevin G. Pammett, Inc. All rights reserved.
See Also:
main(java.lang.String[]), outputAsHtml(java.lang.String), process_Xml_SongDescriptionFile(), processCgiQuery()

Variable Index

 o deleteBefore_date
This SQL string is used to control the Delete Semantics associated with the HealthGate Feed.
 o delete_If_N_days_old
This compile-time parameterization is used as part of the Delete Semantics associated with the HealthGate Feed.
 o doWeeklyQueries
This boolean is used to control whether the Queries sent to MEDLINE are for a "weekly" batch as opposed to the one-time "database load" that we do to create the TBS-kgp database from scratch.
 o errorLine
This line always appears in the "Log" file - and also in the email - that gets generated to report on the completion status each time the feed runs.
 o iAbstractsFetchedCount
This counter is used to know how many Abstracts we fetched.
 o iDbInsertCount
This counter is used to know how many nwc Items we Inserted into the database.
 o iQrysCount
This counter is used to know how many nwc Items we really issued to the HealthGate web server.
 o iRsCount
This counter is used to know how many nwc Items we really got.
 o insertDb_dateTime
All nwc Items inserted into the underlying database in any particular instance of running this feed will have exactly the same "Insert Time" in the database.
 o myCollctn
There's a good chance I'm going to completely change how/where this is done.
 o myHgQryObjs
This container is used to hold the set of top-level metadata objects that this translator deals with.
 o nwc_Publish_Root
The "nwc Publish Root" [directory] may later be an argument that can be given on the command line, but for now it's just hard-wired.
 o peopleResponsible
These are the names of who should be informed if the TBS-kgp Feed does not execute as expected.
 o tstID
Normally used to annotate the expected messages that are output by this tool.
 o whichQryCatgy
The Query Categorization string is the only argument that can be given on the command line.

Constructor Index

 o nwcItem_Driver()
The constructor for this object arranges for the object to exist, setting up the data structures that are essentially static for the lifetime of the object.

Method Index

 o getSongCollection()
 o getVersion()
The usual fixed-string Version ID.
 o getXmlObjs()
This method lets me "expose" the data structure that is used to contain the "all" notion regarding Xml objects for this context.
 o main(String[])
Command-line interpreter for this application.
 o setCollection(nwcCollection)

Variables

 o deleteBefore_date
 java.lang.String deleteBefore_date
This SQL string is used to control the Delete Semantics associated with the HealthGate Feed. Although this notion can be overridden with the '-D' command-line option, described further in Usage Instructions, there is currently no way to override the details of the Delete Semantics; you only get to say whether you want to execute them or not.

For now, the HealthGate feed does not do any sort of deletion; this mechanism is anticipated for "post Release 1".

See Also:
delete_If_N_days_old, main(java.lang.String[])
 o delete_If_N_days_old
static final int delete_If_N_days_old
This compile-time parameterization is used as part of the Delete Semantics associated with the HealthGate Feed. Although const (for now), this variable does specify the age - in Days - that a HealthGate Article is allowed to become before we automagically delete it from the database. This automagic can be overridden with the '-D' command-line option as described further in Usage Instructions.

For now, the HealthGate feed does not do any sort of deletion; this mechanism is anticipated for "post Release 1".

See Also:
main(java.lang.String[]), deleteBefore_date
 o doWeeklyQueries
static boolean doWeeklyQueries
This boolean is used to control whether the Queries sent to MEDLINE are for a "weekly" batch as opposed to the one-time "database load" that we do to create the TBS-kgp database from scratch. As such, this datum is simply used to make available the semantics that can be specified via the '-Q' command-line option as we describe further in Usage Instructions.

For the complete story on how all this works, look at the routine that does it.

See Also:
processCgiQuery(), main(java.lang.String[])
 o errorLine
static java.lang.String errorLine
This line always appears in the "Log" file - and also in the email - that gets generated to report on the completion status each time the feed runs.

 o iAbstractsFetchedCount
static int iAbstractsFetchedCount
This counter is used to know how many Abstracts we fetched. The ending value of this counter is reported in the "Summary" message at the end so that "Items returned from the HealthGate search" is qualified and easily visible.

 o iDbInsertCount
static int iDbInsertCount
This counter is used to know how many nwc Items we Inserted into the database. It is incremented only when we successfully do the Insertion but does (or DOES NOT) take into account that we may have seen this guy before (and therefore dod NOT insert a new one). The ending value of this counter is reported in the "Summary" message at the end so that "Items were added to the database" is qualified and easily visible.

 o iQrysCount
static int iQrysCount
This counter is used to know how many nwc Items we really issued to the HealthGate web server. The ending value of this counter is reported in the "Summary" message at the end so that "Items returned from the HealthGate search" is qualified and easily visible.

 o iRsCount
static int iRsCount
This counter is used to know how many nwc Items we really got. It is incremented only when we successfully get to the end of the "known sequence" of lines that contribute to a single nwc Item. The ending value of this counter is reported in the "Summary" message at the end so that "Items returned from the HealthGate search" is qualified and easily visible.

 o insertDb_dateTime
static java.lang.String insertDb_dateTime
All nwc Items inserted into the underlying database in any particular instance of running this feed will have exactly the same "Insert Time" in the database. This value is reported as the "Dataset TimeStamp" in the "Summary" message at the end so that it is easy to identify which database changes came from where/when.

See Also:
process_Xml_SongDescriptionFile(), myHgQryObjs
 o myCollctn
static nwcCollection myCollctn
There's a good chance I'm going to completely change how/where this is done. For now, this routine simply makes available the "collection" object that the translator generally works wrt. Eventually, this will all come from an .Xml file that supplies metadata for the whole collection, but now I just fill in (hard-wire) the parameters that go with the only collection that I actually have.

See Also:
main(java.lang.String[])
 o myHgQryObjs
static java.util.Vector myHgQryObjs
This container is used to hold the set of top-level metadata objects that this translator deals with. On purpose, we have no need to build-in any knowledge of how many there are or how they are constructed.

Since this is essentially a static table, the data itself is set up in the nwcItem_Driver's constructor.

See Also:
outputItems()
 o nwc_Publish_Root
static java.lang.String nwc_Publish_Root
The "nwc Publish Root" [directory] may later be an argument that can be given on the command line, but for now it's just hard-wired. I'll parameterize this later. TBS-kgp (does the rest of this make sense?) For now, look here for the only documentation we have regarding how this file gets produced and is parsed.

See Also:
myHgQryObjs, process_Xml_SongDescriptionFile()
 o peopleResponsible
static final java.lang.String peopleResponsible
These are the names of who should be informed if the TBS-kgp Feed does not execute as expected. The names appear in the email that is generated automagically; they are also written to the "Log" file.

 o tstID
static java.lang.String tstID
Normally used to annotate the expected messages that are output by this tool. This const has no inherent meaning; it just makes it easier to create code from skeletons and have it work identifiably differently without having to change code all over the place.

 o whichQryCatgy
static java.lang.String whichQryCatgy
The Query Categorization string is the only argument that can be given on the command line. For now, look here for the only documentation we have regarding how this file gets produced and is parsed.

See Also:
myHgQryObjs, process_Xml_SongDescriptionFile()

Constructors

 o nwcItem_Driver
public nwcItem_Driver()
The constructor for this object arranges for the object to exist, setting up the data structures that are essentially static for the lifetime of the object. No provision is made for anything serious to go wrong; the only real initialization done at this point is for things that cannot go wrong.

Methods

 o getSongCollection
public static nwcCollection getSongCollection()
 o getVersion
static java.lang.String getVersion()
The usual fixed-string Version ID. This is used to keep track of which source goes with which executable is delivered to operations. The log file generated by the Feed includes this version string on its "Introductory" line - when it announces that it is starting up.

 o getXmlObjs
static java.util.Vector getXmlObjs()
This method lets me "expose" the data structure that is used to contain the "all" notion regarding Xml objects for this context. It is used to "write out" the Menu Info associated with each Nwc Item.

See Also:
outputTheNwcSelectionLines(java.io.FileOutputStream,java.lang.String)
 o main
public static void main(String[] args)
Command-line interpreter for this application.
//// //// ////
//// //// //// FEED application entry point and command-line interpretation
//// //// ////
 
For details on how to invoke the FEED application please see the Usage Instructions that appear see nwcItem_Driver#myHgQryObjs at the top of this "package".

See Also:
getVersion(), process_Xml_SongDescriptionFile()
 o setCollection
public void setCollection(nwcCollection wrtColl)