Skip to content

first proposal of the project structure #7

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

dierickxsimon
Copy link
Collaborator

@dierickxsimon dierickxsimon commented Apr 9, 2025

Work in progress...

Created some base classes that i think could be the bassis of the package.

BaseFileHandler is the base class for all files and contains most of the logic for reading and writing of the file. The BaseFileHandler has an data attribute that contains a CompositeData instance where all the logic of the data is handled. The CompositeData can be inherited from the define the data structure of a certain file. The fields of a file can then be defined with the help of the DataComponent. What do you guys think?

I just nottice i didn't put a lot of documentation inside the code but I will do it in the next commit.

@dierickxsimon dierickxsimon mentioned this pull request Apr 9, 2025
@AartGoossens
Copy link
Collaborator

Hey Simon,
Great job on the PR.
I like the implementation with (nested) ABC classes, I think it gives a lot of flexibility for different data types.
One thing that is not immediately clear for me with this implementation is how this implementation would "enforce" a standard way to store for example distance or speed data. For example, how would BaseFileHandler.to_df() always parse speed data in the same way? Or is the point that the implementation doesn't enforce that?

@dierickxsimon
Copy link
Collaborator Author

Hi Aert
This question kept me also awake for a couple of nights... But I think that the best way is that we create a class inhertited from the DataComponent called RecordData (maybe we should think about a more brother term like ActivityData or somthing) where we define how the data should look and thus also how we should parse the the data. The second options is that we even go further and create for every type of data (speed, power, etc...) a seprate component (and not store the entire ActivityData as a component it self ). so that the parse funciton is implemented in for example a SpeedData component but i don't know if this is needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants