Richard Querin wrote: > > On 4/5/06, *Alan Gauld* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Sounds like creating each app as a class which can be instantiated on > demand by the master application would be a possible design option. > > I guess writing the master program (or some simplified version of it) > would be required from the start in order to make launching the separate > design programs possible (for testing, debugging etc..).
Not really. You just have to write the separate design programs in a way that they can be integrated with a larger whole. This means, write the functional part of the program with an API that can be easily be invoked to make it do the work. The API can be class-based, as Alan suggests, or standalone functions, whichever is simpler. Then for a standalone program you can write a main() function that works from the command line or a GUI. For your master program you can invoke the API from whatever framework you come up with. > > The class approach coupled to a config XML file would do this. > Define a file that looks something like > <snip suggested XML config file> > > Then you can read that and use it to construct a menu or set of buttons > or toolbar or whatever. XML is obviously a bit controversial, you have several contrasting opinions already. I have successfully used XML and a DOM data model in several applications and I would do it again. For configuration I would look at something simpler, possibly a Python module that configures other modules or maybe a plug-in mechanism. Or possibly you just write your master program to call the subprograms as libraries without any dynamic configuration at all - just hard-code it. I should note that my experience with XML data models is from using the excellent dom4j library with Jython. I haven't found any Python XML packages available for Windows that have the same combination of power and ease-of-use as dom4j. > I think my first task will likely be settling on what I need each > component of the system to do and how they will interact. It's becoming > more complex the more I discuss it.. ;) I would say your first task is to write some code that does something useful. Then write some more and make them work together. Repeat as necessary. Don't try to figure it all out up front. > > > Obviously this won't happen right away, I would likely develop each > > small design app as a standalone and then when I've got 3 or 4 done > > I would tie them together with the project app. When you have two standalone apps then you can reasonably think about how to tie them together. Before then too soon - you don't know what the standalone apps are going to look like until you make them. After you have three is getting to be too late - when you integrate the apps you will discover things you want to change about them to make the integration easier, and that will inform the way you create the next app. Don't leave out the unit tests - when you want to change your apps for integration (or any other reason) the unit tests will give you confidence that you haven't broken anything. Also writing the apps to be testable will help make them usable from another app. Kent _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor