[Tutor] Method/subclass

[Liam Clarke]

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


-- 
'There is only one basic human right, and that is to do as you damn well please.
And with it comes the only basic human duty, to take the consequences.