[CONTEDIT-150] Define the public/private APIs of the Content Editor module Created: 27/Jul/17  Updated: 24/Aug/17  Resolved: 24/Aug/17

Status: Closed
Project: Content Editor
Component/s: None
Affects Version/s: None
Fix Version/s: 1.0.6

Type: Task Priority: Neutral
Reporter: Aleksandr Pchelintcev Assignee: Aleksandr Pchelintcev
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
dependency
depends upon MAGNOLIA-7105 Propose open API annotations Closed
Template:
Acceptance criteria:
Empty
Task DoR:
Empty
Release notes required:
Yes
Documentation update required:
Yes
Epic Link: Content Editor fine-tuning
Sprint: Basel 107, Basel 108, Basel 109, Basel 110
Story Points: 5

 Description   

Since Content Editor is about to be communicated publicly on the one hand, but on the other hand - contains quite some amount of technical debt, it seems like a crucial thing to try to reserve our right to change the parts of its code base freely. Even though some classes there are public formally, they aren't really meant for extension or re-use in the client code.

We want to consider such parts as private API and for that we need to do the following:

  • define the clear cut between the public API (e.g. definitions, actions etc) vs private (data binding plumbing, most of the code of custom Vaadin components used to provide content editor interface, all of the client-side code (that is a usual thing)).
  • evaluate options and choose the method to communicate the private API policy (through packages/annotations/linters etc)

This could be considered as a test bed that could prepare a public API strategy product-wide.


Generated at Mon Feb 12 00:17:34 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.