Find out if data in a dialog-window was modified by the user

[c.b...@posteo.jp]

I think about if there is a pattern or another intelligent solution for
that problem.

I load an existing and still persistent row/object from a database and
display this data in a editable dialog-window to the user.

When closing the window I want to know if the user modfied the data in
that dialog. e.g. I should write that modifications back to the
database instance and store it.

I could simply check each attribut from the window with the database.
Or I could add event-handlers to each component of the window that will
set a isModified-flag or something like that. But this doesn't sounds
intelligent to me.

Maybe wxPhoenix offer a half-generalizing solution to implement
something like that? Maybe register gui-components to a
is-modified-messaging-system?
--
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1

mQENBFQIluABCACfPwAhRAwFD3NXgv5CtVUGSiqdfJGVViVBqaKd+14E0pASA0MU
G0Ewj7O7cGy/ZIoiZ0+lIEZmzJKHfuGwYhXjR/PhnUDrQIHLBvh9WuD6JQuULXfH
kXtVm/i9wm76QAcvr2pwYgNzhcJntUHl2GcgnInYbZDeVmg+p9yIPJjuq73/lRS3
0/McgNoFOBhKK/S6STQuFyjr9OyJyYd1shoM3hmy+kg0HYm6OgQBJNg92WV9jwGe
GzlipvEp2jpLwVsTxYir2oOPhfd9D1fC9F/l/3gXbfjd5GIIVrZFq2haZmoVeJ33
LJxo3RA5Tf9LoUeels1b4s9kFz6h7+AHERUpABEBAAG0IUNocmlzdGlhbiBCdWh0
eiA8YnVodHpAcG9zdGVvLmRlPokBPgQTAQIAKAUCVAiW4AIbAwUJAeEzgAYLCQgH
AwIGFQgCCQoLBBYCAwECHgECF4AACgkQZLsXsAdRqOxNUAf/V/hDA5zGDpySuCEj
DhjiVRK74J9Wd8gfH0WAf1Co5HZ24wZH8rgOIVIgXw8rWkOw/VA6xfdfT+64xjTY
Fhkpbrk199nDzp72F7Jc4NC+x8xac2e3rK5ifSWhZx7L5A32pGYE+d16m3EEqImK
D4gcZl38x9zdUnD4hHyXkIPz1uCfuMuGgWEnaUk4Wbj41CBZr3O0ABue6regV15U
jaes8r+B8iCcY+0yP2kse+3iaCaMqNv5FgQZ9+b2Cql8pFkZJVtBVUw4GW3DWZJi
du0O/YrC9TgS+xY9ht/MD2qSHwjcK1sdImjqBO7xP8TIOwKeYyDvGKnSO3EJ/sSA
UPGEPrkBDQRUCJbgAQgA0k/Qg67CCUJE2/zuxBEoK4wLJpDRJzh8CQPZpjWx8VP0
KL892jwfxymXn8KNhuy1SgCBFSeV9jg4VZNWDlUGJc2lo82ajr9PzIsrQwu4lf0B
zrUWV5hWepKu/kb8uSjx58YYfx0SFz4+9akX3Wwu9TUHntzL5Gk3Q26nnsr1xEJ+
VEumvCH9AE0Tk0K7dQpJ2/JcLuO+uhrpd/lHFDYVN5NsG3P015uFOkDI6N/xNFCj
v95XNR93QlfKpK3qWlFGescfG+o/7Ub6s67/i/JoNbw0XgPEHmQfXpD7IHO4cu+p
+ETb11cz+1mmi96cy98ID+uTiToJ8G//yD9rmtyxoQARAQABiQElBBgBAgAPBQJU
CJbgAhsMBQkB4TOAAAoJEGS7F7AHUajs6sQH/iKs6sPc0vkRJLfbwrijZeecwCWF
blo/jzIQ8jPykAj9SLjV20Xwqg3XcJyko8ZU6/zuRJq9xjlv9pZr/oVudQAt6v+h
2Cf4rKEjmau483wjMV2xjTXQhZi9+ttDbia4fgdmGtKsOicn5ae2fFXcXNPu3RiW
sZKifWdokA6xqMW6iIG9YjjI5ShxngHWp2xfPscBFMDRtFOMags/Yx+YvwoyEZ4A
dURYMFHFqpwILEc8hIzhRg1gq40AHbOaEdczS1Rr3T7/gS6eBs4u6HuY5g2Bierm
lLjpspFPjMXwJAa/XLOBjMF2vsHPrZNcouNKkumQ36yq/Pm6DFXAseQDxOk=
=PGP9
-----END PGP PUBLIC KEY BLOCK-----

[Steve (Gadget) Barnes]

On 03/11/2015 03:32, c.b...@posteo.jp wrote:
> I think about if there is a pattern or another intelligent solution for
> that problem.
>
> I load an existing and still persistent row/object from a database and
> display this data in a editable dialog-window to the user.
>
> When closing the window I want to know if the user modfied the data in
> that dialog. e.g. I should write that modifications back to the
> database instance and store it.
>
> I could simply check each attribut from the window with the database.
> Or I could add event-handlers to each component of the window that will
> set a isModified-flag or something like that. But this doesn't sounds
> intelligent to me.
>
> Maybe wxPhoenix offer a half-generalizing solution to implement
> something like that? Maybe register gui-components to a
> is-modified-messaging-system?
>

The obvious problem with an is modified flag set by an event handler is
when the operator changes a value and then, rather than pressing cancel
changes it back to the old value presses OK. Personally, I find that
having your dialogue take a record of the structure that you are
interested in as an initialiser to populate the fields and return the
field values in the same structure simplifies thins enormously.

You can then follow a pattern of:

(result, new_record) = prompt_user(old_record)
# Check if they pressed OK & made changes
if result == wx.OK and new_record != old_record:

If you would like to get really cleaver you create your dialogue with
field names, types & validators derived from your database field structures.

--
Steve (Gadget) Barnes
Any opinions in this message are my personal opinions and do not reflect
those of my employer.

[Tim Roberts]

c.b...@posteo.jp wrote:
> I could simply check each attribut from the window with the database.
> Or I could add event-handlers to each component of the window that will
> set a isModified-flag or something like that. But this doesn't sounds
> intelligent to me.

There's no magic here. Either you assume everything was modified and
rewrite the row every time, or you track the "modified" state of each
control.

> Maybe wxPhoenix offer a half-generalizing solution to implement
> something like that? Maybe register gui-components to a
> is-modified-messaging-system?

How is that different from the mechanism you didn't like?

--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.

[c.b...@posteo.jp]

On 2015-11-03 09:52 Tim Roberts <ti...@probo.com> wrote:

> c.b...@posteo.jp wrote:
> > Maybe wxPhoenix offer a half-generalizing solution to implement
> > something like that? Maybe register gui-components to a
> > is-modified-messaging-system?
>
> How is that different from the mechanism you didn't like?

It would be re-usable. I don't want to code that for each dialog again.
And I wonder if there isn't such a solution currently because I am not
the first person with that "problem".

[Karsten Hilbert]

> > c.b...@posteo.jp wrote:
> > > Maybe wxPhoenix offer a half-generalizing solution to implement
> > > something like that? Maybe register gui-components to a
> > > is-modified-messaging-system?
> >
> > How is that different from the mechanism you didn't like?
>
> It would be re-usable. I don't want to code that for each dialog again.

Actually, it's not the job of the GUI to decide on things
that belong into middleware or business logic code (such
as whether - or in fact how - to save data).

What you do is smarten up your row class. Write a
__setitem__ method (or __setattr__, depending on whether
your row class is of the row[field] or row.field approach).
In that you compare the new value to the old value. If
they differ you set a modification flag. Then have a row.save()
method which, courtesy of the modification flag, becomes a noop
if nothing changed.

The dialog only ever returns OK or CANCEL. On OK you
update your row instance drawing on what the user
entered into the dialog. Then you call row.save() which
will or will not do anything based on whether anything
changed.

The row class is what you use for generalizing this
behaviour, not the UI class.

Karsten