[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] Widgets talking to business objects
From: |
Karsten Hilbert |
Subject: |
Re: [Gnumed-devel] Widgets talking to business objects |
Date: |
Wed, 28 May 2003 13:30:49 +0200 |
User-agent: |
Mutt/1.3.22.1i |
>> That makes sense, of course. What you are saying is that every
>> widget that accepts user input should have a dictionary
>> attribute self.widget_data for easy access to it's content so
>> that outsiders don't need to walk the input field tree ? And
>> Sians PropertySupport would be one way of automatically
>> pushing input field content into that dictionary ?
> Yes, but I would choose a different name.
You mean a name different from the Java lingo PropertySupport ?
I couldn't agree more ...
> No reason why the load () and save () methods can't talk to several
> business objects.
Sure. I just wanted to make sure that GUI plugins talk to
business objects (be they client, middleware or server-side)
and not directly to the persistence mechanism.
> > 2) upon *losing focus* the input field updates it's associated
> > business object's data field - whether that be achieved by
> > some clever generic mechanism similar to PropertySupport or
> > by explicitely defined associations executed in a
> > wxValidator is another matter
> This is difficult to generalise. It would mean writing a handler for
> each and every widget.
True. It would at least mean associating a business object
slot with each and every input field. The actual transfer can
be done generically, I suppose.
> Instead, they could load the dictionary, then
> we only need one handler, at the end, to talk to business object(s) and
> transfer the data.
Sounds fair.
>> 3) the business object temporarily persists state in, say,
>> temp files (this idea also comes from Sians earlier
>> postings) such that to be able to recover from client crash
> Plugins could save their dictionary easily.
Ah, I think I know what you are getting at ! You mean it's a
lot easier to just save widget state instead of business object
state because we then avoid the impedance mismatch (said
non-1:1-mapping between GUI and business objects) upon recovery
from backup files due to not having to recreate widget state
from business object state ? Surely easier technically. I
believe what Syan is currently working on in EditArea may over
time/several iterations lead to what we desire here.
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Re: [Gnumed-devel] PropertySupport, Karsten Hilbert, 2003/05/26