allowChannel() now throws exception

[contributte]

allowChannel() now throws exception

[hrach]

Yes, I know about this. This will require deeper refactoring, use 2.0.0 stable in the mean time.

[hranicka]

I temporary use somethink like this immediatelly before the payment process call:

    /**
     * @param Markette\Gopay\Service $goPay
     * @throws Markette\Gopay\GopayFatalException
     */
    private function setChannels(Markette\Gopay\Service $goPay)
    {
        $goPay->addChannel($goPay::METHOD_GOPAY, 'GoPay');
        $goPay->addChannel($goPay::METHOD_CARD_CESKAS, 'Platba kartou - ČS');
        $goPay->addChannel($goPay::METHOD_CARD_UNICREDITB, 'Platba kartou - Unicredit');
        $goPay->addChannel($goPay::METHOD_SUPERCASH, 'SuperCash');
        $goPay->addChannel($goPay::METHOD_PREMIUMSMS, 'Premium SMS');
        $goPay->addChannel($goPay::METHOD_MPLATBA, 'mPlatba');
        $goPay->addChannel($goPay::METHOD_KOMERCNIB, 'KB');
        $goPay->addChannel($goPay::METHOD_RAIFFEISENB, 'Raiffeisen bank');
        $goPay->addChannel($goPay::METHOD_MBANK, 'mBank');
        $goPay->addChannel($goPay::METHOD_FIOB, 'FIO banka');
        $goPay->addChannel($goPay::METHOD_UNICREDITB, 'Unicredit');
        $goPay->addChannel($goPay::METHOD_SLOVENSKAS, 'Slovenská spořitelna');
        $goPay->addChannel($goPay::METHOD_TRANSFER, 'Bankovní převod');
    }

Tag 2.0.0 is OK at all.

In master instead of ::allowChannel could be called ::addChannel from the Extension class . Or no?

[haltuf]

Sorry for that - didn't realize it will bump here, please ignore.

Do you have any ideas how to solve this bug once for all?
Approaches I was considering:

• bring back GopaySoap::paymentMethodList() call, just cache its results for a long time
• load list of methods from constants defined in Service.php - the problem is, PHP reflection cannot read phpdoc of these constants, so you lose information about human-readable name of the payment method ($title)
• load list in a way @hranicka suggests, just with the possibility for user to edit/rewrite this specification if needed (so the method probably shouldn't be private)

Seems to me, list of payment methods is quite stable, is even specified in API docs, but changes from time to time.

[f3l1x]

I vote for caching. And also for load list as @hranicka suggested. There could be quite more options to set it.

[hrach]

Personally, I would totaly remove getting channels. They are not specific for users, it's just something, which tells you which channel is available. Something like xml documentation. Obivously, you have to allow them "manually", so I would implemented only adding channels manually.

[f3l1x]

So, user have to add/allow channel before pay method is called. Am I right? I'll change it in master then.

[haltuf]

Does it mean not adding then via config.neon?

[f3l1x]

@hrach Did you mean stg like this? https://github.com/f3l1x/Gopay/commit/5691899f3a484b2a105bbd759911d2c56462b70e

Removed:

• allowChannel
• denyChannel
• addRowChannel
• $fetchedChannels

Added:

• onBeforePay - events that allow you to set channels & etc..

[hrach]

Rather not. I think:

• remove allow/deny
• rework addRowChannel to addChannel($code, $name, $logo, $offline, $description)

If you would you only event, it wouldn't be possible to bind buttons to form, would be?

[f3l1x]

@hrach
https://github.com/f3l1x/Gopay/commit/685fd3f6ae99326c7b714e33c5b6ee8f7d13ea8f - Is it better now?
https://github.com/f3l1x/Gopay/commit/7e096d74eb1b4435880974fad387f6351d24e36c - And do you think about pass channels via extension. I removed it.

[hrach]

yeah, it's seems to be the right way. about extension - dunno. maybe it should stay. in any cas, try it on your project and validate if the attitude is right :)