thewillyan / ecloset Goto Github PK

The user may want to see only some clothes based on some criteria, so we should implement the following functionalities

• List based on user preference (size, sex, color, etc.)
• List only clothes for sale
• List only clothes for donation

Styles are also part of the filter system and each time the user selects a style as a filter for clothes the style['count'] should be incremented by one. To do this, we need the following filters

• List all styles
• List clothes of a certain style

My suggestion is that clothing filters and style filters must be added to the clothing.py file and style.py file, respectively.

Better handling of user errors is fundamental for a good application. that is why this issue was created with the following goals:

• Improve the error reporting system
• Better handle data entry errors (Eg.: not lose previous data)

• Add the feature to add clothes based on a file passed as parameter by the command line.

Eg.: The following command gonna add all clothes from input_file.toml

python ./main.py input_file.toml

The first problem we may solve is the way we represent clothes and styles on RAM based on user input.

For the clothes, my suggestion is:

generic_clothe = {
    'id':  int,
    'type': string,
    'sex': string,
    'size': string,
    'color': string,
    'purchase_date': (int, int, int),
    'status': string,
    'price': int
}

where

We already discussed the Style data structure, which looks like this:

generic_style = {
    'name': string,
    'count': int,
    'clothes_sets': [ [id1, id2, id3] ]
}

where 'count' is the number of times this style has been selected by the user, [ id1, id2, id3 ] is a "clothes set", id1 is a id of a clothing of the type "upper", id2 is a id of a clothing of the type "lower" and id3 is a id of a clothing of the type "footwear".

The implementation of Clothing and Style as well as the functions that operate on them must be in different files since they are completely different data structures. Eg: style.py and clothing.py.

Once the clothes are stored, the user can choose which ones he wants to donate or sell. That's where this system comes in with the following functionalities

• Sell clothes
• Donate clothes
• Store donated and sold clothes in a file

The donated and sold clothes are stored separately in different files. Eg: donated_clothes.toml and sold_clothes.toml.

My suggestion is to reuse the clothes_data.toml template:

[Clothing_1]
id = 1
type = "upper"
size  = "M"
sex = "U"
color = "blue"
resolved_date = "10/02/2022" # date of sale or donation
price = 5000 # only for sold clothes
agent = "ONG or Person" # buyer or donation receiver

Where the difference between a donated clothing and a sold clothing is the existence of the price field.

The clothes that are donated or sold are moved from clothes_data.toml to donated_clothes.toml or sold_clothes.toml, respectively.

To improve functionality and the test process, it's very important to add a storage system as son as possible.

Due to the guidelines, we don't have much freedom on what kind of data is stored. I suggest the following template

#clothes_data.toml

[Clothing_1]
id = 1
type = "upper"
size  = "M"
sex = "U"
color = "blue"
purchase_date = "10/02/2022"
status = "stay"
price = 5000 #optional
styles = [ "winter", "summer", "party" ]

A blank line should be used to determine the end of a data set.

All the CRUD components should be part of the storage system, that is, we should implement the following requirements

• Add data to storage
• Read stored data
• Update existing data
• Remove stored data

All storage-related operations should be in a single, separate file. Eg: storage.py.

This is an instance of the issue #3 but, since it depends on #4 which is a completely different feature, I chose to remove it from the scope.

In a nutshell, what should be done is:

• add the functionality of filter donated clothes of a specific agent.