[Top][All Lists]

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

Re: [Gnumed-devel] wxGlade and edit areas

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] wxGlade and edit areas
Date: Sun, 27 Nov 2005 12:50:34 +0100
User-agent: Mutt/1.5.9i

On Sun, Nov 27, 2005 at 07:01:04PM +0800, Syan Tan wrote:

> talks about trying to impose another layer of formalism on the one that 
> wxglade
> gives you already. It isn't going to make it
> easier to read and would achieve the same thing if you just let programmers
> access your business layer any which way
> they see fit , from within the skeleton code generated by wxglade.
They can if they want to. We are just suggesting a way how
to cleanly separate things thereby ensuring relayouting can
be done without affecting the business code unduly. In the
ideal case the layout can be adjusted entirely

Eg. if you want to attach business code to attributes, eg
make the __scan_btn invoke a method _scan_now() you need to
define that in wxGlade or else you have to fiddle with the
generated code any time you regenerate it. Also, the
regenerated code will not have your business code in it -
for it is generated - so you'll have to re-add it after
re-layouting. There'd be another way, of course: define the
business methods in another module which is then imported
into the generated wxGlade code. Then again, you'd have to
fiddle with that code to import your module - albeit a lot
less. The only solution where you *don't* have to fiddle
with it is to inherit from them glade classes and use
overloading to attach business methods.

This is the way Horst suggested using wxGlade. So far we've
been faring fairly well with his suggestions - he threw in
some concepts, we spelled them out and turned them into
working and maintainable code (to various degress of
success...). I'd have chosen the same way to do it.

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

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