5. Qué es ZK y cómo dibuja iDempiere su interfaz

ZK es el framework Java que dibuja toda la interfaz web de iDempiere (bundle org.adempiere.ui.zk, versión 10.3.0.1 en la instalación de referencia de FINORA, finora-erp-experience/idempiere/IDEMPIERE_UI_MAP.md, §0). Es un framework de componentes del lado del servidor: quien escribe una pantalla trabaja con objetos Java (Window, Grid, Textbox, Combobox) y ZK se encarga de traducir sus cambios a HTML/JavaScript y de enviar los eventos del navegador de vuelta al servidor por Ajax. No se escribe JavaScript a mano para que la interfaz reaccione — se escribe Java, igual que el resto del backend.

ZUL: la plantilla de una pantalla

Las pantallas fijas de iDempiere (login, escritorio, diálogos) se describen en archivos .zul, un XML declarativo de componentes ZK:

<!-- patrón de org.idempiere.zk.iceblue_c.theme, zul/login/login.zul -->
<borderlayout id="layout">
  <north><include src="login-top.zul"/></north>
  <center>
    <window use="org.adempiere.webui.window.LoginWindow" id="loginWindow"/>
  </center>
  <south><include src="login-bottom.zul"/></south>
</borderlayout>

Lo importante: el propio código Java del core espera encontrar ciertos id en ese XML (layout, loginWindow en este caso) para engancharse a ellos (finora-erp-experience/idempiere/EXTENSION_GUIDE.md, §3.7). Un tema visual puede reordenar, esconder o decorar libremente todo lo que no sea uno de esos contratos, pero no puede quitar los ids que el Java necesita.

Las ventanas de negocio no usan .zul a mano

Las ventanas de negocio (Business Partner, Sales Order, y cualquier ventana nueva definida en AD_Window) no tienen un archivo .zul propio: ZK las construye en tiempo de ejecución leyendo el Diccionario de Aplicación (ver Tutorial 3). Los .zul de este tutorial son para las pantallas “de sistema” (login, escritorio, diálogos), que sí son estáticas.

Cómo el Diccionario decide el editor de cada campo

Esta es la pieza que conecta este tutorial con el anterior: cuando ZK dibuja una pestaña, para cada AD_Field mira la AD_Reference de su AD_Column y elige el editor correspondiente —

AD_Reference	Editor en ZK
String, Text	Caja de texto
Integer, Amount, Quantity	Caja numérica con máscara
Date, DateTime	Selector de calendario
YesNo	Casilla de verificación
List	Combo con los valores de AD_Ref_List
Table / TableDir	Combo o buscador que consulta otra tabla (por ejemplo, elegir un Business Partner)
Search	Diálogo de búsqueda avanzada

Esto es lo que hace posible que agregar una columna nueva a una tabla existente — como C_BPartner.FVE_IVACondition, una Lista con los valores ordinario/formal/especial/no contribuyente — aparezca en la ventana con el editor correcto (un combo) sin escribir una sola línea de interfaz: la columna ya trae su AD_Reference declarado en el 2Pack que la crea.

Temas: cómo se ve, no cómo se comporta

La apariencia visual (colores, tipografía, logo) vive en un tema ZK, un fragmento OSGi del bundle org.adempiere.ui.zk que aporta hojas de estilo (css/theme.css.dsp, con un bloque :root de más de 180 variables CSS) e imágenes. iDempiere trae iceblue_c como tema por defecto desde la versión 12; FINORA construye su propio tema como otro fragmento (com.finora.erp.theme) que copia iceblue_c y solo reescribe ese bloque :root con los tokens de marca de FINORA, dejando el resto del CSS —y toda la lógica Java— intacto (finora-erp-experience/idempiere/EXTENSION_GUIDE.md, §1.4 y §3).

Un tema no cambia el comportamiento

Cambiar el tema (o incluso el CSS) no puede reordenar campos, esconder una pestaña completa ni agregar datos que ZK no está mostrando ya. Eso se resuelve con AD_UserDef_Win/Tab/Field (configura qué se ve, sin código) o con una extensión Java real —una fábrica IADTabPanelFactory, un IFormFactory— si hace falta una pantalla verdaderamente nueva (finora-erp-experience/idempiere/EXTENSION_GUIDE.md, §6 y §8).

Dónde entra com.finora.lve.ui

De los cinco bundles de FINORA LVE, solo uno depende de ZK: com.finora.lve.ui (diálogo “Imprimir documento fiscal”, paneles de retención). Todo lo demás — el cálculo de retenciones, el número de control, los libros — funciona igual de completo por REST sin necesitar ZK (finora-lve/docs/ARCHITECTURE.md, §2.1, razón de corte 3: “toda operación funciona por REST y por procesos de servidor; la interfaz ZK es una capa opcional”). Esta separación deliberada significa que un cliente puede instalar el motor fiscal completo sin instalar ningún componente ZK adicional, si va a operar solo por integración.

Grillas grandes: por qué no se cargan todas las filas de una vez

Una pantalla de negocio con miles de registros (un listado de facturas de todo un año, por ejemplo) no trae esas filas al navegador de una sola vez: la grilla de ZK que usa iDempiere pagina la consulta en el servidor (un ORDER BY + LIMIT/OFFSET sobre la tabla real) y solo materializa como componentes ZK las filas que la persona efectivamente está viendo o a punto de ver. Es lo mismo que resuelve la paginación de /api/v1/models/{tabla} con $top/$skip (ver Tutorial 10) — ambos caminos, ZK y REST, terminan apoyándose en el mismo mecanismo de acceso a datos del core, solo que uno lo dispara al hacer scroll y el otro por parámetro explícito.

Por verificar

El nombre exacto de la clase que implementa esta paginación del lado ZK (el equivalente a un LazyListModel) no está confirmado contra el código fuente en esta guía — el comportamiento observable (la grilla no se congela con tablas grandes) sí está verificado en instalaciones reales de FINORA. Si necesitas modificar el comportamiento de una grilla específica, revisa la clase concreta que arma esa ventana antes de asumir el mecanismo genérico.

Fuentes

• finora-erp-experience/idempiere/EXTENSION_GUIDE.md, §1, §3, §6 y §8 (ThemeManager, contrato de ids en ZUL, fábricas de extensión)
• finora-erp-experience/idempiere/IDEMPIERE_UI_MAP.md, §0 (versión de ZK instalada)
• finora-lve/docs/ARCHITECTURE.md, §2.1 (por qué solo com.finora.lve.ui depende de ZK)
• ZK Framework — sitio oficial