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()
-
deleteBefore_date
- This SQL string is used to control the
Delete Semantics
associated with the HealthGate Feed.
-
delete_If_N_days_old
- This compile-time parameterization is used as part of the
Delete Semantics
associated with the HealthGate Feed.
-
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.
-
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.
-
iAbstractsFetchedCount
- This counter is used to know how many Abstracts we fetched.
-
iDbInsertCount
- This counter is used to know how many
nwc Items we Inserted into the database.
-
iQrysCount
- This counter is used to know how many
nwc Items we really issued
to the HealthGate web server.
-
iRsCount
- This counter is used to know how many
nwc Items we really got.
-
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.
-
myCollctn
- There's a good chance I'm going to completely change
how/where this is done.
-
myHgQryObjs
- This container is used to hold the set of top-level metadata objects
that this translator deals with.
-
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.
-
peopleResponsible
- These are the names of who should be informed if the TBS-kgp Feed
does not execute as expected.
-
tstID
- Normally used to annotate the expected messages that are output by this
tool.
-
whichQryCatgy
- The Query Categorization string is the only argument that can be given
on the command line.
-
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.
-
getSongCollection()
-
-
getVersion()
- The usual fixed-string Version ID.
-
getXmlObjs()
- This method lets me "expose" the data structure that is used to contain
the "all" notion regarding Xml objects for this context.
-
main(String[])
- Command-line interpreter for this application.
-
setCollection(nwcCollection)
-
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[])
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
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[])
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.
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.
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.
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.
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.
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
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[])
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()
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()
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.
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.
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()
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.
getSongCollection
public static nwcCollection getSongCollection()
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.
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)
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()
setCollection
public void setCollection(nwcCollection wrtColl)