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
Translate to de es fr it pt ja

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.

Translate to de es fr it pt ja

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 :-).

Translate to de es fr it pt ja

php component requirement 1.0.3 released

Version 1.0.3 of the requirement component for php is released. Changes are listed below.

  • add caching for magic __call condition in abstract method to not iterate over each item (invalid cache if new item is add)
  • Refactored locking by using lock component

Enjoy it :-).

Translate to de es fr it pt ja

php component requirement - version 1.0.1 released

Version 1.0.1 of Requirement Component for php is released. Changes are below.

  • Added annotations to example requirement
  • Added return value $this to magic __call methods of requirement and condition
  • Added return value $this to addItem method of ConditionInterface
  • Added return value $this to addCondition method of RequirementInterface
  • Added lock and isLocked method to RequirementInterface, RuntimeException is thrown if addCollection is called and requirement is locked
  • Updated Readme with explanation of provided examples
Translate to de es fr it pt ja

php component requirement - transfer business logic into code like a breeze

Reason Of Development

As a php developer, i have to deal with a lot of refactoring tasks day in and day out. Refactoring includes not only code refactoring but also business logic refactoring. A team member right now had figured out a general problem and we all knew that we have to put "the chaos into a cage" because of the following reasons:

  • Developers are lazy and want to call a simple method instead of rewriting complex expressions
  • After we found strange parts of code, we want to put that into a sentence to spot the business logic
  • We want to have a generic component where you can reuse business items
  • Since business logic can became nested, the component should handle this

After we (take a look to the credits please) tied up the requirements, it took some time to get a feeling of how to put this into classes. After a while, i had a longer talk with a team member and he presented me his idea. I liked his idea but found some drawbacks. Since it this is a normal way of coding, it really isn't a fault of the team member (and i'm also not a better programmer then he), but thats how this component was initial created. While i was on my way back home, i had some ideas how to keep things simple and generic and started that project. On the next day, jens joined me and we quickly made some progress and where able to tag version 1.0.0 pretty soon.

Common Terms And Names

To understand the component, it is worth to know about the used terms and names. We finally decided to use the following ones.

  • Requirement: Thats the class you want to work with. Extend it or use it straightaway via a factory. This class represents the business logic with all "and's" and "or's"
  • Condition: After reading and writing business logic, each is full of "or's" or '"and's". Thats why we provide two condition that are used to handle collections of business items (simple rules)
  • IsMetInterface: To keep it simple, when you implement a business logic or validate against one, you only want to know "is this requirement met or not", so thats what the interface is for. This interface is implemented in the Requirement as well as in the Condition and you have to implement it in your item as well
  • "()" are used to represent an and condition: ("foo", "bar") is "foo and bar"
  • "[]" are used to represent an or condition: ["foo", "bar"] is "foo or bar"


The component is shiped with some examples. Feel free to pull some more. Nevertheless, to use this component, you have to do the following steps (and yes, this is already the example ;-)).

  • Try to sum things up by writing a sentence like: "The user mets our requirement if he is interested in OOP or big data and if he loves open source software, has no problem to read man pages or use his favorite internet searchengine or if he is already a maintainer or a contributor to an existing open source project"
  • Slice out the items that matters: "OOP", "big data", "loves open source", "read man pages", "use favorite internet searchengine", "maintainer", "contributor"
  • Create classes for each item that implements the IsMetInterface and that provides a usefull setter method
  • Collect the items into conditions: [(["OOP", "big data"], "loves open source"["read man pages", "use favorite internet searchengine"]), ["maintainer", "contributor"]]
  • Create the items and inject them to the right conditions, be aware of the fact that you even can inject conditions into conditions (meaning combine a condition with another)
  • Implement this into an class that extends the Requirement class or let it be assembled via a factory

Hints For Using And Developing

All in all you have to implement a setter method to your item. You can create setter methods in your requirement or simple use annotation. The requirement class and the condition classes are using the magic __call method to hand over the call from the requirement through the condition to the item.

If you want to create a requirement class that assembles itself or use a factory is a decision you have to make.

Download And Install


git clone

require: "net_bazzline/component_requirement": "dev-master"


Thanks to Mihai Andrei Cosma - this is your idea, developed by ourselves :-).

Translate to de es fr it pt ja