Publish a new Article created by a User.

[jdickey]

The "user-eye view" description in Issue #1 described "an" action as

log in, create a new article, and submit it for publication.

Logging in and content entry are delivery-system- and UI-specific, respectively; we've already established an interface for querying the current user. Although it's entirely likely that we'll want to add domain logic to the act of logging in (is this user on a particular type of membership or a member of a group that requires additional processing on login?), none that is required for product release 0.5 seems obvious. Editing, including constraints on field values, will be at least deferred. That leaves publication, which at this stage is synonymous with persistence.

The steps involved should therefore likely be:

1. Content validation as appropriate (body and/or image URL specified; any specified image URL valid);
2. Claimed author name identical to current logged-in member?
3. As this is a new article, an existing article with the same name by the same author will fail the use case;
4. Persist that sucker; and
5. Report success.

One might think that this requires access to two repositories, one to get user information and one to persist the article to. We don't need the user repository; we've already established that a separate interface exists to query the current user name, which is all we're interested in here at the moment. This may well change after product release 0.5.

[jdickey]

An interesting "quirk" in ActiveModel::Validations is that. when using custom methods for validation, the method name must not end with a ? character. validate :all_right is acceptable (so long as an #all_right method exists on the model-like class including ActiveModel::Validations), but validate :all_right? is not; the #all_right? method will never be called. The documentation is, of course, completely silent on this "feature".

[jdickey]

The question mark on the title for Commit 199eb3e was prudent; the form object doesn't yet know about keywords and, while Prolog::Core::Article will happily instantiate itself without them, that's not what's wanted. Once more into the cauldron we go…

[jdickey]

Virtus custom coercions allow us to automagically clean up keywords by declaring them using an attribute class like

        # Virtus attribute to clean up keyword strings before persistence
        class KeywordList < Virtus::Attribute
          def coerce(value)
            value.map { |item| item.to_s.strip.gsub(/\s{2,}/, ' ') }
          end
        end

This will cause the value to be converted to lower case and have excess leading, trailing, or embedded spaces cleaned up on initialisation/assignment. We could do this for other strings, e.g., titles, and reduce the amount of validation dreck needed. Oh well.