Allow providing custom fields mappings

[s0undt3ch]

This will allow sub-classing fields and allow marshmallow_jsonschema to
render them as the parent class would.

[coveralls]

Coverage remained the same at 100.0% when pulling 96a52c8 on s0undt3ch:master into 6f51771 on fuhrysteve:master.

[fuhrysteve]

Wow this is great and thanks for adding the test case - sorry I didn't get around to this sooner. So I've been thinking about this a little, and while I like the new functionality, I'm a bit hesitant to encourage behavior that basically isn't thread-safe when it seems like there's a good alternative. What if the implementation looked more like this:

# Documented and recommended approach for general use
json_schema = JSONSchema(json_schema_type_mappings={fields.Color: text_type})
json_schema.dump(MySchema())

If you really want to have this globally, you can always do this somewhere global:

JSONSchema.JSONSchemaTypesMapping[fields.Color] = text_type

Or, you could simply extend the base JSONSchema class, which would be the recommended way of adjusting the behavior for global use:

class JSONSchemaExtended(JSONSchema):
    pass

JSONSchemaExtended.JSONSchemaTypesMapping[fields.Color] = text_type

Let me know what you think

[s0undt3ch]

So, are you still OK of I remove the classmethod but rely on the class level attribute to either subclass or update the class attribute?

[coveralls]

Coverage remained the same at 100.0% when pulling 593c752 on s0undt3ch:master into e6a6bce on fuhrysteve:master.

[coveralls]

Coverage decreased (-0.7%) to 99.301% when pulling 18ab94d on s0undt3ch:master into e6a6bce on fuhrysteve:master.

[coveralls]

Coverage decreased (-0.7%) to 99.291% when pulling d3009c8 on s0undt3ch:master into e6a6bce on fuhrysteve:master.

[coveralls]

Coverage remained the same at 100.0% when pulling dba3fc8 on s0undt3ch:master into e6a6bce on fuhrysteve:master.

[s0undt3ch]

Could you please take another look and consider this again? Thanks!

[coveralls]

Coverage remained the same at 100.0% when pulling 2b82154 on s0undt3ch:master into e6a6bce on fuhrysteve:master.

[s0undt3ch]

Ok, this final solution seems like the least intrusive

[coveralls]

Coverage remained the same at 100.0% when pulling 1f7c1de on s0undt3ch:master into e6a6bce on fuhrysteve:master.

[s0undt3ch]

Polite ping.

[s0undt3ch]

Polite ping.

[s0undt3ch]

Polite ping.

[atmo]

Hi @s0undt3ch ! I would like to recommend using a different approach here. Have a look at how apispec module handles the same problem: it defines a decorator map_to_openapi_type which modifies the global mapping.

I think that decorator is a more convenient and readable solution. Could you please rework your PR to use the decorator instead and resolve the conflicts? See also apispec docs for custom fields.