Overview | Package | Class | Use | Tree | Deprecated | Index | Help
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES

## Package org.crosswire.jsword.book

The Book package provides an interface to a real store of data.

See:
Description

Interface Summary
Book | 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).
BookDriver | The BibleDriver class allows creation of new Books.
BookFilter | A method of filtering Books.
BookList | 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.
Bookmark | A Bookmark remembers a particular view of one or more Books.
BookMetaData | A BookMetaData represents a method of translating the Bible.
BookProvider | A BookProvider provides a list of books.
BooksListener | BiblesListeners are able to be notified about changes to the numbers of Bibles installed on the system.
MetaDataLocator | A MetaDataLocator allows one to define where BookMetaData for a Book may be found.
ReferenceSystem | A ReferenceSystem is a marker interface.
UnAccenter | An object implementing this interface is able to unaccent the texts.

Class Summary
AbstractBookList | A basic implementation of BookList.
BookComparators | Provides different ways to sort Books.
BookData | BookData is the assembler of the OSIS that is returned by the filters.
BookFilterIterator | An iterator that filters as it goes.
BookFilters | Some common implementations of BookFilter.
BookFilters.AllBookFilter | Filter for all books
BookFilters.BookCategoryFilter | Filter for books by category
BookFilters.BookFeatureFilter | Filter for books by feature
BookFilters.CustomBookFilter | Custom Filter
BookFilters.CustomBookFilter.Test | A helper class
BookFilters.NotBookCategoryFilter | Filter for books by category
BookmarkFactory | A Factory class for Bookmarks.
Books | The Books class (along with Book) is the central point of contact between the rest of the world and this set of packages.
BookSet | BookSet represents a collection of descriptions about Books which may be subsetted into other BookMetaDataSets.
BookSet.GroupFilter | GroupFilter does the SQL traditional group by.
BooksEvent | A BooksEvent is fired whenever a Bible is added or removed from the system.
DataPolice | 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.
DefaultBook | Defines a single default book.
Defaults | Handles the current default Books.
Defaults.DefaultsBookListener | To keep us up to date with changes in the available Books
OSISUtil | Some simple utilities to help working with OSIS classes.
OSISUtil.OSISFactory | A generic way of creating empty Elements of various types
SentenceUtil | The SentenceUtil class provide utility functions for the various Books.

Enum Summary
BookCategory | An Enumeration of the possible types of Book.
CaseType | Types of Sentence Case.
FeatureType | An Enumeration of the possible Features a Book may have.
KeyType | Types of Key that a Book uses, either verse, list, or tree.

Exception Summary
BookException | Something went wrong with a Book.

## Package org.crosswire.jsword.book Description

The Book package provides an interface to a real store of data. Different sources of data interact with the rest of the code via a `Book` interface. An implementation of `Book` is expected to be able to retrieve Biblical text for a given `Passage`, and to return a `Passage` of verses that contain a word.

A Bible is a specialization of a Book that uses Passages as basic data types.

The folowing is out of date since the Version -> Book/Bible split

There are several specializations of the `Book` interface. A `MutableBook` is-a `Book` that can be changed either to accomodate Verse based notes or for a normal `Book` 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.

Secondly a `Translation` is a `Book` that understands Strongs numbering and can give information about how words are translated to and from the original.

Currently there are 2 basic implementations of the `Book` interface - an `ODBCBook` and a `FileBook`. The 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 invisage 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) and a `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 cacheing 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. Allowing `Book`s to contain data like red-letter markup that a display module may not want to use. See the display section for more details.

More work is needed here to with Strongs numbers and non-Biblical text sources. (Lexicons and such like)

### Startup

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 fulfil the requests.

### Cacheing

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:

- Ability to cache multiple (possibly remote) sources
- Use of JDBC style URL to help cached data to re-connect with source
- Can be used with multiple cacheing schemes (sword, ser, ...)

So it is up to the actual cacheing 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.

Overview | Package | Class | Use | Tree | Deprecated | Index | Help
| Copyright ¨ 2003-2015
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES