Skip to content

version 1.1.0 of php component requirement released

I happy to announce the release of 1.1.0 of bazzlines requirement component for php. Important changes are:

  • added example WithDisabledCondition
  • added example WithDisabledItem
  • added getConditions() method to RequirementInterface - this easies up disabling single conditions or single items (by using condition->getItems())
  • added migration howto
  • added version eye and scrutinizer coverage
  • covered AbstractItem and AbstractCondition with unit test
  • created AbstractItem that implements ItemInterface
  • created IsDisabledInterface
  • created ItemInterface
  • created TestCase that is extended by all phpunit tests
  • implemented IsDisabledInterface to AbstractCondition
  • implemented IsDisabledInterface to Requirement
  • refactored ConditionInterface, addItem now only accepts ItemInterface instead of IsMetInterface
  • refactored Condition::getItems() - now returns plain php array
  • renamed ConditionAbstract to AbstractCondition
  • renamed and updated previous WithShutdown example to WithDisabledRequirement
  • updated dependencies

Disable your requirement, configuration based - php component requirement 1.0.5 released

I'm happy to announce the new release 1.0.5 of my requirement component for php.

This version resolves a feature request (the first official one by the way :-D). With version 1.0.5, you are now able to shutdown a requirement. This leads to the fact that the requirement is not evaluating its internal collections or items. Instead, it returns "true" immediately.

This version is shipped with an example so take a look into it.

create simple and reusable validators using the php requirement component - php component requirement 1.0.4 released

I updated the requirement component to 1.0.4. The new version contains the validator example. By creating this example, i added two new features for upcoming releases, so stay tuned :-).

The example is shipped with a validator collection which contains all needed validator items. It would definitely make more sense, if you would name that validator collection more specific like "IsValidTableForGermany" (or "IsValidUserName" if you want to switch context). All validator items need a injected table example class. Since the requirement component is dealing with automatically injection, you don't have to take care about this :-).

As you can see in the example class, all you have to do is to inject the item you want to validate and call "isMet()". The example itself creates a bunch of tables by choosing random properties.

What are the benefits of using the requirement component also for validation? Reusable and simple testable validator items and a endless flexibility of item combination by using the power of existing and and or condition.

  • add example to use the component as validator

Enjoy it :-).