Gump is a complete validation and filtering system. It is something you would use for your application as a whole, for all your validation needs and not just for the input validation of a single class. So, if you need validation anywhere, you should be thinking about your strategy to involve Gump for those needs too. Once you have that answered, then you know how to also use Gump for your PDF invoice class and any others. To me, Gump looks like a nice service, which could be sitting in a service container (DI container). Take Symfony’s usage of their validator as an example.
As for the question of extending Gump, the answer to that question wouldn’t support your strategy on how to implement it within your application directly. Extending Gump would be extending its filters or validation methods to cover a validation or filtering case you have, which it doesn’t cover for you. If you would need to extend Gump, in order to cover your PDF invoice class validation, you would do so and then not load Gump directly into your service container. You’d load your own validation class, which extends Gump.
Gump also let’s you add rules on the fly too. (see the validation_rules() and filter_rules() methods). So that is another way to give it new filtering and validation features.
s_molinari, thanks for your reply.
So I think I should create a custom filter class.
One because it is easier to ask for the class alone instead of pulling in a whole package.
I will figure this out in the afternoon and will come back at it.
And, I take back what I said about it being a whole system for your validation and filtering needs seeing their todo list. It is a good start though. Still, looking at that big class, I wonder if it possibly needs to be broken into smaller classes actually. Maybe one for validation and one for filtering?