Re: [Tutor] How to effectively use a Student class with SQLite [Was Re: How to design object interactions with an SQLite db?]
On Fri, Aug 14, 2015 at 4:49 AM, Laura Creighton wrote: > You've found the 'variety of parents' problem. Listing the parents' > names will only let your wife know she has the correct student if she > habitually thinks of the parent names when she thinks of the student. This came to mind because currently, even with three grades in the same classroom, the total number of students tends to be small compared to traditional schools. Also, Montessori parents seem on average to be very active in their comms with the teacher. But... > I suspect her internal labelling is more likely to be along the lines > of 'the short one', 'the one who plays the cello', 'the one who used > to have difficulty reading' and 'the one whose water-pistol I > confiscated in the first week of class'. > > So you may be better off letting the teacher specify some tags she can use > and apply to any student, which can be of use when you need to > tell one student from another, and the name just isn't doing it for you. > (Perhaps because you have several students with that name, but also because > this is a student you taught many years ago. The name is vaguely > familiar but the details have blurred over time. "Water-Pistol" will > evoke better memories than parents' name in this case, as if you can > barely remember the child you most likely have lost the parents altogether.) ... I have been thinking in terms of only my wife using the software. If I have the good (or mis-) fortune to create a successful and utile bit of software, I might find others using the program. So your points suggest I should look for a more flexible approach that any potential user will find effective. -- boB ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] How to effectively use a Student class with SQLite [Was Re: How to design object interactions with an SQLite db?]
In a message of Thu, 13 Aug 2015 23:42:33 -0500, boB Stepp writes: >Many of my wife's students do have their own email accounts, but, >alas, not all of them. I have not totally thought this through yet, >but the student data will include their parents' names and some of >their data. But it will be my luck that two students will have the >same name, John Allan Smith, with their dads having the same name! >But I guess I can list both parents' names. Surely that would enable >the user to reliably pick the correct student? > >As an aside, when discussing my wife's user requirements for this >project, I found out that some of her students have, shall we say, a >variety of parents: birth parents, multiple step-parents, parents who >are not allowed to have contact with their children, legal guardians >who are not parents, etc. Ay, yi, yi! > > >-- >boB You've found the 'variety of parents' problem. Listing the parents' names will only let your wife know she has the correct student if she habitually thinks of the parent names when she thinks of the student. I suspect her internal labelling is more likely to be along the lines of 'the short one', 'the one who plays the cello', 'the one who used to have difficulty reading' and 'the one whose water-pistol I confiscated in the first week of class'. So you may be better off letting the teacher specify some tags she can use and apply to any student, which can be of use when you need to tell one student from another, and the name just isn't doing it for you. (Perhaps because you have several students with that name, but also because this is a student you taught many years ago. The name is vaguely familiar but the details have blurred over time. "Water-Pistol" will evoke better memories than parents' name in this case, as if you can barely remember the child you most likely have lost the parents altogether.) Laura ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] How to effectively use a Student class with SQLite [Was Re: How to design object interactions with an SQLite db?]
On 14/08/15 03:16, 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? Sorry, yes. Anything involving people. the case of students with duplicate names, she might forget to enter one (or more, if there are that many). You can't really mitigate for that kind of error. Imagine popping up a dialog for every single record saying "Are you sure you didn't forget somebody else of the same name?" How annoying would that get?! Even if you only did it during bulk data input it would still be a pain. 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? No, you need to identify which subset of fields are sufficient to always identify a student. And that might mean all of them! I'm guessing this stands for "Model-view-controller" as in https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Correct. MVC is the standard UI OOP pattern, its been around a long time (with various minor variants) and it works. The main simplification is to sometimes join the View and Controller into a singe object. Microsoft did this with their Windows object model. is the controller serving as the API between the data (model) and the display (view)? No, or only partly. The controller captures and processes user input. It controls the state machine that determines which actions are valid and which are not depending on the states of the Model and the current Views(there may be multiple views of the same model) The controller is sometimes known as the "policy" of the UI - the rules of how it works. As such the controller is the thing that determines that an action is valid and makes the call to the Models UI. In most MVC implementations the Model will have a list of all open views and send a state update to those views so they can update themselves. In a few cases the Controller does that bit sand the Model replies only to the controller. If you are using a network model where different devices may have views onto the same object then you must use the first option. In a single desktop app the second option tends to be more efficient. In all cases its the Model that exposes the API that provides the business value/logic of the system. The View and Controller are purely UI focussed. 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? Pretty close. Any window that displays data(state) of an Model is a view. You could have a graphical view and a table view of the same data for example, and both could be on screen together. Or you could have two devices accessing the same data model over a network at the same time. In both cases the Model has multiple views and one or more controllers. correctly, the program logic (model) and controller need to be designed in parallel? Not always, but if you use the use case approach the controller implements the sequence of events and the model implements the actual actions. You can extract the actions from the use case and implement that separately. But in bigger projects the UI and database teams will likely work in parallel and with close co-operation. lines in other projects I have done. I will have to search for most applicable materials to my current project. A very simple example is the login use case Actors - User, SUD(System under design), UserDB Preconditions - None Postcondition - SUD Home screen displayed to user 1) User starts application 2) SUD displays login screen with username and password fields. submit is greyed out 3) User fills in name and password 4) SUD validates field content and enables submit button 5) user hits submit 6) SUD validates user name and password 7) SUD displays home screen 1A1 - SUD fails to launch 1A2 User retries 4A1 User fails to fill in all fields 4A2 SUD does not enable submit 4B1 User fills a field with invalid characters 4B2 SUD presents error message 6A1 User does not exist 6A2 SUD notifies user of error 6B1 Password is invalid 6B2 SUD notifies user of error 6C1 Password has expired 6C2 SUD initiates change password use case. 6D1 After 3 unsuccessful login submissions the SUD locks the user account, logs a security threat and notifies the sys admin. Notice its very common to have more error cases than happy path steps! Notice too that some steps have multiple error cases. Hmm. I was thinking that I would need all the student objects generated
Re: [Tutor] How to effectively use a Student class with SQLite [Was Re: How to design object interactions with an SQLite db?]
On Thu, Aug 13, 2015 at 11:13 PM, Laura Creighton wrote: > If your students need to provide a unique email address, then that is > a possibility to use to distinguish between ones with the same name. Many of my wife's students do have their own email accounts, but, alas, not all of them. I have not totally thought this through yet, but the student data will include their parents' names and some of their data. But it will be my luck that two students will have the same name, John Allan Smith, with their dads having the same name! But I guess I can list both parents' names. Surely that would enable the user to reliably pick the correct student? As an aside, when discussing my wife's user requirements for this project, I found out that some of her students have, shall we say, a variety of parents: birth parents, multiple step-parents, parents who are not allowed to have contact with their children, legal guardians who are not parents, etc. Ay, yi, yi! -- boB ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] How to effectively use a Student class with SQLite [Was Re: How to design object interactions with an SQLite db?]
If your students need to provide a unique email address, then that is a possibility to use to distinguish between ones with the same name. In Sweden, where this is known as the 'Anders Andersson' problem (that being the most common name in Sweden, and any organisation with more than a handful of members is likely to have several), a good many apps are now showing pictures of the Anders Anderssons and asking people to select based on that. The upshot of this is that Sweden is discovering that Prosopagnosia -- difficulty in telling the difference between faces is rather more common than has been known. Just in case you come up with this idea yourself Laura ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] How to effectively use a Student class with SQLite [Was Re: How to design object interactions with an SQLite db?]
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 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
Re: [Tutor] How to effectively use a Student class with SQLite [Was Re: How to design object interactions with an SQLite db?]
On 13/08/15 20:18, boB Stepp wrote: that I am puzzling over is the very real possibility of duplicate student names. Of course, I was planning on the Student db table having a primary key of student_id, which would be an unique identifier for a particular student. The problem with this is from the user's perspective: The teacher will naturally want to interact with the program using the student's name, possibly even a student's nickname. These can be non-unique. Yes, that's a standard problem in any HR type application. Names suck as database keys. But names are how humans interact. 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.. 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. (One nice feature if you are likely to doing a lot with one student is to provide a "sticky flag" that remembers the choice for all future queries in that session - you need a reset option somewhere too of course or the user has to quit the system and restart!) But many colleges now issue student cards with a unique ID. So the problem may not be as hard as you think. 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) 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. 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. I've used it on everything from small personal projects to multi-million dollar projects with hundreds of programmers. As a free side-effect you get free test scripts too. In terms of UI I imagine the user will have some sort of list of student names displayed. In a given school year in the case of two students with identical names, I imagine the target user (my wife) will want a student nickname displayed to differentiate between two (or more) such students. So she would select a student in the UI and start doing stuff. Yep, that's usually how it works. The class or year or age could also be choice differentiators too) I assume if I have a list of student names in the UI, then the program already created all of the student objects in the list, so the student_id primary key for each student would be freely available to use. However, if the student did not exist in the list, then a new student object would have to be created and its relevant attributes recorded in the student db table with its newly created student_id primary key. Yes. The "happy path" use case is only one student returned. The first error case is multiple students including an identifiable target. The second error case is no identified target. You are already beginning to think like a use case approach, the technique just formalises it and so forces you to uncover errors you might otherwise miss. 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. 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 studen
[Tutor] How to effectively use a Student class with SQLite [Was Re: How to design object interactions with an SQLite db?]
Beware! Lengthy post!! Sign of a confused boB. ~(:>) I believe that I understand now all of the things I want my project (Tentatively named "Montessori Classroom Manager".) to *do*. But I am currently spinning my wheels on how to implement classes, SQLite, and the kivy UI, so that they all effectively interact with each other. I think it is time to write some code and that I should start with the most fundamental class to the project, the Student class. The Student class, as I now envisage it, will have many attributes, which seem to naturally map to a Student db table. The first issue that I am puzzling over is the very real possibility of duplicate student names. Of course, I was planning on the Student db table having a primary key of student_id, which would be an unique identifier for a particular student. The problem with this is from the user's perspective: The teacher will naturally want to interact with the program using the student's name, possibly even a student's nickname. These can be non-unique. I like Alan's suggestion: On Sat, Aug 1, 2015 at 12:30 PM, Alan Gauld wrote: > On 01/08/15 17:34, boB Stepp wrote: >> 1) Create my various objects normally, but have their data attributes > >> fetched through some sort of db manager class I would design. > > Personally I tend to create a load() method that is used like a constructor > but fetches the data from the database > > myObj = MyClass().load(ID) > > Where load() returns self if successful. > Alternatively in Python you could define the ID as a parameter of init with > a None default > > def __init__(self,att1=None,att2=SomeDefault,...,ID=None): > if ID >self.load(ID) > else: >self.att1 = att1 # etc... > > Its conceptually simple and gives you full control of the SQL, but things > like inheritance can get tricky. Both his ideas rely on using the primary key for a student to fetch the information needed to create that particular student object, which the user will not normally ever use directly. 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. In terms of UI I imagine the user will have some sort of list of student names displayed. In a given school year in the case of two students with identical names, I imagine the target user (my wife) will want a student nickname displayed to differentiate between two (or more) such students. So she would select a student in the UI and start doing stuff. I assume if I have a list of student names in the UI, then the program already created all of the student objects in the list, so the student_id primary key for each student would be freely available to use. However, if the student did not exist in the list, then a new student object would have to be created and its relevant attributes recorded in the student db table with its newly created student_id primary key. 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. 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. 3) The program logic would reference each student object only with the student_id primary key uniquely associated with each such student object. Is this the way to approach this, or at least a good way? 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, so I can try selecting students, creating students, etc. Would the best way to go about this is to create an old command line-style menu system, which lists options by number, input number desired, action occurs etc.? As always, many thanks in advance! boB ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
