Re: [Tutor] A not-so-basic question...
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
Re: [Tutor] A not-so-basic question...
Patric,
I am a strong proponent of
- incremental development
- unit testing and test-first (or at least test-concurrent) programming
- Don't Repeat Yourself and merciless refactoring
I look for a small piece of a problem, or a simplification of the problem, and write some code. I
write unit tests for the code as I go. When I have the first bit working, I add some more. I
refactor to improve the clarity of the code and avoid duplication.
Look for a way to automate your tests. If you are writing a CGI and testing it in place with a web
browser, the testing will quickly become tedious and you will rarely test more than the last code
that you wrote. If your tests are automated and quick, you can run many tests at once. That way you
have confidence that you haven't broken anything.
In your example, automated testing may be a challenge. If I understand correctly, you are basically
getting data from a form and putting it into an email. Some suggestions:
- If there is any manipulation of the data in the middle, you can break that into functions and test
those functions separately.
- You can abstract the mailer into a generic back end. Then you can make a test version that doesn't
actually send any mail, but that lets you verify that the program asked for mail to be sent. Then
use an automated tester for web apps to drive the front end and make sure the back end is called
correctly.
- This thread on comp.lang.python about unit testing CGIs may be helpful:
http://tinyurl.com/5yr4c
It can take some work to set up a test jig but I find it usually pays off. Once you have done it
once you will have the techniques down and you can use the same techniques in similar projects.
Look for duplication in your code and don't tolerate it. Not only in a single project but between
projects. If you are writing many similar CGIs you should be building up a library of tested support
modules that you can re-use. This will make subsequent projects easier.
Whenever you are tempted to copy and paste code, look for a way to abstract the code into a function
or class so the copying is not needed.
Whenever you are tempted to copy and paste data, look for a way to centralize the data so all
clients work from the same reference.
HTH,
Kent
Patric Michael wrote:
Hi folks...
I was thinking about this the other day while prepping to write up
another CGI thing.
It occurred to me to wonder how other folks prepare an app, script,
whatever.
So the question is, and I am not looking for a right answer here. (I
doubt ther eis one, to be honest.)
How do you go about setting up a new application?
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 know that the script needs to be somewhat customizable since more
than one person will use it, and I want to look to the future where such a
script might get superceded for something like credit card orders, or
possible integration with a larger order processing scheme.
I'd start out by commenting goals in a new file, like so:
--
# Initialize variables
# Gather form data
# Output results
--
Then I'd go back through each comment and either call modules I've
prewritten, or write new defs.
Then I'd add import statements to cover the modules and the defs:
--
from datetime import now
import cgi
from mailman import send
# Initialize variables
form = cgi.FieldStorage()
# Gather form data
for each in form:
blah
blah
# Output results
result = {}
send(result)
And so on.
So the question is, how do you do it?
Is there a method you prefer? Something tried and true, or maybe
foolproof?
Just curious... And maybe a bit hopeful someone has a better way than
mine. Seems like I do an awful lot of testing... :)
Patric
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
[Tutor] A not-so-basic question...
Hi folks...
I was thinking about this the other day while prepping to write up
another CGI thing.
It occurred to me to wonder how other folks prepare an app, script,
whatever.
So the question is, and I am not looking for a right answer here. (I
doubt ther eis one, to be honest.)
How do you go about setting up a new application?
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 know that the script needs to be somewhat customizable since more
than one person will use it, and I want to look to the future where such a
script might get superceded for something like credit card orders, or
possible integration with a larger order processing scheme.
I'd start out by commenting goals in a new file, like so:
--
# Initialize variables
# Gather form data
# Output results
--
Then I'd go back through each comment and either call modules I've
prewritten, or write new defs.
Then I'd add import statements to cover the modules and the defs:
--
from datetime import now
import cgi
from mailman import send
# Initialize variables
form = cgi.FieldStorage()
# Gather form data
for each in form:
blah
blah
# Output results
result = {}
send(result)
And so on.
So the question is, how do you do it?
Is there a method you prefer? Something tried and true, or maybe
foolproof?
Just curious... And maybe a bit hopeful someone has a better way than
mine. Seems like I do an awful lot of testing... :)
Patric
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
