[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnumed-devel] so, where are we now on data persistence
From: |
Karsten Hilbert |
Subject: |
[Gnumed-devel] so, where are we now on data persistence |
Date: |
Thu, 29 May 2003 00:01:16 +0200 |
User-agent: |
Mutt/1.3.22.1i |
All,
in order to get things moving again let me restate the
"consensus" on widget data handling as it presents itself to
me:
1) input fields validate their input in real-time if needed
2) input fields "persist" their content upon "evt_lose_focus"
in a GUI form/widget level dictionary, the purpose of this
being for easier access to the values and client crash
recovery, this is to be done in a generic way such that as
little code as possible needs to be written per UI widget,
this requires something like Syan's handlers or
PropertySupport with a better name :-)
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
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",
this may be invoked by Ian's generic save() but will IMHO
need a widget specific implementation of said save()
5) the business object (which may reside in a service server
or in the app) now persists itself to the datastore
Anything I have missed ? Any changes ? Please act now so we
can get back to implementation.
Thought: Should we store some value in a database table that
gets explicitely cleared when the app exits cleanly and thus
persists if it crashes ?
Thanks,
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
- [Gnumed-devel] so, where are we now on data persistence,
Karsten Hilbert <=