| Summary: | Eliminate DocumentationProvider annotation in favor of service approach | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Konstantin Komissarchik <konstantin> |
| Component: | Sapphire | Assignee: | Konstantin Komissarchik <konstantin> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | ling.hao |
| Version: | unspecified | Keywords: | plan |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Konstantin Komissarchik
DocumentationProviderImpl returns DocumentationData which in turn returns DocumentationResource. I think DocumentationData methods can be inlined into ModelPropertyDocumentationService/ModelElementDocumentationService. That leaves DocumentationResource, which would need to move to org.eclipse.sapphire.modeling package to be alongside the service classes. Also, DocumentationData includes merge strategy, but thinking through this I don't think merging is really necessary when we are talking about custom documentation service. By the time you are implementing a custom one, you can bring together content from wherever you choose already. Done. See the migration guide for details. Semantically, the big change is that content merging only happens for content specified via annotations. If a custom documentation service is specified, it is the sole source of the documentation. This allowed merging logic and all the handling of annotations to move from UI layer into a default documentation service implementation. Ling, please verify this one. Verified via sapphire-gallery's help, also skimmed over the modified code. |