20250626

¿Cuál es el rol principal del método `fetchProperties` en un `TableDelegate` para una `mdc:Table`?

• Aplicar los filtros seleccionados por el usuario en la barra de filtros.

• Suministrar los metadatos (el "plano") de todas las propiedades disponibles a la tabla, habilitando así la personalización (P13n).

• Obtener la ruta de binding de los datos desde el `payload` definido en la vista XML.

• Renderizar las filas con los datos del modelo.

En un `JSONTableDelegate`, ¿cuál es el propósito de la línea `bindingInfo.path = table.getPayload().bindingPath;` dentro del método `updateBindingInfo`?

• Para definir las columnas que serán visibles en la tabla.

• Para mejorar el rendimiento de la tabla activando el `templateShareable`.

• Para cargar manualmente los datos del fichero JSON en la tabla.

• Para conectar de forma reutilizable al delegado con la ruta de datos específica de la tabla, definida en la vista XML.

¿Por qué es crítico mantener los metadatos devueltos por `fetchProperties` "estables durante todo el ciclo de vida" de la `mdc:Table`?

• Porque el `JSONFilterBarDelegate` necesita una copia exacta de los mismos metadatos para funcionar.

• Para garantizar que las personalizaciones del usuario (como orden, visibilidad de columnas, filtros) no se pierdan, ya que se guardan asociadas a las `propertyKey` de los metadatos.

• Porque cambiar los metadatos puede causar errores de renderizado en la tabla.

• Para asegurar que los datos en el `JSONModel` no se modifiquen accidentalmente.

¿Qué es el fichero `JSONPropertyInfo.ts` al usar un `JSONModel` con `mdc`, y por qué es necesario?

• Es el delegado (`delegate`) que se encarga de la lógica de filtrado y ordenamiento de la tabla.

• Es una caché de los datos del `JSONModel` para un acceso más rápido.

• Es un fichero de configuración de UI5 para habilitar los controles MDC en la aplicación.

• Es un 'plano' o 'contrato de metadatos' creado manualmente que describe las propiedades de los datos, porque, a diferencia de OData, un `JSONModel` no tiene metadatos automáticos.

¿Cuál es el propósito del binding `conditions="{$filters>/conditions/name}"` en un `mdc:FilterField`?

• Carga los valores posibles para el campo de filtro desde un modelo llamado `$filters`.

• Aplica directamente un filtro sobre la columna 'name' de la `mdc:Table`.

• Define una condición de filtro por defecto con el valor 'name'.

• Crea un enlace bidireccional entre el `FilterField` y el modelo de estado interno (`$filters`) de la `mdc:FilterBar`, centralizando las condiciones de filtro.

Un `mdc:ValueHelp` puede tener un `<mdc:typeahead>` (con `<vh:Popover>`) y un `<mdc:dialog>`. ¿Cuál es la diferencia funcional?

• No hay diferencia, son dos formas de definir el mismo diálogo de ayuda de valores.

• El `typeahead`/`Popover` es para selección única y el `dialog` es para selección múltiple.

• El `typeahead`/`Popover` muestra sugerencias rápidas mientras se escribe, y el `dialog` abre una ventana de búsqueda avanzada y completa al presionar F4 o hacer clic en el icono de ayuda.

• El `typeahead`/`Popover` solo funciona con `JSONModel` y el `dialog` solo con OData.