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 transparently.
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. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
