# Auditoria de refactorizacion de `TDesigner.js`

## Resumen

- Fichero auditado: `public/js/TDesigner.js`
- Lineas actuales: 3138
- Clase principal actual: `TDesigner`
- Metodos detectados dentro de `TDesigner`: 171
- Funciones globales detectadas: 0
- Variables globales detectadas: 1 referencia global intencionada, `window.oDesigner`
- Arranque global detectado: `document.addEventListener('DOMContentLoaded', ...)`

`TDesigner.js` ya esta orientado a objetos, pero concentra demasiadas responsabilidades en una sola clase. La refactorizacion recomendada no debe convertir el codigo en funciones sueltas, sino extraer clases con ciclo de vida propio y fachada controlada desde `TDesigner`.

## Estado Actual

La clase `TDesigner` contiene actualmente:

- inicializacion del documento;
- referencias DOM del area de diseno, propiedades, menus, modales y barra superior;
- carga y guardado de plantillas;
- render del papel, reglas, cuadricula, seleccion y JSON;
- gestion de objetos;
- historial;
- panel de propiedades;
- editor de formulas;
- validacion de expresiones;
- eventos globales de teclado y raton;
- menus contextuales;
- conversion de unidades y utilidades de formato.

El principal riesgo no es la existencia de una clase, sino que `TDesigner` se ha convertido en una clase orquestadora y ejecutora a la vez.

## Funciones Globales Detectadas

No hay funciones globales declaradas con `function`.

Solo existe el arranque:

```js
document.addEventListener('DOMContentLoaded', () => {
    window.oDesigner = new TDesigner().init().create();
});
```

Esta parte puede mantenerse durante la transicion.

## Variables Globales Detectadas

No hay variables globales de estado detectadas fuera de la clase.

La unica exposicion global relevante es:

```js
window.oDesigner
```

Se recomienda mantenerla temporalmente por compatibilidad con depuracion manual y posibles referencias existentes, pero hacer que apunte a la clase orquestadora `TDesigner`.

## Clases Propuestas

La propuesta de nombres es coherente con el proyecto. Todas las clases empiezan por `T` y cada fichero puede contener una clase principal con el mismo nombre.

Estado actual de preparacion: el esqueleto de clases ya existe en `public/js/` y `TDesigner` ya las instancia. La clase principal vive en `TDesigner.js`; las clases extraidas mantienen la referencia a `oDesigner` y el ciclo `new() / init() / create() / end()`.

| Fichero | Clase | Recomendacion |
| --- | --- | --- |
| `TDesigner.js` | `TDesigner` | Mantener como orquestador principal. |
| `TDesignerDocumento.js` | `TDesignerDocumento` | Sustituye a `TDesignerNucleo`; representa el estado del diseñador sin logica de interfaz. |
| `TDesignerAreaDibujo.js` | `TDesignerAreaDibujo` | Correcta, sera una extraccion de riesgo medio-alto. |
| `TDesignerBarraMenu.js` | `TDesignerBarraMenu` | Correcta, buena extraccion tras formulas y ficheros. |
| `TDesignerPanelProps.js` | `TDesignerPanelProps` | Correcta, riesgo medio por historial, formulas y multiseleccion. |
| `TDesignerFormulas.js` | `TDesignerFormulas` | Correcta, segunda extraccion recomendada tras estabilizar el estado. |
| `TDesignerGestionFicheros.js` | `TDesignerGestionFicheros` | Correcta, separa servidor/export/local legacy. |
| `TDesignerStorage.js` | `TDesignerStorage` | Correcta, pero debe limitarse a autoguardado/localStorage. |
| `TDesignerObjetos.js` | `TDesignerObjetos` | Correcta, aunque debe coordinarse con `TDocument` para no duplicar modelo. |
| `TDesignerHistorial.js` | `TDesignerHistorial` | Correcta, separa snapshots, undo y redo. |
| `TDesignerEventos.js` | `TDesignerEventos` | Correcta, centraliza captura de eventos del navegador y delega. |

### Decision sobre `TDesignerNucleo`

Se elimina la clase propuesta `TDesignerNucleo`.

Motivo: el nombre "Nucleo" no expresa una responsabilidad concreta y tiende a convertirse en un cajon de sastre. La arquitectura debe evitar clases que acumulen codigo residual.

La responsabilidad de estado pasa a:

```text
TDesignerDocumento
```

Esta clase representa el estado compartido del diseñador. No debe renderizar, no debe crear UI y no debe contener logica de edicion.

## Clases Nuevas Recomendadas

Ademas de las propuestas, conviene valorar estas clases si la refactorizacion avanza:

| Clase | Motivo |
| --- | --- |
| `TDesignerReglas` | Reglas, scroll y posicion de raton pueden aislarse si `TDesignerAreaDibujo` crece demasiado. |
| `TDesignerMenuContextual` | Menu contextual, posicion de pegado y acciones de contexto pueden separarse sin tocar el area completa. |
| `TDesignerJSONPanel` | `renderJSON` y `toggleJSON` son pequenos, pero pueden salir junto con barra/menu. |
| `TDesignerEstado` | Barra de estado y mensajes visibles pueden separarse si no encajan en `TDesignerDocumento`. |

## Agrupacion de Metodos por Clase

### `TDesigner`

Debe quedar como fachada y orquestador. Mantendria:

- `constructor`
- `init`
- `create`
- `end`
- `new`
- `bindEvents`, solo como delegador o coordinador temporal
- metodos fachada de compatibilidad durante la transicion

Ejemplos de fachadas temporales:

```js
seleccionarObjeto(...) { return this.oAreaDibujo.seleccionarObjeto(...); }
marcarModificado(...) { return this.oDocumento.marcarModificado(...); }
openFormulaEditor(...) { return this.oFormulas.openFormulaEditor(...); }
```

### `TDesignerDocumento`

Estado compartido del diseñador:

- documento actual;
- objeto seleccionado;
- lista de objetos seleccionados;
- documento modificado;
- nombre del fichero;
- zoom;
- unidad;
- configuracion general del documento;
- estado compartido entre clases.

Metodos y datos candidatos:

- `markDocumentDirty`
- `updateFileStatus`
- `confirmDiscardUnsavedChanges`
- `handleBeforeUnload`
- parte de `updateStatus`
- referencias comunes a `oDocument`
- coordinacion con `TDocument`

No debe contener:

- logica de interfaz;
- logica de render;
- logica de edicion;
- captura de eventos del navegador;
- llamadas AJAX.

Debe representar el estado del diseñador y ofrecer un contrato claro al resto de clases.

### `TDesignerGestionFicheros`

Carga, guardado y exportacion:

- `newTemplate`
- `openTemplateLocalLegacy`
- `handleFallbackOpenFileLocalLegacy`
- `loadTemplateFileLocalLegacy`
- `validateTemplateData`
- `saveTemplateLocalLegacy`
- `saveTemplateAsLocalLegacy`
- `writeTemplateToHandleLocalLegacy`
- `downloadTemplateLocalLegacy`
- `getTemplateFileContentLocalLegacy`
- `getSuggestedFileName`
- `ensureTemplateExtension`
- `getTemplateNameFromFileName`
- `openTemplate`
- `showOpenTemplateModal`
- `loadTemplateFromServer`
- `saveTemplate`
- `saveTemplateAs`
- `saveTemplateToServer`
- `exportTemplate`
- `getTemplateData`
- `requestJSON`
- `postJSON`
- `showFileError`

Riesgo: estos metodos modifican directamente `oDocument.cFileName`, `cCurrentFileName`, `cTemplateName`, `tModifiedAt`, `lDirty` y estado de guardado. La clase debe recibir `oDesigner` o `TDesignerDocumento` como dependencia.

### `TDesignerObjetos`

Operaciones sobre objetos:

- `addRectangle`
- `addText`
- `setCurrentTool`
- `copySelected`
- `pasteClipboard`
- `pasteClipboardAtContextPosition`
- `deleteSelected`
- `handleToolbarAction`, solo si la accion es de objeto/capa/alineacion
- operaciones de crear, duplicar, normalizar y borrar si se amplian

Riesgo: muchas operaciones ya viven en `TDocument`. Esta clase no debe duplicar reglas del documento; debe coordinar acciones de UI y llamar a `TDocument`.

### `TDesignerBarraMenu`

Botones superiores y acciones de barra:

- parte de `bindEvents` relacionada con botones superiores;
- `zoomIn`
- `zoomOut`
- `nextZoomLevel`
- `setZoom`
- `fitPage`
- `toggleGrid`
- `updateUndoRedoButtons`
- `updateToolbarButtons`
- acciones de menu que llamen a ficheros, objetos o area.

Puede ser una capa de UI que delega en `TDesignerGestionFicheros`, `TDesignerAreaDibujo`, `TDesignerObjetos` y `TDesignerHistorial`.

No debe capturar directamente eventos globales del navegador. Esa responsabilidad pasa a `TDesignerEventos`.

### `TDesignerEventos`

Captura eventos del navegador y delega en la clase responsable:

- `mousedown`
- `mousemove`
- `mouseup`
- `keydown`
- `keyup`
- `resize`
- `scroll`
- `wheel`
- eventos de cierre o perdida de foco si aplican.

Responsabilidad unica:

- registrar listeners;
- normalizar el evento si hace falta;
- decidir a que clase delegar;
- no ejecutar logica de negocio.

Delegaciones esperadas:

- a `TDesignerAreaDibujo` para raton, seleccion, arrastre, resize, reglas y scroll del area;
- a `TDesignerPanelProps` para eventos del panel de propiedades;
- a `TDesignerFormulas` para eventos del modal de formulas;
- a `TDesignerBarraMenu` para botones y acciones principales;
- a `TDesignerGestionFicheros` para eventos de abrir/guardar si proceden.

Justificacion: `TDesigner.js` tenia mucha captura de eventos dentro de `bindEvents`. Separar la captura de la ejecucion evita que `TDesigner` vuelva a crecer y permite probar las responsabilidades de forma aislada.

### `TDesignerAreaDibujo`

Area visual, render, seleccion, arrastre y reglas:

- `render`
- `createGroupSelectionBox`
- `createRubberBand`
- `hideGroupSelectionBox`
- `renderGroupSelectionBox`
- `refreshGroupSelectionBox`
- `getDocumentPoint`
- `getRubberSelectionBounds`
- `updateDesignSurfaceSize`
- `renderGrid`
- `renderRulers`
- `syncRulersScroll`
- `updateRulerMousePosition`
- `hideRulerMousePosition`
- `showContextMenu`
- `hideContextMenu`
- `handleDesignAreaContextMenu`
- `saveContextMenuPosition`
- `handleContextMenuClick`, si se crea `TDesignerMenuContextual` podria salir de aqui
- `handleDocumentMouseDown`
- `handlePaperMouseDown`
- `handleDesignDoubleClick`
- `beginTextEdit`
- `endTextEdit`
- `isInterfaceControl`
- `startRubberSelection`
- `updateRubberSelection`
- `updateRubberBand`
- `hideRubberBand`
- `endRubberSelection`
- `objectIntersectsBounds`
- `startGroupDrag`
- `startResize`
- `startGroupResize`
- `resizeObject`
- `resizeGroup`
- `endResize`
- `endGroupResize`
- `handleDocumentMouseMove`
- `dragGroup`
- `handleDocumentMouseUp`
- `handleKeyDown`, si no se extrae un gestor de atajos

Riesgo alto: estos metodos comparten estado mutable (`hDrag`, `hGroupDrag`, `hGroupResize`, `lResizing`, `oResizeObject`, coordenadas de raton, seleccion, historial y panel de propiedades).

En la arquitectura final, los metodos tipo `handle...` no deberian registrar listeners por si mismos. `TDesignerEventos` capturara el evento del navegador y llamara a metodos publicos de `TDesignerAreaDibujo`.

### `TDesignerPanelProps`

Panel de propiedades:

- `renderProperties`
- `renderPropertyPanel`
- `createFormulaValidationButton`
- `createFormulaEditorButton`
- `refreshPropertyValues`
- `getPropertyObjects`
- `getCommonProperties`
- `getCommonPropertyValue`
- `refreshEditorMixedState`
- `getPropertyValue`
- `getPropertyColorDisplayValue`
- `createPropertyEditor`
- `createBorderVisibilityEditor`
- `refreshBorderVisibilityEditor`
- `handlePropertyFocus`
- `handlePropertyPanelClick`
- `validatePropertyExpression`
- `handlePropertyInput`
- `handlePropertyBlur`
- `getPropertyDefinition`
- `applyPropertyValue`
- `parseNumberInput`
- `normalizeColorValue`
- `normalizeTextColorValue`

Riesgo medio: el panel dispara historial, refresco del documento, JSON, formulas de color y actualizacion de estado. Debe recibir dependencias claras: `oDocument`, `oFormulas`, `oHistorial`, `oAreaDibujo`.

### `TDesignerFormulas`

Editor de formulas:

- `loadFormulaCatalog`
- `loadFormulaVariables`
- `openFormulaEditor`
- `renderFormulaFunctionList`
- `renderFormulaVariableList`
- `renderFormulaConstantList`
- `renderFormulaFunctionDetail`
- `renderFormulaConstantDetail`
- `renderFormulaDetailRow`
- `handleFormulaFunctionClick`
- `handleFormulaFunctionDoubleClick`
- `handleFormulaVariableClick`
- `handleFormulaVariableDoubleClick`
- `handleFormulaConstantClick`
- `handleFormulaConstantDoubleClick`
- `refreshFormulaFunctionSelection`
- `refreshFormulaVariableSelection`
- `refreshFormulaConstantSelection`
- `insertSelectedFormulaFunction`
- `insertSelectedFormulaVariable`
- `insertSelectedFormulaConstant`
- `insertTextInFormulaEditor`
- `scheduleFormulaEditorValidation`
- `validateFormulaEditor`
- `acceptFormulaEditor`
- `validateFormulaWithMotor`
- `updateFormulaDesignPreview`
- `refreshDesignColorFormulaPreviews`
- `validateFormulaSyntax`
- `formulaLooksLikeColor`
- `getFormulaBalance`
- `getFormulaFunctionCalls`
- `getFormulaVariableReferences`
- `getFormulaMissingOperatorWarnings`
- `stripFormulaStrings`
- `formulaVariableExists`
- `isFormulaReservedWord`
- `isFormulaIdentifierChar`
- `needsFormulaConcatBefore`
- `needsFormulaConcatAfter`
- `normalizeFormulaFunctionName`
- `escapeHtml`, si no se mueve a utilidades comunes

Esta es la segunda extraccion recomendada tras `TDesignerDocumento`, porque tiene un bloque muy definido y ya dispone de selectores `data-testid` en varias listas.

### `TDesignerHistorial`

Aunque no estaba en la propuesta inicial, conviene extraer:

- `saveHistory`
- `beginHistoryChange`
- `commitHistoryChange`
- `removeLastHistoryIfUnchanged`
- `undo`
- `redo`

Riesgo medio: el historial depende de `TDocument`, de acciones de propiedades, colores, movimiento, redimensionado y toolbar.

### `TDesignerJSONPanel`

Opcional:

- `renderJSON`
- `toggleJSON`

Puede quedar en `TDesignerBarraMenu` al principio para no crear demasiadas clases pequeñas.

## Funciones que No Encajan Claramente

| Metodo | Motivo | Propuesta |
| --- | --- | --- |
| `handleKeyDown` | Mezcla atajos de documento, objetos, historial y edicion. | Captura en `TDesignerEventos`, delegacion inicial a `TDesignerAreaDibujo`; posible `TDesignerAtajos` despues. |
| `updateStatus` | Mezcla estado de fichero, seleccion, documento y coordenadas. | `TDesignerDocumento` para estado y posible `TDesignerEstado` para UI visible. |
| `escapeHtml` | Utilidad transversal usada por formulas y posiblemente otros paneles. | Helper estatico pequeno o metodo utilitario de `TDesigner`. |
| `handleToolbarAction` | Puede llamar a acciones de capas/alineacion en `TDocument`. | `TDesignerBarraMenu`, delegando en `TDesignerObjetos`. |
| `showContextMenu` y familia | Afectan al area, pero tambien a copiar/pegar. | `TDesignerAreaDibujo`; posible `TDesignerMenuContextual`. |

## Dependencias Peligrosas

1. `TDesigner` accede directamente a muchas propiedades de `TDocument`.
   - Ejemplos: `aObjects`, `aSelectedObjects`, `oSelectedObject`, `aUndoStack`, `aRedoStack`, `nZoom`, `lFitPage`, `lDirty`, `cFileName`.
   - Riesgo: al mover metodos, varias clases podrian empezar a mutar el documento sin contrato claro.

2. El panel de propiedades mezcla UI, modelo, historial y render.
   - `handlePropertyInput` cambia valores, limpia formulas de color, refresca documento, refresca panel, renderiza JSON y confirma historial.
   - Riesgo: facil romper foco, undo/redo o multiseleccion.

3. El editor de formulas depende de datos externos y del panel de propiedades.
   - Carga `lenguaje_dominus.json`, `datos_prueba.json` y llama a `validar_formula.php`.
   - Tambien actualiza propiedades del objeto seleccionado.
   - Riesgo: al extraerlo debe devolver una expresion o recibir callbacks, no modificar todo de forma opaca.

4. Area de dibujo, seleccion y redimensionado comparten estado temporal.
   - `hDrag`, `hGroupDrag`, `hGroupResize`, `lResizing`, `cResizeHandle`, `nStartMouseX`, `nStartMouseY`.
   - Riesgo: extraer parcialmente puede romper mouseup/mousemove globales.

5. Guardado/exportacion modifica temporalmente metadatos del documento.
   - `exportTemplate` preserva y restaura nombre/fichero.
   - Riesgo: una extraccion descuidada puede marcar como guardado lo que solo se exporto.

6. Historial se dispara desde muchos sitios.
   - Propiedades, formulas, colores, mover, redimensionar, toolbar, crear y borrar.
   - Riesgo: duplicar snapshots o perder undo/redo.

## Orden Recomendado de Migracion

1. **Extraer `TDesignerDocumento`.**
   - Estabilizar el estado compartido del diseñador.
   - Evitar que las siguientes clases dependan directamente de demasiadas propiedades de `TDesigner`.
   - No mover logica de interfaz ni render.

2. **Extraer `TDesignerFormulas`.**
   - Bloque mas cohesionado.
   - Tiene UI propia: modal de formulas.
   - Tests Playwright existentes o faciles de crear: abrir modal, doble clic, insertar, validar.

3. **Extraer `TDesignerGestionFicheros`.**
   - Metodos bastante agrupados.
   - Proteger con pruebas: abrir plantilla, guardar, guardar como, exportar.

4. **Extraer `TDesignerBarraMenu`.**
   - Primero solo acciones de barra y delegacion.
   - Luego acciones de zoom/cuadricula si siguen siendo simples.

5. **Extraer `TDesignerHistorial`.**
   - Despues de tener ficheros/formulas estables.
   - Proteger undo/redo con propiedades, colores y movimiento.

6. **Extraer `TDesignerPanelProps`.**
   - Riesgo medio por foco, multiseleccion y formulas.
   - Conviene hacerlo con pruebas Playwright especificas.

7. **Extraer `TDesignerAreaDibujo`.**
   - Ultima extraccion grande.
   - Dividir internamente si hace falta en reglas, seleccion, drag/resize y menu contextual.

8. **Extraer `TDesignerObjetos`.**
   - Puede hacerse antes o despues de area segun se quiera separar toolbar de acciones.
   - No debe duplicar comportamiento de `TDocument`.

9. **Valorar `TDesignerStorage`.**
   - La responsabilidad de autosave/localStorage debe permanecer aislada de `TDesigner.js`.
   - Crear esta clase solo cuando se implemente o localice esa responsabilidad.

10. **Extraer `TDesignerEventos`.**
    - Centralizar listeners cuando las clases responsables ya existan.
    - Delegar eventos a clases ya extraidas.
    - Evitar que `TDesignerEventos` contenga logica de negocio.

## Primera Clase a Extraer con Menor Riesgo

La primera clase recomendada es:

```text
TDesignerDocumento.js
```

Motivos:

- estabiliza el estado compartido antes de extraer UI;
- evita que las clases nuevas dependan directamente de todas las propiedades internas de `TDesigner`;
- no requiere mover todavia render, eventos de raton ni panel de propiedades completo;
- crea un contrato claro para documento actual, seleccion, zoom, fichero y estado de modificado;
- reduce el riesgo de que las siguientes extracciones creen dependencias cruzadas.

Contrato inicial sugerido:

```js
this.oDocumento = new TDesignerDocumento().init(this).create();
```

`TDesignerDocumento` puede recibir el `oDesigner` al inicio para adaptarse al estado actual sin mover toda la logica de golpe.

Debe exponer de forma controlada:

- documento actual;
- seleccion actual;
- estado de fichero;
- zoom;
- estado de modificado;
- unidad y configuracion general.

En una segunda pasada se podran sustituir dependencias directas por interfaces mas pequenas.

## Tests Playwright Recomendados

Antes de mover cada bloque, conviene tener al menos estas pruebas:

1. **Arranque del diseñador**
   - Abre `public/index.php`.
   - Comprueba que aparece el papel.
   - Comprueba que no hay errores de consola.

2. **Cargar plantilla**
   - Abre modal de plantillas.
   - Carga `prueba_texto.lbl` o una plantilla conocida.
   - Comprueba que hay objetos visibles.

3. **Seleccion de objetos**
   - Selecciona un `TText`.
   - Selecciona un `TRectangle`.
   - Comprueba que el panel cambia.

4. **Panel de propiedades**
   - Cambia `Izquierda`, `Superior`, `Ancho`, `Alto`.
   - Comprueba que no se pierde foco al escribir.
   - Comprueba que `Derecha` e `Inferior` se actualizan.

5. **Editor de formulas**
   - Abre con `ƒx`.
   - Doble clic en funcion `Max`.
   - Doble clic en variable `CLIENTE`.
   - Doble clic en constante `CRLF`.
   - Valida expresion correcta.
   - Valida variable inexistente.
   - Acepta y comprueba que se guarda en la propiedad.

6. **Colores con formula**
   - Edita una formula de color.
   - Comprueba que cambia la previsualizacion de diseno.
   - Comprueba undo/redo del cambio.

7. **Guardar y recargar**
   - Guarda plantilla.
   - Recarga.
   - Comprueba que propiedades y formulas permanecen.

8. **Undo/redo**
   - Mueve objeto.
   - Cambia propiedad.
   - Cambia color.
   - Deshace y rehace cada caso.

9. **Multiseleccion**
   - Ctrl/clic o marco de seleccion.
   - Mueve grupo.
   - Alinea o distribuye.
   - Comprueba propiedades comunes.

10. **Redimensionado**
    - Arrastra manejador de un objeto.
    - Arrastra manejador de grupo.
    - Comprueba cambio de dimensiones.

## Recomendacion de Carga JS desde HTML

Para una migracion incremental sin bundler:

1. Cargar primero clases base ya existentes:

```html
<script src="js/TObjectBase.js"></script>
<script src="js/TRectangle.js"></script>
<script src="js/TText.js"></script>
<script src="js/TDocument.js"></script>
```

2. Cargar despues las nuevas clases de diseñador:

```html
<script src="js/TDesignerDocumento.js"></script>
<script src="js/TDesignerFormulas.js"></script>
<script src="js/TDesignerGestionFicheros.js"></script>
<script src="js/TDesignerBarraMenu.js"></script>
<script src="js/TDesignerHistorial.js"></script>
<script src="js/TDesignerPanelProps.js"></script>
<script src="js/TDesignerAreaDibujo.js"></script>
<script src="js/TDesignerObjetos.js"></script>
<script src="js/TDesignerStorage.js"></script>
<script src="js/TDesignerEventos.js"></script>
```

3. Cargar `TDesigner.js` al final:

```html
<script src="js/TDesigner.js"></script>
```

4. `public/js/TDesigner.js` es el fichero principal de arranque del diseñador.

No se recomienda introducir modulos ES en esta fase si el proyecto sigue cargando scripts clasicos. El cambio a `type="module"` seria otra refactorizacion con riesgos propios.

## Reglas para la Refactorizacion Futura

- Mover una clase cada vez.
- Mantener fachadas en `TDesigner` mientras haya referencias antiguas.
- No cambiar nombres publicos durante la extraccion.
- No mezclar refactorizacion con nuevas funciones.
- Ejecutar Playwright despues de cada extraccion.
- Evitar que dos clases escriban la misma propiedad de estado sin pasar por una fachada clara.
- No duplicar logica de `TDocument`.

## Estado del Esqueleto

Ya existen los ficheros:

- `public/js/TDesignerDocumento.js`
- `public/js/TDesignerEventos.js`
- `public/js/TDesignerFormulas.js`
- `public/js/TDesignerGestionFicheros.js`
- `public/js/TDesignerBarraMenu.js`
- `public/js/TDesignerHistorial.js`
- `public/js/TDesignerPanelProps.js`
- `public/js/TDesignerAreaDibujo.js`
- `public/js/TDesignerObjetos.js`
- `public/js/TDesignerStorage.js`

`public/index.php` carga estos scripts antes de `public/js/TDesigner.js`.

`TDesigner` crea estas referencias:

- `oDocumento`
- `oEventos`
- `oFormulas`
- `oGestionFicheros`
- `oBarraMenu`
- `oHistorial`
- `oPanelProps`
- `oAreaDibujo`
- `oObjetos`
- `oStorage`

Importante: esta fase no mueve metodos ni cambia responsabilidades en tiempo de ejecucion. Solo prepara puntos de anclaje para extraer una clase cada vez.

## Conclusion

La division propuesta es viable y los nombres son coherentes con LL-Dominus. La secuencia mas segura es empezar por `TDesignerDocumento`, continuar por `TDesignerFormulas`, seguir por ficheros/barra y dejar `TDesignerAreaDibujo` para una fase posterior.

La refactorizacion debe ser progresiva. El objetivo no es crear muchos ficheros rapidamente, sino reducir responsabilidades sin romper el diseñador visual.