search

goldenphoenix713 / spielpendium

GNU General Public License v3.0
1 stars 0 forks source link

Design Internal Data Structure #9

Open goldenphoenix713 opened 3 years ago

goldenphoenix713 commented 3 years ago

Spielpendium will need an internal data structure to keep track of information pulled from the database as well as inputs from the user. An initial design of this data structure will help with writing code for other issues, such as #1, #2, and #4.

This issue will be closed when an internal data structure is designed.

goldenphoenix713 commented 3 years ago

This can either be it's own class or just use a dictionary. The advantage of using a class is that we can define methods to add, remove, and read data easily in other parts of the code. However, a dictionary might be all that is needed.

goldenphoenix713 commented 3 years ago

Potential Class Structure:

Game Object: Holds information about a game. Profile Object: holds information about the user profile who's game list we're reading from on BGG. GameList Object: Collection of Game Objects with an associated Profile Object.

All of these can, once again, be implemented using just dictionaries and lists, too. However, using classes might keep things more organized.

Methods or functions? Methods are cleaner since they're associated with the class. If they're only used for that class (very likely), then a class approach might make more sense. Functions would be grouped in a module for data structure manipulation, but otherwise don't have any association with the data structure.

goldenphoenix713 commented 3 years ago

I'm leaning towards making a class, mainly because of the associated methods. It just makes sense to me.

goldenphoenix713 commented 3 years ago

A Game object holds the information downloaded from BGG (internally dictionary, likely). A GameList object is a collection of Game Objects, and well as some additional metadata (list/pdf name, owner name, date last uodated, etc). Object names are subject to change.

goldenphoenix713 commented 3 years ago

https://doc.qt.io/archives/qt-4.8/modelview.html

goldenphoenix713 commented 3 years ago

https://www.pythonstudio.us/pyqt-programming/modelview-programming.html

goldenphoenix713 commented 3 years ago

https://www.pythonguis.com/tutorials/modelview-architecture/

goldenphoenix713 commented 3 years ago

Based on that last link, it looks like I can make a Games class subclassed from a Qt model class.

goldenphoenix713 commented 3 years ago

Based on the structure of the information pulled from BGG, since there's not much nesting, a QAbstractTableModel is probably the best class to subclass.