Closed jdickey closed 8 years ago
This issue exists because, in the current implementation, endpoints are only guaranteed to be valid at the time the Proposal is created; other Contribution Proposals occurring before the selected content will invalidate the endpoints, whether those Proposals are Responded to or not. The Accept and Reject Single Proposed Contribution use cases have been implemented to look for the begin- and end-Proposal marker tag pairs in the body content; that is much safer and more reliable assuming that the persisted content cannot be modified by any outside agent. Replacing the :endpoints
attribute of the ProposeEditContribution::Attributes
class with an :original_content
attribute, containing the selected range at the time the Proposal was created, is a better solution.
agreed
As a reminder, endpoints are and must remain input parameters to ProposeEditContribution#call
; they're part of how the UI selection mechanism communicates the content selection to the back-end application. But they go no further.
Also, note that :original_content
is a pseudo-attribute (reader method whose return value is added to #to_hash
). Most if not all of the work for this appears to have been done as part of #57, at about Commit 0fc0a66. All that remains is some leftover bits in test/prolog/entities/contribution/proposed_test.rb
(here, here, and here).
It's arguable whether the endpoints are needed in the
Contribution::Proposed
entity. What appears more compelling is to include the original content of the selected range at the time the Proposal is submitted, for presentation to the Article Author as part of the Respond-to-Proposal UI. This will require changes to the entity, and to the use-case class which populates it.The amount and specificity of churn in these classes to date suggests that it would be wise to further decompose/decouple the entity and/or use case; appropriate options for doing so are less immediately obvious.
(pinging Issue #55 and PR #57)