[bt-devel] The design of the BackEnd

[Torsten Uhlmann]

----- Original Message ----- 
From: Joachim Ansorg <Jockel123@gmx.de>
To: <bt-devel@crosswire.org>
Sent: Monday, January 17, 2000 7:44 PM
Subject: Re: [bt-devel] The design of the BackEnd


> Hi!
> Hope I undestood noe the most of your ideas.
> 
> >> Is HTML a text converted to HTML or an external HTML text?
> >> If it's a converted one we should use the different presenters (bible presenter,
> >> commentary presenter and lexikon presenter).
> >
> >An internal text stream. I don't want the GUI to see where the data comes from 
> >nor to know how to retrieve it. I also thought it might good the differ between
> >normal text, bible, comment and dict but couldn' think of a real need for this.
> >But maybe it will come later. Anyway I will give you information about what type of
> >module text you get. You can now display everything in one presenter and make later
> >sub classes that you can specialy use.
> 
> Let me see if I undestood it: You send a HTML text to a module presenter (type
> is here not important) and with it information about the type.
> Each presenter get's only HTML and should work with the HTML text.
> Right?

Each HTML presenter. In the future we might see need to create presenters for other types of data (interactive maps...)
Basically you will get a QString, either as return code of a function (if you want to call the CModuleInfo
directly) or as a SIGNAL (if you call the slot from CBackEnd). The QString will contain the formatted Info the
presenter needs to display. So the CFrontEndContainer will call for instance the slotGetText(Module,Key) and
will receive the text via a SIGNAL/SLOT. It then will look to which presenter is active
and call Presenter::setText() (for instance; the names are not real but you see what I mean).

> 
> But one problem I see is that e.g. a dictionary presenter needs special things
> like a list of the dictionary entries? How could we realize this?

The CModuleInfo will provide a function that will return all valid keys for that module. 
(Hope I'm able to do this with SWORD) But thats the way it will work.

> 
> >Speaking of class structure. I would like you to create a Container class that handles requests
> >to and from the backend (for instance) and gives information to it's registered widgets (presenters,
> >list view, etc.) and not to register each window. That way we can keep the data flow between
> >backend and frontend clean and easier to change.
> 
> ???
> 
> First you wrote we should register each widget and later "and not to register
> each window.".

Register each presenter to the CFrontEndContainer and NOT to the CBackEnd. But connect the 
CFrontEndContainer with CBackEnd. See also next answer on Thomas' question.

> 
> I think something is confusing here the last time.
> 
> -- Joachim
> BibleTime - the bible study program for KDE
> http://www.bibletime.de/
> info@bibletime.de