|Subject:||[Gnumed-devel] another suggestion|
|Date:||Fri, 19 Nov 2004 09:35:04 +1100|
|User-agent:||Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913|
( Actually, I think I ended up using a pipe to communicate input between the gui and the console user commands ; can't remember how I did output though; maybe it was observer with a console observer and then a gui observer. Observers have a handle to the root of the model, and get notified by the model when the model changes; observers then update their particular brand of ui ). gnumed has an observer system , I think (gmDispatcher) , but noone's made a simplified console interface first, or yet.
On the other hand , it could be argued that gui interface apps and console apps shouldn't be made the same, as the first is event driven and the later blocks on input / output streams. This was apparently so in a sockets course I did, but it was based on old Windows C explicit event loops, which funnelled every event through a big switch statement, but maybe it isn't so different from the console open-socket centred main loops.
Another issue is schema versioning ; gnumed keeps changing the model based on some rational refinement that extends over many months, without much recourse to experimental knowledge gained from hooking a working application on it. I just started looking at a messaging application in java for clinical applications, and they've got an interesting versioning system : they have sql scripts of the a particular starting version which is meant to be installed first onto the database system. Then they have a component that inspects the tables and possible table fields and come up with a version number. then they loop through a list of versioning objects that have methods to drop different parts of the schema in a particular order, e.g. indexes, constraints, views, tables, and then methods to add new version tables, constraints, views , indexes ; and apply the versioning objects that have a number greater than the guessed current version number , onto the backend schema.
Off topic, another interesting hack they have is to constrain object call paths by throwing deliberate exceptions and inspecting the call stack for particular text method names, e.g. just to check an object was created through a factory objects method.
|[Prev in Thread]||Current Thread||[Next in Thread]|