gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnumed-devel] Re: Gnumed-devel Digest, Vol 6, Issue 34


From: sjtan
Subject: [Gnumed-devel] Re: Gnumed-devel Digest, Vol 6, Issue 34
Date: 23 May 2003 21:58:11 +1000

> ------------------------------
> 
> Date: Fri, 23 May 2003 10:49:53 +0200
> From: Karsten Hilbert <address@hidden>
> To: gnumed <address@hidden>
> Subject: Re: [Gnumed-devel] gmEditArea
> Message-ID: <address@hidden>
> In-Reply-To: <address@hidden>
> References: <address@hidden>
> Content-Type: text/plain; charset=us-ascii
> MIME-Version: 1.0
> Precedence: list
> Message: 3
> 
> > I suppose you could do it the Delphi way, i.e. have a data aware text ,
> > combo box, check box, which connects to a field in the table. 
> > And manually go through the gmEditArea and change the instantiations of
> > the components. To save time for future changes, why not have a globally
> > accessible wxComponent Factory object(s) on the guiBroker , and use it's
> > create(TextCtrl, ComboBox, CheckBox)  method to instantiate the gui
> > components, then if you'd prefer to put in  object domain model aware
> > components instead of 2-tier data-aware components, it would be easy
> > just to substitute the factory(ies) in the guiBroker at config time.
> > 
> > 
> > Another way is to design your own java style Model View components,
> > where the model is a defined (empty) interface that allows different
> > implementations , and the textComponent has an interface which can be
> > called by the model. Then put the model implementation instantiations
> > as entries into the "Model" broker at config time. 
> 
> Well, if you DO it and document it so a dumb-founded doctor
> like me can understand and extend it, fine. And no, I don't
> need proof-of-concepts. I understand that it works in
> principle.
> 
> I'm surely open to elegant solutions but I need to see them
> put to work.
> 
> Karsten
> -- 
> GPG key ID E4071346 @ wwwkeys.pgp.net
> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
> 
actually, I'm having a hard time trying to work out how to access the 
gmclinical tables. The views and update triggers in gmIdentityViews are 
fairly straight forward, and after trying to do the handler skeletons, I
realize SQL triggers are probably the clearest way of doing things.
But after  I stared at the gmclinical tables for a few hours, trying to
write my first SQL trigger, I whimpered back to my java IDE toy.

What about starting with a dead simple mapping , then later normalizing
it by making the simple tables views with triggers?


  









reply via email to

[Prev in Thread] Current Thread [Next in Thread]