Add mapper to fit response with needed schema and add a way to extend it

[cewald]

This is a further extension of #25.

It's about the automatic the JSON mapping using JSON_NUMERIC_CHECK which causes some type errors, for example for leading zeros in numeric strings (which should stay strings) – like in some german postcodes or telephone numbers with a leading zero.

I added a way to extend the mappings of @mtarld using the config.xml like in DivanteLtd/magento1-vsbridge-indexer. So now you can add a custom mapper for your type by adding a module with the following config xml node:

<?xml version="1.0"?>
<config>
    <global>
        <vsf_bridge>
            <mapper>
                <types>
                    <address>
                        <mapper>
                            <add_custom_attribute_mapping>Divante_VueStorefrontBridge_Helper_Mapper_CustomClass</add_custom_attribute_mapping>
                            <filter_another_attribute>Divante_VueStorefrontBridge_Helper_Mapper_SecondCustomClass</filter_another_attribute>
                        </mapper>
                    </address>
                </type>
            </mapper>
        </vsf_bridge>
    </global>
</config>

The classes for the mapper extensions declared above must extend the Divante_VueStorefrontBridge_Helper_Mapper_Abstract class and should contain your custom mappings and options for your custom attributes.

For example: the following code in combination with the configs above will filter out the attributes firstname and lastname from the addresses response object.

<?php

class Divante_VueStorefrontBridge_Helper_Mapper_CustomClass extends Divante_VueStorefrontBridge_Helper_Mapper_Abstract
{
    /**
     * Get Dto attribute blacklist
     *
     * @return array
     */
    protected function getBlacklist()
    {
        return ['firstname', 'lastname'];
    }
}

This way the mapping is more flexible and can be extended without overwriting classes.

[tdugue]

Hi @cewald @afirlejczyk ,

I didn’t have time to work more on the sorry mapper.

Why did this PR ask to be closed ? I’ve been working with bridge for 1 year and it’s the mapper without the @cewald update.

I make a new setup with magento 1 storefront-api and vue storefront api so I can advance a can advance on the problem.

But if we could give a little summary of what has been done and what is wrong :)

Thanks

[cewald]

This was about to have a way to extend the types of mapped fields without extending the module. Like if you have custom mappings for specific fields because your system is e.g. hooked to a merchandise management system which depends on specific field-types. In our case it was the postcode and second address field where the leading zero code was stripped away. In the master branch you couldn't change date without changing the core. With this changes, based on an earlier PR, you can.