Re-implement the "Validate Selection" Use Case.

[jdickey]

This is an analogue to Issue #68 and, more directly, to Issues #69 and #70. Whereas Issue #68 concerned a reimplementation of the Publish a New Article Use Case, this issue addresses the Validate Selection Use Case. As with Issues #69 and #70, no specification for the reimplementation yet exists.

To close this issue, we need:

• a (new, never-before-done) spec for the Validate Selection Use Case analogous to that done for Publish a New Article; and
• a replacement for the existing Validate Selection Use Case.

[jdickey]

Right; this should be pretty straightforward. We have a spec, even if its known possible failure modes don't comply with current convention.

The current code doesn't have a Prolog::Entities::Result::Base-subclassing Result object, which inter alia means it doesn't do error-notifications properly, but instead has a simple thumbs-up-or-down method that doesn't expose any detail about why validation failed.

And yes, it still uses the old form-object convention, which Has To Go; we're not iterating around mutable state here.

It Would Be Very Nice to get some basic benchmarks of the existing code before we blow it away and replace it with the new hopefully-hotness...

[jdickey]

Closed with the 0.1.0 release of the prolog-use_cases-validate_selection Gem.

[jdickey]

This issue was closed prematurely. Yes, we have the reimplemented use case as a separate Gem, but we still have the obsolete implementation in this Gem that needs jettisoning. Back to the grind…

[jdickey]

Started on 0.16.0 by removing the existing code for the ValidateSelection use case in the main prolog-use_cases Gem. Tests for the old form object fail, as expected. What slipped our mind was that the new protocol uses a "result" object which includes a success? flag and an array of error items as appropriate. This does, and should, break the existing tests for the old class.