[bt-devel] The design of the BackEnd

[Torsten Uhlmann]

--=-=-=

I wrote down some info on my part, the backend and put it in CVS under
doc/Backend_Design.txt

Please review it:


--=-=-=
Content-Disposition: attachment; filename=Backend_Design.txt
Content-Description: Backend Design

# $Log: Backend_Design.txt,v $
# Revision 1.1  2000/01/15 16:07:46  tuhlmann
# Provided info on my part
# I put my part in the Roadmap
#
#
# $Revision: 1.1 $

Backend design
~~~~~~~~~~~~~~

Author:             Torsten Uhlmann
EMail:              TUhlmann@gmx.de
Date started:       15-01-2000
Date last updated:  15-01-2000

==============================================================

Purpose of this document is to provide an overview of the
planned and implemented features of the BibleTime backend and to provide a
foundation on which this can be discussed.

This document targets the new BibleTime (0.3) design.

Supplied classes important for the FrontEnd
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

There will probably be some more classes implemented but these are important
for other developers who want to use them in our FrontEnd:

CBackEnd:
---------

CBackEnd is the link between the FrontEnd and the BackEnd. It provides info
about modules, collects modules and creates objects, one for each module (see
below). It provides service and convinience functions for the FrontEnd.

On startup the GUI will ask CBackEnd about installed modules. CBackEnd will
get the info into objects and will give a QList of installed modules
(CModuleInfo) back to the one who asked.
If the GUI needs something from a module it has the pointer (from the QList)
and needs to ask the module personally. Only CModuleInfo knows how to get the
information needed.

CModuleInfo:
------------

Stores information about modules and provides methods to access data and info
about the modules (is Encrypted, aboutInfo, hasStrongnumbers and the like). If
the GUI needs a text for a key it will call a member from CModuleInfo and this
will give the data back. However I don't yet know but the returned text should
probably be sent via a Signal for greater flexibility.

However CModulInfo is just a Superclass and won't be instantiated.
So far I see the subclasses CSWORDModuleInfo and CDirectoryModuleInfo.

CSWORDModuleInfo will provide information for all SWORD module types. I might
even break this one down in CSWORDTextModuleInfo, DictionaryModuleInfo and the
like but I don't yet know. It should not matter to the GUI.

CDictionaryModuleInfo will look at a directory as a module and the files in it
will be the data that can be accessed via a key (file name). So for instance a
directory with audio sermons or maps can be shown and if the user clicks on
one the data will be presented in the right way- managed be the ModuleInfo
class.

We could also make a class like CTextModuleInfo where we can view a text file
as a module and use tools (or libraries) like grep to search through texts
(maybe sermons or other stuff).
I believe this approach allows much flexibility and takes away much knowledge
about the underlying source from the GUI which is desirable. So we are open to
quickly add new types of modules. We can later do this via plugins in a way
transparent to the GUI.

CModuleSearch:
--------------

CModuleSearch is the search super class. It will provide the means to search
through one or more modules. It could bring it's own dialog to ask teh user
for the data it needs in order to fulfill the search and a dialog to present
the search result. This way the search (which is quiet dependend on the module
type) is transparent to the GUI.

CSWORDModuleSearch is the search class for SWORD modules. On can give it a
list of modules which should be searched and it will provide a nice dialog to
present the search result.

CDirectoryModuleSearch will do this for CDirectoryModule's and
CTextModuleSearch for CTextModule's

So if the GUI wants to initialize a search it will need to call the search
class for that type of modules (probably via CBackEnd as it provides
convinience functions). The GUI has to give the search class the modules that
should be searched. Everything else will be done by the search class.

We could also provide one search dialog with all options in it and disable
those who are inappropriate for that module type. But the scheme would be the
same.

So this will be my part. If you want, please comment on it.
--=-=-=



-- 

best regards,
Torsten Uhlmann

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
TUhlmann@gmx.de
TUhlmann@debis.com

http://www.tuhlmann.purespace.de
http://www.bibletime.de
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Wise men still seek him!


--=-=-=--