manuals-publisher: History
This repository was forked from the specialist-publisher repository in November 2015, thus the two repositories have the first ~1800 commits in common. The last commit which the two repositories have in common is this one.
Immediately after the fork the code in specialist-publisher was all removed and the application re-written from scratch to support publishing of specialist documents using the Publishing API as the canonical/only persistence mechanism.
At the point when the fork happened the application in this repository (now called manuals-publisher
) was responsible for publishing both manuals (and their sections) and specialist documents. The application was originally written in Feb 2014 and started life only being able to publish specialist documents. Publishing of manuals and their sections was added in Apr/May 2014 in PR #76 & PR #78.
The application had been developed in a rather unconventional fashion - using a custom dependency-injection container and the Domain-Driven Design / Hexagonal Architecture idea of decoupling the persistence mechanism from the domain model using repository classes. The app also contained extensive use of anonymous procs and classes with a single #call
method.
In September 2016 the Rails app in this repository was renamed from SpecialistPublisher
to ManualsPublisher
. In October 2016, the UI for publishing specialist documents was removed. Presumably before this point the re-written specialist-publisher app had taken over responsibility for publishing specialist documents.
By early 2017 this application had become extremely difficult to maintain. The unconventional architecture had led to so many levels of indirection that it was extremely difficult to understand what effect executing a single controller action would have. It looks as if one consequence of this was that bug fixes and enhancements sometimes worked around the architectural patterns rather than with them, making the codebase even more confusing.
From March 2017, developers from Go Free Range spent a couple of months refactoring the codebase towards a simpler and more conventional Rails app. The dependency injection container was removed, many levels of indirection were collapsed, and anonymous procs were converted into named classes. The remaining code and data associated with specialist documents was removed and the main gems used by the application (Rails, Mongoid, etc) were upgraded to much more recent versions. The current state of the codebase is described in more detail here.
While investigating converting the domain model to be a more standard set of Mongoid::Document
classes with all relationships defined as Mongoid associations, they decided that it might be simpler to convert the app to "fully-migrated" status with regard to the Publishing API, i.e. to use the Publishing API as the canonical/only persistence mechanism in the app. Their exploration of this idea is captured here and their ideas for possible next steps are recorded here.