플러그인 시스템
플러그인으로 뷰어 확장
Doconut의 핵심은 간결하게 유지됩니다; 선택적 기능은 플러그인 형태로 제공되며 — 뷰어나 서비스를 제공하는 별도의 NuGet 패키지이며 라이선스에 따라 활성화됩니다. 이 페이지에서는 등록 모델, 런타임에서 라이선스 게이팅이 어떻게 동작하는지, 그리고 자체 뷰어를 어떻게 연결하는지 설명합니다.
플러그인 등록
각 플러그인 패키지는 하나의 플러그인 클래스를 노출합니다. 시작 시 한 번 등록합니다:
builder.Services.AddDoconut(options =>
{
options.AddPlugin<Doconut.Plugins.Converter.ConverterPlugin>();
options.AddPlugin<Doconut.Plugins.Dicom.DicomPlugin>();
});AddPlugin<TPlugin>()는 플러그인을 인스턴스화하고 DoconutOptions에 보관된 플러그인 레지스트리에 대해 Register 콜백을 호출합니다. 플러그인이 제공하는 모든 것은 플러그인의 필수 기능으로 태그됩니다. AddDoconut()은 등록된 플러그인을 즉시 검증합니다: 라이선스가 없거나, 레거시 TRIAL 파일이 있거나, 해당 기능이 없는 유료 라이선스인 경우 InvalidOperationException으로 시작이 실패합니다. Temporary/Demo 등록은 만료 후에도 유지되지만, 런타임 기능은 만료 날짜 이후에 회수됩니다.
계약
플러그인은 의도적으로 작은 인터페이스를 구현합니다:
public interface IDoconutPlugin
{
string Name { get; } // e.g. "Doconut DICOM Viewer"
LicenseCapability RequiredCapability { get; } // the license gate
void Register(IDoconutPluginBuilder builder); // contribute viewers/services
}Register 내부에서, 빌더는 두 종류의 기여를 받습니다:
builder.RegisterViewer(".dcm", () => new DicomViewer())— 파일 확장자를 위한 뷰어,builder.RegisterService<TContract>(() => …)— 파이프라인의 다른 부분에서 조회할 수 있는 타입화된 서비스.
기능 및 게이팅
기능은 라이선스 단위입니다. Converter와 Dicom은 선택형 플러그인으로 제공되며; Search와 Annotation은 동일한 방식으로 게이팅되는 내장 기능입니다. 기본 뷰어는 아님 — 전제 조건이며 라이선스 서비스의 IsViewerLicensed로 노출됩니다.
시작 시 검증은 일반적으로 라이선스가 없는 플러그인이 요청 파이프라인에 들어가는 것을 방지합니다. 뷰어 팩토리는 또한 두 가지 방어적 런타임 규칙을 적용하는데, 이는 시작 후 권한이 변경될 경우 중요합니다:
- 플러그인이 내장 뷰어를 대체 (플러그인이 내장 레지스트리에서도 처리하는 확장자를 주장하는 경우): 기능이 라이선스된 경우 플러그인 뷰어가 우선합니다; 그렇지 않으면 Doconut은 조용히 내장 뷰어로 되돌아갑니다. 사용자는 여전히 문서를 볼 수 있지만 플러그인 기능은 제공되지 않습니다.
- 플러그인 전용 포맷 (예:
.dcm— DICOM은 내장 뷰어가 없음): 기능이 없으면 열기 호출이 강제로 실패합니다:
LicenseException: This document type requires the 'Dicom' plugin license.활성화된 Temporary 라이선스는 모든 기능을 부여합니다 (깨끗하고 워터마크 없는 기본 뷰잉). 이는 실서비스 시작 시 놀라움의 전형적인 원인입니다: 하나의 기능이 누락된 구매 라이선스로 동일한 플러그인을 등록하면 AddDoconut()이 시작 시 실패합니다. 배포 전에 IsCapabilityGranted(...)를 플랜과 비교하십시오. 반대로 라이선스가 전혀 없으면 아무 것도 부여되지 않습니다 — 라이선스가 없다는 것은 Temporary 라이선스가 아니라는 의미입니다.
같은 게이팅은 클라이언트 측에서도 나타납니다: Viewer.ReferenceScripts()와 ReferenceCss()는 라이선스가 활성화된 경우에만 (search, annotation, …)와 같은 라이선스 게이팅 기능을 위한 스크립트/스타일 번들을 출력합니다, 따라서 위젯 UI는 서버가 실제로 수행하는 내용과 일치합니다.
기능 및 플러그인 맵
제품 UI는 “플러그인”을 광범위한 기능 레이블로 사용하지만, 서버 등록은 다릅니다:
| 기능 | 활성화 방법 | 기능 | 기여 내용 |
|---|---|---|---|
| Annotation | 뷰어에 내장; 주석 리소스 포함 | Annotation | 브라우저 저작, 세션 지속성, 그리고 번인된 내보내기 |
| Search | 검색 가능한 포맷 뷰어에 내장; 검색 리소스를 포함하고 필요 시 추출 활성화 | Search | 네이티브 텍스트 인덱스, 하이라이트, 결과 탐색 |
| Converter | Doconut.NET6.Converter 설치 및 ConverterPlugin 등록 | Converter | C# 변환 서비스 및 선택적 웹 위젯 |
| DICOM | Doconut.NET6.Dicom 설치 및 DicomPlugin 등록 | Dicom | .dcm 및 .ima에 대한 의료 이미지 뷰잉 |
Annotation과 일반 Search는 AddPlugin<TPlugin>()를 사용하지 않으며, 해당 번들은 라이선스가 해당 기능을 부여할 때만 출력됩니다. Converter와 DICOM은 이 문서 세트에 대한 출시된 선택형 IDoconutPlugin 구현입니다.
승인된 .NET 6 아티팩트에는 코어 패키지와 동일한 버전의 Doconut.NET6.Converter와 Doconut.NET6.Dicom이 포함되어 있습니다.
출시된 플러그인 패키지
| 플러그인 | 패키지 | 기능 | 기여 내용 |
|---|---|---|---|
| Converter | Doconut.NET6.Converter | Converter | 문서 변환 기능 |
| DICOM | Doconut.NET6.Dicom | Dicom | 의료 이미지 뷰잉 (.dcm — 플러그인 전용 포맷) |
각각은 Plugins 아래 전용 페이지를 가지고 있으며, 구성 및 사용법을 제공합니다.
사용자 정의 뷰어 — 자체 포맷 핸들러
플러그인 패키지를 작성하지 않고도 Program.cs에서 바로 뷰어를 파이프라인에 연결할 수 있습니다:
builder.Services.AddDoconut(options =>
{
options.RegisterViewer(
".myext",
() => new MyCustomViewer(), // implements IFormatViewer
() => new ImageConfig { ImageResolution = 150 }); // optional default config
});사용자 정의 뷰어는 모든 것 — 내장 및 플러그인 모두 — 보다 우선순위를 가지며 라이선스 게이팅을 받지 않습니다(사용자 코드이기 때문). 기본 구성을 제공하지 않으면 팩토리는 ImageConfig로 대체합니다.
핵심 요점
- 플러그인은 명시적으로 등록되며,
AddDoconut()중에LicenseCapability가 검증됩니다 — 누락되었거나 일시적이 아닌 권한이 부족하면 즉시 실패합니다. - 오버라이드 스타일 플러그인은 우아하게 감소하고; 플러그인 전용 포맷은
LicenseException으로 실패합니다. - 활성화된 Temporary 라이선스는 모든 것을 해제하고, 프로덕션에서는 구매한 기능만 해제됩니다. 배포 전에
IDoconutLicenseService로 확인하십시오.
이 페이지가 도움이 되었나요?