[Tutor] Method/subclass

[Bill Kranec]

This article might also be helpful, as it is a little more concrete: 
http://www.devx.com/dbzone/Article/22093.  I found it by Googling for 
'python database access object'.  Is this the kind of thing that you are 
referring to, Kent?

HTH,

Bill

Liam Clarke wrote:

>Kia ora, 
>
>  
>
>>I'm not really sure what you are trying to do, the code is pretty sketchy. It looks like you want to
>>have a bunch of queries on your dataset, and the result of each query is displayed in a window. Is
>>that right? Assuming it is, I'll continue...
>>    
>>
>
>
>What I'm doing here is very sketchy, both in my mind and code. So
>yeah, my apologies, I probably should have put more effort into the
>question. ESR would flame me for sure.
>
>  
>
>>First, DO NOT put any references to your GUI classes into your data access classes!! NEVER ever do that!
>>    
>>
>
>Point noted. That was me trying to grasp the concept of returning
>objects, and then I thought I could be clever....
>
>  
>
>>I would probably have
>>- a data access class (DAO)
>>- probably some data container classes (domain objects). Your data access class >methods will take domain objects as parameters and return them as results. The different >parts of the app will communicate by passing domain objects around. If the domain data >is very simple you might just use
>>Python lists and dictionaries.
>>- a class for the main window
>>- classes for the display windows - a separate class for each kind of display. If all the >displays are similar you might reuse a single class; if they are very different they will have >their own classes. If there is shared behaviour you might have a common base class, >otherwise inherit directly from the GUI classes.
>>- possibly one or more controller classes - the classes that provide the glue between the >gui and the data. Some of this logic will be in the main window, some you might want to >put in its own class.
>>
>>A sample data flow might be
>>- user enters a query into the main window and clicks a 'search' button
>>- the search button handler is invoked. This might be a method of the main window class, >or it might delegate to a helper class.
>>- in either case, the handler class must have a reference to the data access class. It >forwards the request to the DAO, gets the results back, and creates the new window to >display the results. (The result object might be passed directly to the window class in its >constructor or by a helper method.)
>>    
>>
>
>
>Thank you for that Kent, your shouting has been heeded, and it makes
>perfect sense not to return GUI objects. Of course, hindsight is great
>like that, the answer to the cryptic crossword clue is obvious once
>you know the answer.
>
> I'm not sure I understand your response fully, so I've described how
>I would do this in accordance with my understandinf of the method
>described above. Any feedback/corrections are gratefully welcomed.
>
>But first, a wee bit of explanation. As I said, this is very sketchy.
>I've run into the issue of not knowing where to start. This is my
>first database type project, so I want
> to go about this the right way from the get go, which means my
>progress is quite hesitant/non-existent. Ultimately I want to follow
>good methods of coding as much as I can, as I dream of actually being
>able to make a living out of this at some stage.
>
> So, as I don't actually know how to do this, on account of never
>having done similar, I need to layout in my mind what I'm going to do,
>before I do it. I had a look at UML, but it doesn't look helpful .
>Perhaps it's a way of thinking that I need to learn that'll make UML
>useful.
>
>So, looking at your dataflow above Kent, I'm planning - 
>
>my main GUI runs, and upon initialisation creates self.DAO a data access object.
>
>The handlers in the main and each child window, submit requests by
>calling an appropriate method of self.DAO (or self.parent.DAO) as the
>case may be, passing any needed data as a dictionary/list, as it's not
>going to be overly complicated.
>
>The DAO then creates an SQL request as necessary, and creates a
>dictionary/list out of any retrieved data, and returns it to the
>handler. (Or an acknowledgement if data was entered, or similar.)
>
>If a new window needs to be opened (in response to a query or
>requested table) then the handler then instantiates a new child window
>using the dictionary after it's been appropriately twiddled. (As a lot
>of handlers are going to be doing this, perhaps a function of  my
>parent window can hold a method for the twiddling.)
>
>Is this going to violate any best practise type methodologies? Sheesh,
>I get so confused.
>I've spent all this time trying to keep 'logic and gui' separate, with
>the result that I stuck my gui related logic in daft places.
>
>I dunno, I was thinking perhaps do this one in Java, so I'm forced to
>learn how to use objects (particularly passing them around) properly.
>The temptation to use many, many, functions is there. I've never
>(consciously) used objects as arguments and returned values,
>aside from what 3rd party packages have required. To put it a better
>way, I've never written code where two objects I've written have
>passed an object that I've also written between them.
>
>Of course, then I'd have to rewrite this in Python once done as Swing
>is yuck, and I don't like waiting for five minutes for the JRE to kick
>in. Actually, I don't like Java at all.
>
>If anyone has any links to recommended OO best practises, I'd be grateful. 
>I googled DAO, & domain objects, and found a lot of confusing stuff.
>
>Of course, it would probably help if I didn't have cold as well.
>
>Thanks in advance for any advice offered.
>
>
>Regards, 
>
>Liam Clarke
>
>
>  
>