[Tutor] How to effectively use a Student class with SQLite [Was Re: How to design object interactions with an SQLite db?]

[boB Stepp]

Whew, Alan!  You've given me quite a lot to mull over.  Thank you very
much for the time you've invested in your responses!!

On Thu, Aug 13, 2015 at 6:38 PM, Alan Gauld <alan.gauld at btinternet.com> wrote:
> On 13/08/15 20:18, boB Stepp wrote:
>
[...]

> Yes, that's a standard problem in any HR type application. Names suck as
> database keys. But names are how humans interact.

HR = Human Resources?

>
> The only way around it that I know is for you to assign and use
> student IDs in the code but on the UI use search screens that
> 90%+ return one student but occasionally return 2 or 3 (rarely
> many more) and the user has to figure out which one they want..

I've had this rattling around in my brain when I sent my post.

> If you have a search form you have to check for multiple responses before
> filling the form. If its true then pop up a list dialog
> to let the user pick...

It looks like I would need to query the db for all students with this
same name, and display enough additional info for each student to
enable the user to select the correct one?  And once that selection is
made I would have the student_id needed to pull info out of the db?

It looks like there may be an edge case problem that can slip through
the cracks:  As the user will be doing her own student data entry, in
the case of students with duplicate names, she might forget to enter
one (or more, if there are that many).  The program would return only
one name, suggesting no name duplication exists, and might cause the
user to start editing that student's info when she really needs to do
is create the student entry which she forgot to do so in the first
place and edit that student's data.  It seems that I would always have
to display a certain amount of student information to make it
*obvious* to the user which student she is editing.  Or is there an
easier way?

>
> But many colleges now issue student cards with a unique ID. So the problem
> may not be as hard as you think.

My wife is dealing with 7th through 9th graders, not college level.
Her school does not assign student id numbers, so I would have to have
the program generate unique ids numbers.

>> So this leads me naturally to the UI design, something I would
>> normally mostly forget about until I had my main program logic well
>> worked out.  But in this project it seems to me that program logic, db
>> and UI are all intimately intertwined.
>
>
> Hopefully not, you can create a web/desktop or CLI UI.
> The UI (or specifically the Controller in MVC terms)...

I'm guessing this stands for "Model-view-controller" as in

https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

> ...may well dictate or at least influence the API to the
> data (or Model in MVC terminology.) The display (View in MVC)
> part of the UI should typically be driven by the API rather
> than the other way round.

I may be getting bogged down in terminology here.  In this MVC design,
is the controller serving as the API between the data (model) and the
display (view)?  So is the idea here to decouple the program logic
from the (possibly complicated) UI, is to have a module (controller?)
which processes data resulting from the program logic (model) and then
decides whether this should go to the menu portion of the display, or
the part that generates a pop-up window, etc.?  And likewise
user-generated events go to the controller module and it decides which
data states get altered in the model?  And IF I am understanding this
correctly, the program logic (model) and controller need to be
designed in parallel?

>
> The other thing that can really help is to use the Use
> Case methodology. Write out the interaction dialog between
> user and system for the "happy path" scenario for a given task.
> Then analyse each step in turn for potential error cases and
> write out the use case for how you'd handle each error type.
> There is a ton of Use case material online. It's a very powerful technique
> and since its text based, there's no new tools to learn.

This is new to me, but I have always tried to think along these broad
lines in other projects I have done.  I will have to search for most
applicable materials to my current project.


>> So (Finally!) if I am understanding the important issues involved in
>> creating a viable Student class, I should be doing:
>>
>>      1)  For the current school year, at program startup, the program
>> should retrieve all current students' attributes from the db,
>> instantiate each such student object, and be able to make each
>> available in the UI.
>
>
> Maybe not. You could have a report object that displays a subset
> of student attributes without creating an object per student.
> Then only when it comes time to modify or operate on a student
> in some way do you need to instantiate the student object with
> its associated data and methods (don't forget in OOP its the
> methods that are  important, the data is the support act.)
> If you only want to view data you probably want a Report (or
> Query if you prefer - but I prefer to name objects after
> the output. The query is part of the constructor and other
> methods of the record - refresh, filter, etc) rather than
> an object per record.

Hmm.  I was thinking that I would need all the student objects
generated first and then move on to reports, etc., but this is
probably an artifact of my procedural programming background.  I guess
one can start with *any* relevant object and proceed from there based
on what needs to be *done*.

>>      2)  If a new student needs to be created by the user, then the
>> Student class would have an appropriate method which would allow for
>> data entry via the UI to both create a new student object and a new
>> student db table entry with its own unique student_id primary key.
>
>
> The UI will have a StudentView object that knows about the data needed to
> create or display Student details. It can validate input fields etc. Once
> complete the Save/OK button will send a create message to make a new
> StudentModel which saves the data into the database. That's the usual MVC
> pattern.

Would you please elaborate on what you mean by StudentView object,
StudentModel object and what you think I have meant thus far by my use
of student object?  I think I may have some large understanding gaps
here.

>>      3)  The program logic would reference each student object only
>> with the student_id primary key uniquely associated with each such
>> student object.
>
>
> The program logic of the Model class would. The users of the Model reference
> it through a Python variable like anything else. Its
> object oriented programming not database oriented programming.
> Use the objects.

Again, I am not sure I am understanding all of what you mean here.
Your first sentence is in line with what I have been thinking.  But I
am not sure of the particulars of where you are going in the second
sentence.


>> I don't want to worry about actually coding the UI at this point, but
>> it looks like while testing things as I go along, I will need to have
>> at least a text simulation of a UI,
>
>
> Yes, a basic CLI is a really useful test tool.
>
>> create an old command line-style menu system, which lists options by
>> number, input number desired, action occurs etc.?
>
>
> It could be even more basic than that. Just a set of command line options.
> argparse (or one of its friends) will do the heavy
> lifting there. An option letter for each API call and a list
> of arguments that get translated into a function call. Building
> test scripts then becomes trivial...
>
> But if you waqnt some5hing friendlier then text menus is one option.
> But rather than build a traditional menu system I'd recommend you
> take a look at the cmd module. It gives you a lot of power for
> free - its what the help() function (and pdb) all use. More to
> learn though...

I am not familiar with either the argparse or cmd modules.  To the
docs I must go!

boB