You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The class and interface names and how they relate to each other are not really clear and can be misleading without reading their source.
(I'll omit the prefix/pseudo-namespace for brevity.)
Right now:
VersionDetector => detects version AND provides message VersionMessage => sets criteria AND acts as controller MessagePresenter => renders message AND disentangles conflicting Whip versions
Proposed layout:
(off the top of my head, might need adjustments)
Message => value object representing a message VersionRequirement => value object representing a "component => minimum version" association VersionTester => gets a VersionRequirement and returns whether it is met ComponentMessage => gets a failed VersionRequirement and turns it into a renderable Message MessageFilter => filters the collection of Message objects to only show the relevant ones (to disentangle conflicting Whip versions) MessagePresenter => renders all Message objects RequirementsCheck => 1. runs each passed-in VersionRequirement through the matching VersionTester, 2. fetches the matching ComponentMessage for each failed VersionRequirement, 3. passes all collected Message objects through the MessageFilter, 4. Passes the filtered collection of Message objects to the MessagePresenter. CheckVersions => facade to provide simplified access to execute a version check.
Proposed normal flow:
(I added MySQL as well to demonstrate usage with multiple requirements.)
// Hook into user interface.
$message_presenter = new WPMessagePresenter();
$message_presenter->register();
// Set up requirements.
$requirements = new RequirementsCheck(
$message_presenter,
[
new VersionRequirement( 'php', '>=5.6' ),
new VersionRequirement( 'mysql', '>=5.7' )
]
);
$requirements->check();
The value object Message is meant to encapsulate some logic in dealing with messages, and to allow external injection of arbitrary messages while still being able to ensure integrity by type-hinting against them, instead of a scalar string.
The class and interface names and how they relate to each other are not really clear and can be misleading without reading their source.
(I'll omit the prefix/pseudo-namespace for brevity.)
Right now:
VersionDetector
=> detects version AND provides messageVersionMessage
=> sets criteria AND acts as controllerMessagePresenter
=> renders message AND disentangles conflicting Whip versionsProposed layout:
(off the top of my head, might need adjustments)
Message
=> value object representing a messageVersionRequirement
=> value object representing a "component => minimum version" associationVersionTester
=> gets aVersionRequirement
and returns whether it is metComponentMessage
=> gets a failedVersionRequirement
and turns it into a renderableMessage
MessageFilter
=> filters the collection ofMessage
objects to only show the relevant ones (to disentangle conflicting Whip versions)MessagePresenter
=> renders allMessage
objectsRequirementsCheck
=> 1. runs each passed-inVersionRequirement
through the matchingVersionTester
, 2. fetches the matchingComponentMessage
for each failedVersionRequirement
, 3. passes all collectedMessage
objects through theMessageFilter
, 4. Passes the filtered collection ofMessage
objects to theMessagePresenter
.CheckVersions
=> facade to provide simplified access to execute a version check.Proposed normal flow:
(I added MySQL as well to demonstrate usage with multiple requirements.)
Proposed simplified flow (using the Facade):
The text was updated successfully, but these errors were encountered: