Patric, > How do you go about setting up a new application?
Thats a great question, and I hope we get a few responses. > For example, suppose I need a script that will collect order information > for a set of items ona page. Its output will go to a mail program so the > artist can be notified. I would start by abstracting the problem as much as possible and identifying the classes/objects (I think in OOP by default for anything non trivial) In this case I see an order and and order item (or possibly several) Because I try to separate UI from application as much as possible I'd start with these and build the two objects in a module and test them using the >>> prompt. Order depends on order items so I'd build item first. Then I'd test it - can I create an item? Can I print an item? Because this is targetted at the web I might right a dedicated str/repr method to grenerate an XML representation... Then I'd build the orderand test it. Can I add items to it? etc. Then I'd think about how to extend the order items. I don't want to use subclassing since that means custom code for every new product we sell, better to use a dictionary of attributes I think... Lets try that out, back to item again... OK, It all works from the >>> prompt lets think about the UI. (Here I confess that I do very little web programming) I need to - present the items for selection/browsing - offer the opportunity to create an order(add to basket) - present an order summary - capture customer details - allow confirmation of the order - process the order This points out that I also need a customer object! Back to the application construction..... OK I now have a customer object, back to the UI. I'll build the UI in generic terms using the bullets above as hook functions - so I can change behaviour easily later. Thus calling Order.process(customer) will initially generate an email, but later I may subclass order to provide a direct link to the suppliers via a B2B gateway or Web Service... I'll have to think about the order process at this point and join the bits up in the right order. Back to the >>> prompt for some experimenting. Now I design the HTML and set up my web server environment. I write my CGI handling parts to call the application objects as required. It all works, but nothing is persisted. Build a persistence mechanism, how many orders? Maybe store the data in XML files somewhere for a few orders? Or go for growth and build a full database and write persistence methods to match. I think I'm ready for accepance testing now. In terms of modules, I'll probably put the order, item, and customer in separate modules. I'll put the UI stuff in a single module. The database bits will probably go along with the objects themselves. If its for production use rather than a prototype I'd document the class structure, the order processing sequence and the database schema and persistence mechanism. I'd also document the file structure on the web server. The rest of the documentation I'd leave as comments and docstrings since its a very small application. In total I'd expect a design document of 5-7 pages or so. Alan G. _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
