Re: [Gnumed-devel] What to do with information in popups

[Karsten Hilbert]

> My inital plan would be to hold popup results in RAM until the SOAP
> itself is committed,
OK. One way to do it.

> as it makes little sense to commit the popups
> before committing the SOAP data.
But I don't understand how this could be a reason for the
above. Why would one not want to commit a fully entered
vaccination regardless of whether any other SOAP data has
been committed ?

> The other alternative
> is to have an "auto-save" timer to regularly commit the narrative so far
> to the backend, as well as when popups are saved and when the user explicit 
> requests a save.
Ah, now I understand why people don't seem to get what I am
asking. The data in the popups isn't narrative at all ! It
does not map to a cNarrative row.

> Problem is, if the don't auto-save, in what form should this
> epheremal data be? cClinItem descendants are the logical
> choice, but at present they can't exist before a backend row is
> created. In this case, can we have an cClinItem.__init__ ()
> option to create a empty "RAM-only" clinical object, then
> cClinItem.save () creates the row?
It is surely possible but IMO it creates more trouble than it
buys convenience. I would just keep the data in a dict, then
at save time use the appropriate create_*() methods to create
"empty" rows and then fill them in with any available further
detail. I would not want to get into having to worry about
having to somehow delete or invalidate rows that I eventually
decided I wouldn't need. The holding dict would certainly have
a "type" field separate from the data fields.

That is how I would do it, I suppose.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346