Sistema de Plugins

El núcleo de Doconut se mantiene ligero; la funcionalidad opcional se entrega como plugins — paquetes NuGet separados que aportan visores o servicios y se activan mediante su licencia. Esta página explica el modelo de registro, lo que ocurre al iniciar cuando una licencia no cubre un plugin, y cómo conectar su propio visor.

Registro de un plugin

Cada paquete de plugin expone una clase de plugin. Regístrelo una vez, en Application_Start:

Doconut.DoconutHost.Initialize(options =>
{
    options.AddPlugin<Doconut.Plugins.Converter.ConverterPlugin>();
    options.AddPlugin<Doconut.Plugins.Dicom.DicomPlugin>();
});
// Un complemento registrado cuya licencia falta lanza aquí, en Application_Start, y el
// el sitio luego responde a cada solicitud con un 500 vacío. La razón está en el registro de eventos de Windows.

AddPlugin<TPlugin>() crea el plugin y le permite registrar sus contribuciones con DoconutOptions. Todo lo que un plugin aporta está etiquetado con la capacidad requerida del plugin, y DoconutHost.Initialize verifica cada plugin registrado contra la licencia antes de que el sitio sirva su primera solicitud.

Una licencia de plugin faltante detiene el sitio

Cuando ninguna licencia activa otorga la capacidad de un plugin registrado — ninguna licencia en absoluto, un archivo legado TRIAL, o una licencia de pago sin esa capacidad — DoconutHost.Initialize lanza InvalidOperationException desde Application_Start:

The Converter plugin is registered via AddPlugin but no active license grants Converter.
Remove the AddPlugin<...>() call or install a license (or trial/demo) that includes Converter.

En System.Web, una excepción en Application_Start no produce una página de error. Cada solicitud responde con un 500 vacío, el registro de IIS no muestra nada útil, y el mensaje aparece solo en el registro de eventos de Windows (registro de Aplicación, origen ASP.NET). Cuando un sitio deja de responder justo después de añadir una línea AddPlugin, revise primero los archivos de licencia en wwwroot — vea Configuración de Licencia.

El contrato

Un plugin implementa una interfaz deliberadamente pequeña:

public interface IDoconutPlugin
{
    string Name { get; }                          // p. ej. "Doconut DICOM Viewer"
    LicenseCapability RequiredCapability { get; } // la puerta de licencia
    void Register(IDoconutPluginBuilder builder); // contribuir visores/servicios
}

Dentro de Register, el constructor acepta dos tipos de contribución:

• builder.RegisterViewer(".dcm", () => new DicomViewer()) — un visor para una extensión de archivo,
• builder.RegisterService<TContract>(() => …) — un servicio tipado que otras partes del pipeline pueden buscar.

Capacidades y restricciones

Las capacidades son las unidades de licencia. Converter y Dicom se entregan como plugins opcionales; Search y Annotation son funciones integradas restringidas de la misma manera. El visor base no es una capacidad — es el prerrequisito, expuesto como IsViewerLicensed en el servicio de licencias.

La validación al iniciar normalmente mantiene un plugin sin licencia fuera del pipeline de solicitudes. La fábrica de visores también aplica dos reglas defensivas, que importan si los derechos cambian mientras el sitio está en ejecución:

• Un plugin que sobrescribe un visor integrado (reclama una extensión que también maneja un visor integrado): con la capacidad licenciada, el visor del plugin gana; sin ella, Doconut recurre al visor integrado. Los usuarios siguen viendo su documento; simplemente no obtienen el comportamiento del plugin.
• Un formato solo de plugin (.dcm y .ima — DICOM no tiene visor integrado): sin la capacidad, la apertura falla:

LicenseException: This document type requires the 'Dicom' plugin license.

Una licencia Temporal activa otorga todas las capacidades. Eso es una sorpresa clásica al lanzar: las mismas líneas AddPlugin que se ejecutaron durante la evaluación detienen el sitio cuando la licencia comprada omite una de esas capacidades. Compare IsCapabilityGranted(...) con lo que adquirió antes de desplegar. Con ninguna licencia en absoluto, no se otorga nada — una licencia faltante no es una licencia Temporal.

La misma restricción llega al navegador: Viewer.ReferenceScripts() y ReferenceCss() emiten los archivos para funciones restringidas por licencia (Búsqueda, Anotación) solo cuando la licencia los concede, por lo que la página nunca ofrece una función que el servidor rechazará.

Mapa de características y plugins

Annotation y Search no utilizan AddPlugin<TPlugin>(). Converter y DICOM cada uno tienen una página bajo Plugins con su configuración y uso. En este paquete, DICOM renderiza páginas, marcos y animaciones, pero no lee metadatos técnicos — vea Plugin DICOM.

Visores personalizados — su propio manejador de formato

Puede conectar un visor al pipeline sin escribir un paquete de plugin, directamente en Application_Start:

Doconut.DoconutHost.Initialize(options =>
{
    options.RegisterViewer(
        ".myext",
        () => new MyCustomViewer(),                        // implementa IFormatViewer
        () => new ImageConfig { ImageResolution = 150 });  // configuración predeterminada opcional
});

Los visores personalizados tienen precedencia sobre todo — integrados y plugins por igual — y no están restringidos por licencia: son su código. Cuando no suministra una configuración predeterminada, la fábrica usa un ImageConfig.

Conclusiones

• Los plugins se registran explícitamente en DoconutHost.Initialize, y sus capacidades se validan allí; una falta de derecho detiene el sitio con un 500 vacío cuyo motivo está en el registro de eventos de Windows.
• Los plugins de estilo sobrescritura se degradan de forma elegante; los formatos solo de plugin fallan con un LicenseException.
• Una licencia Temporal activa desbloquea todo; la producción desbloquea lo que compró. Verifique con IDoconutLicenseService antes de lanzar.