Difference from VotingAPI

The VotingAPI is centered solely around the task of recording, storing, and calculating "votes" for a piece of content – something it does quite well. The Evaluation API's intended use is to merely add criteria to a node that can be evaluated however for whatever purposes. As such, the Evaluation API was not intended to be used for "rating" content or "voting" on content, but rather it can be used to add eligibility requirements to a node that is to be rated or voted on. In this scenario, the Evaluation API makes a nice compliment to the VotingAPI (as well as other modules). Interestingly, this is the notion that gave birth to my module. We have a series of websites that have different types of contests on each that make heavy use of the VotingAPI.

However, we ran into problems when our clients started requesting different eligibility rules per contest. For example, one contest may have an age limit restriction where only users 18 and older could participate. Another contest may not care at all about age limits. Some contests required users could only vote once per day, some once per week, some once ever. Some contests had a specific window of time in the day that users could vote. Some contests required users had entered another contest as a prerequisite. So, as you can see, the business requirements for checking eligibility rules like the ones I've outlined quickly exceeded the scope of what the VotingAPI does and was meant to do. We wanted a solution that would be flexible and not require much more overhead. We also wanted a solution that wouldn't require us to write or modify a new module each time contest requirements changed. Hence, the Evaluation API was born to address this need. VotingAPI still handles the voting, Evaluation API handles the requirements check. While developing the Evaluation API for our contests (which started life off being called the Eligibility API), I realized it could easily be extended to handle any number of situations where a node requires additional validation of some sorts. I wrote this module so that other developers wouldn't have to jump through as many hoops to accomplish this.

I'm planning on including some better examples of various use cases in the handbook documentation I'm writing currently to better illustrate. Hope my explanation helps!