RFC: Remove class based message-types

[bummzack]

This is a follow up to this question, which didn't get any feedback: #123

Motivation

The gateway message classes don't contain any logic or custom data and their only purpose at the moment is to generate a custom value in the ClassName ENUM.
Instead of cluttering the source-files with lots of individual class files, I'd like to propose this new architecture:

Merge two top level message classes

PaymentMessage and GatewayMessage get merged into one class, named PaymentMessage.

I don't see a future use for payment messages without a Gateway, since all our messages are going to revolve around Gateways anyway. For other types of messages, we have separate means of logging now.

The third class that has separate data GatewayRequestMessage can remain as a separate class (maybe rename to PaymentRequestMessage for consistency).

Using a separate naming scheme (PaymentMessage instead of GatewayMessage) also helps differentiate between native omnipay classes and our own classes.

Replace subclasses with a DB-field

All the existing subclasses are basically there to build the ENUM in the PaymentMessage table. I propose to remove these subclasses and create a Type field on PaymentMessage. This can be an indexed string field or an enum.

All message types will be defined as const in the codebase and can be used to create and look up messages by type. These constants should be defined in the service that generates the messages, so that new services can add their own.

Advantages

• Less classes, which makes the architecture easier to understand
• Better readability of the payment message type. With the namespaces, the types have now become really long, which makes it harder to read (eg. in the CMS or when looking at the Database or a logfile). Example: SilverStripe\Omnipay\Model\Message\PurchaseRequest instead of just PurchaseRequest
• Types will be defined by the classes that generate these messages

Disadvantages

• Upgrading will become more complex.
• There's no longer a tight coupling between a PaymentMessage subclass and its "type".
• You can't decorate or use Injector to alter a single message-type (since the message-types don't contain any logic or data, I currently don't see any use-case for this)

[mlewis-everley]

@bummzack I read issue #123 first so have posted a comment there.

Basically I agree with you, I was thinking rather than an enum though, use something like a varchar and assign possible types as a config variable.

This means if users wanted to add more statuses (though I am unsure why), they can do it fairly easily?

Also enum's are a little annoying (see also @dhensby's rant on slack a few weeks ago) :-)

[bummzack]

What is the problem with Enums? I think Varchar is a poor replacement for Enum.

If not using an Enum, I think the proper substitution would be a relation.

[dhensby]

http://komlenic.com/244/8-reasons-why-mysqls-enum-data-type-is-evil/