Skip to content

added json_content_type parameter as per discussion at https://github… #6

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

Conversation

slootsky
Copy link
Contributor

added json_content_type parameter as per discussion at #3

@makermelissa
Copy link
Collaborator

A better approach to this may be to have a content_type parameter that defaults to None (which would cause it to behave how it does now) and if it has either CONTENT_IMAGE, CONTENT_JSON, or CONTENT_TEXT and then it wouldn't have to guess looking at headers.

Copy link
Collaborator

@makermelissa makermelissa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See previous comment.

@slootsky
Copy link
Contributor Author

slootsky commented Dec 31, 2020

I was looking at doing the code change you suggested, and I have a couple of questions:

  • there is already a local variable content_type. Would you like me to use force_content_type as the parameter name, or rename the current local variable to something else? If you'd like the local variable renamed, what would you suggest? use_content_type ?
  • do you have a better way for me to check for a valid content_type other than "if content_type not in (CONTENT_JSON, CONTENT_TEXT, CONTENT_IMAGE) ?
  • What exception would you suggest I throw if an invalid value is passed for content_type? ValueError ?

@makermelissa
Copy link
Collaborator

What I was thinking was having a content_type parameter that defaults to None. If it is None, it would auto-detect like it is currently doing. A value check would be done to make sure it is one of the 3 handled types and if not, it would be set to None and be auto-detected like it currently is.

In the "auto-detect" code, it would start by assigning the value to CONTENT_TEXT and check the headers like it currently does. So I think you can re-use the variable name as the parameter and in the auto-detect section.

@Lnk2past
Copy link

Lnk2past commented Jan 6, 2021

The changes as they are now only allow this to be exercised from the fetch_data method - could the fetch method in PortalBase forward along **kwargs to fetch_data to allow it to be specified from PortalBase.fetch?

@makermelissa
Copy link
Collaborator

I'm doing a huge refactor that takes a similar approach to this without adding any keywords, so this PR code won't work so well. I did take the requested functionality into account and the approach I ultimately decided to take was to add a add_json_content_type() function that adds it to a list and then it's automatically checked.

@makermelissa
Copy link
Collaborator

Closing this in favor of #8 which is already merged in and includes this functionality.

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.

3 participants