Book is the most basic store of textual data - It can retrieve data either as an XML document or as plain text - It uses Keys to refer to parts of itself, and can search for words (returning Keys).
The BibleDriver class allows creation of new Books.
A method of filtering Books.
There are several lists of Books, the most important being the installed Books, however there may be others like the available books or books from a specific driver.
A Bookmark remembers a particular view of one or more Books.
A BookMetaData represents a method of translating the Bible.
A BookProvider provides a list of books.
BiblesListeners are able to be notified about changes to the numbers of Bibles installed on the system.
A ReferenceSystem is a marker interface.
An object implementing this interface is able to unaccent the texts.
A basic implementation of BookList.
Provides different ways to sort Books.
BookData is the assembler of the OSIS that is returned by the filters.
An iterator that filters as it goes.
Some common implementations of BookFilter.
Filter for all books
Filter for books by category
Filter for books by feature
A helper class
Filter for books by category
A Factory class for Bookmarks.
The Books class (along with Book) is the central point of contact between the rest of the world and this set of packages.
BookSet represents a collection of descriptions about Books which may be subsetted into other BookMetaDataSets.
GroupFilter does the SQL traditional group by.
A BooksEvent is fired whenever a Bible is added or removed from the system.
When we can't convert some source data then the user doesn't really care and just wants it to work, but it would be good to have some way to get the problems fixed, so as a start point we report them through this class.
Defines a single default book.
Handles the current default Books.
To keep us up to date with changes in the available Books
Some simple utilities to help working with OSIS classes.
A generic way of creating empty Elements of various types
The SentenceUtil class provide utility functions for the various Books.
An Enumeration of the possible types of Book.
Types of Sentence Case.
An Enumeration of the possible Features a Book may have.
Types of Key that a Book uses, either verse, list, or tree.
A MetaDataLocator allows one to define where BookMetaData for a Book may be found.
Something went wrong with a Book.
Bookinterface. An implementation of
Bookis expected to be able to retrieve Biblical text for a given
Passage, and to return a
Passageof verses that contain a word.
A Bible is a specialization of a Book that uses Passages as basic data types.
The following is out of date since the Version -> Book/Bible split
There are several specializations of the
Book that can be changed
either to accommodate Verse based notes or for a normal
that can be created at run-time. The latter option allows this system to
be installed on a computer that already has OLB installed without
requiring a download of the complete Bible source, but the source is
created either as part of the install or on the fly, and cached here.
Translation is a
understands Strong's numbering and can give information about how words are
translated to and from the original.
Currently there are 2 basic implementations of the
interface - an
ODBCBook and a
former acts on an Access database via JBDC and ODBC. The latter on an
experimental serialized data store. Probably neither of these
implementations are of any long term use, however they do help get me up
to speed quickly.
I envisage at least 2 more production stores - an
OLBBook that reads directly from OLB files exactly as
installed on Windows. (Maybe in reality there needs to be an
OLB7Book and an
OLB8Book or something)
RemoteBook that uses RMI / CORBA / HTTP or whatever
to retrieve the data from a remote server)
It is important that multiple data sources are available, to allow a compact download time. In an ideal world the base download, would be small enough to place as an applet on a web page, with some kind of "Save as application functionality" that still uses a remote data server. A caching Book could then store verses locally, only using the network for verses not retrieved yet.
The Biblical text is returned to the application as an XML document.
Books to contain data like red-letter markup
that a display module may not want to use. See the display section for
More work is needed here to with Strong's numbers and non-Biblical text sources. (Lexicons and such like)
The startup procedure goes like this. When
Books is first called
it looks up the implementations of BookDriver (using Project.resource()) and
calls registerDriver() for each. This calls getBooks() on the new BookDriver
which should return an array of BookMetaData objects.
Ideally when the BookDriver creates a BookMetaData object it should also create a Book to go with it, and do everything it can to ensure that future reads from the Book will be Exception free, but without consuming significant system resources. So the process of constructing a BookMetaData and associated Book should check that the index file exists and is readable, but not actually load it. BookDriver is allowed to complain that it can't do everything it wants, but it should not hand BookMetaData objects back that are faulty.
This means that the user can browse through the BookMetaData objects without causing any stress to the system, and yet be fairly assured that when they do call getBook() on the BookMetaData that everything will work fine.
Finally when BookMetaData.getBook() is called, it should ask the Book to load any system resources that are needed to fulfill the requests.
We used to have a CacheingBookDriver (now deleted) that was designed to allow data to be cached as it is read. Maybe at some stage we should add it back in again, but we would need to make Drivers writable before we do that.
The designed features of CacheingBookDriver are:
So it is up to the actual caching scheme to distinguish cached data from other normal data, and to be able to return a original source URL in case not all of the data is present.