Re: [Gnumed-devel] so, where are we now on data persistence

[Horst Herb]

On Thu, 29 May 2003 08:01, Karsten Hilbert wrote:
> 3) the widget level dict persists itself to a temp file for
>    crash recovery, this is to be done generically, preferably
>    in the background somehow, say, in a thread; upon widget
>    creation the widget checks for existence of such a file and
>    pre-fills itself from it assuming the client crashed, this
>    needs to be rather smart or it'll be annoying

Easy. When a client starts up, it checks whether a session file exists. If it 
does, the client pops a dialog box saying: "I think the previous session has 
been terminated unexpectedly, possibly due to a system crash. Do you want me 
to restore the session ?" if the user answers "yes", it does so. If not, the 
session file is scrapped. Session files are user specific.

> 4) upon a given event (button pressed, implicit end-of-input
>    when following some pre-defined work-flow) the widget level
>    dict persists itself into appropriate business objects (I
>    wonder how this can be done generically) telling the
>    business object "I am done with this data, deal with it",

Only three events that should trigger the persistence mechanism:
1.) new patient selected
2.) client terminated
3.) deliberate "save" request from menu or hotkey

The "on_save" function should be implemented "per panel", not "per widget", 
with widgets registering themselves with their parent's on_save handler.

Horst