[Tutor] A not-so-basic question...

Patric Michael patric at usa.net
Tue Jan 4 02:45:24 CET 2005


Hi Alan...

> Thats a great question, and I hope we get a few responses.

Me too!

Thank you for taking the time to reply.  

Your response is far more complex than my original example, but its very illustrative.  
Not so much in what to do, but how to think about doing it, and that was my goal.  To 
determine how others _think_ about building an app.

Very cool.  :)

Patric


> 
> > 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.
> 
> 




More information about the Tutor mailing list