Todo es un Component

Esta es la idea que hace que el resto del framework “encaje”. En CrossFly no hay una jerarquía de “widgets” frente a “containers”. Existe un tipo base — Component — y cualquier Component se convierte en un container en el momento en que recibe un Layout.

container = Component + Layout

Component painel = new Component();       // un Component "vacío"
painel.setLayout(new VerticalLayout());   // ahora organiza los hijos → es un container
painel.add(LAY_AUTO, new Label("Título"));
painel.add(LAY_FILL, new ListView<>(...));

Un Button es un Component. Un Label es un Component. Una Window (pantalla) es un Component de pantalla completa. No existe una clase Container especial — la “capacidad de contener” es solo tener un Layout. Esto significa que compones pantallas de la misma manera, siempre, desde el botón hasta la app entera.

Por qué la clase base está diseñada así

Component necesita escalar a miles de instancias sin explotar la memoria. Dos decisiones clave:

• Bitfield (cbits) en vez de decenas de boolean. Estados como enabled, visible, focused, pressed, tiene layout, tiene estilo enfocado… son bits de un único entero long, no campos separados. Miles de componentes × decenas de flags booleanas sería un desperdicio; un bitfield lo resuelve con un solo campo.
• Mapa de propiedades lazy (property(k, v)). Las cosas opcionales (callbacks, skin custom, imagen de fondo, estilos alternativos) no son campos fijos — viven en un mapa creado bajo demanda. Un Label simple no paga por un campo de “imagen de fondo” que nunca va a usar.

// property(...) es el "saco de datos" idiomático para lo que es opcional:
comp.property("meuFlag", true);
boolean f = comp.property("meuFlag");   // recupera (nulo si nunca se seteó)

Los estilos siguen la misma filosofía: se crean bajo demanda a partir del Skin, no se instancian para todo componente de entrada.

Jerarquía de padre único

Todo Component tiene como máximo un padre. El árbol de composición es estrictamente jerárquico: añadir un componente a un container lo elimina de cualquier padre anterior. Esto mantiene el layout y la propagación de eventos predecibles (cada componente pertenece a exactamente un lugar).

Qué se deriva de esto

• Una forma de componer todo: aprender a montar un panel = saber montar una pantalla.
• Los layouts son enchufables: el mismo container cambia de disposición con solo cambiar el Layout (base de la responsividad — ver Layout y el modelo Relative).
• Bajo costo por componente: bitfield + propiedades lazy es lo que hace viables las listas grandes.

Ver también

• Aplicar: Layouts · Catálogo de componentes
• Siguiente: El pipeline de renderizado