docs: update specifications

[javier-godoy]

Spec Update Rationale

Changes applied to SPECIFICATIONS.md based on first-iteration implementation experience.

---

4.1 — getColumnConfig → getColumn; return type EasyColumn<T,V>

The original name getColumnConfig implies the method returns a configuration bag — a passive data holder separate from the column itself. In practice the returned object is the column: it wraps the underlying Grid.Column<T>, drives its renderer, and is the primary handle for all subsequent column work. Calling it a "config" understates its role and misleads callers about what they are holding.

getColumn is also the natural name by analogy with Grid.getColumnByKey, which callers already use when working with the plain Vaadin API. The rename makes the relationship obvious without any documentation overhead.

Renaming the return type from the implied EasyColumnConfig to EasyColumn<T,V> follows the same logic: the object models the column, not its configuration.

---

4.2 — Fluent method naming: with* → set*

with* is the established Java convention for immutable builders and records: each call returns a new object with one field changed, leaving the receiver unchanged. EasyColumn is not immutable — every method mutates the column in place and returns this for chaining. Using with* in this context would create a false expectation of copy-on-write semantics and surprise callers who assume the original reference is unmodified.

set* is the standard JavaBean convention for mutable setters, which is exactly what these methods are. It is also consistent with Grid.Column itself, so callers moving between the Vaadin API and the EasyGrid API encounter no naming discontinuity.

---

4.5 — Boolean default labels: "Yes"/"No" → "true"/"false"

"Yes" and "No" are natural-language words. They are English-specific and carry no formal relationship to the underlying Boolean type. A default that reads "Yes" will look wrong in any non-English application without explicit overrides, and it will surprise developers who expect the rendered value to reflect the data value.

"true" and "false" are the canonical string representation of Boolean in Java (Boolean.toString()). They are locale-neutral, unambiguous, and predictable — the default behavior matches what a plain toString() call would produce. Callers who want "Yes"/"No" (or any other labels) can configure them explicitly via setBooleanLabels("Yes", "No"), a call whose intent is self-documenting.

---

5.3 — EasyGrid(Grid<T>, Class<T>, boolean) constructor

The two constructors defined in the original spec handle the two most common construction patterns: auto-discover all properties, or specify a fixed ordered list. A third pattern is common in practice: the caller wants EasyGrid's type resolution and configuration infrastructure but needs to decide which columns to add at runtime — for example, based on user roles, feature flags, or a dynamic column set loaded from configuration.

Neither existing constructor fits: the auto-discover constructor adds too many columns, and the varargs constructor requires a compile-time fixed list. The boolean constructor fills this gap cleanly. Passing false suppresses all automatic column creation; the caller then calls addColumn(...) explicitly, with full access to the configuration tree on each returned EasyColumn. This also avoids the antipattern of creating a grid with all columns and then hiding the unwanted ones.

---

5.4 — EasyColumn delegates Grid.Column setters directly

The original spec divided column configuration across two objects: type-specific formatting on EasyColumn (via with* methods), and everything else on Grid.Column (via getColumn()). This forced callers to break the fluent chain every time they crossed from EasyGrid-managed config to standard column config:

// Original: chain breaks at getColumn()
easyGrid.getColumn("birthDate")
    .setDateFormat("dd/MM/yyyy")
    .getColumn()          // break
    .setHeader("Birth Date")
    .setFrozen(true);

The two-object model also impairs discoverability: IDEs show only the EasyGrid-specific methods on EasyColumn, so callers must know to call getColumn() to see the rest. This creates a hidden API surface.

Delegating the full Grid.Column setter API directly on EasyColumn eliminates the break and makes the entire column API visible on a single object:

// Updated: single unbroken chain
easyGrid.getColumn("birthDate")
    .setDateFormat("dd/MM/yyyy")
    .setHeader("Birth Date")
    .setFrozen(true);

getColumn() is retained as an escape hatch for the rare cases not covered by the delegation layer.

---

5.5 — addColumn(Class<V>, ValueProvider<T, ? extends V>) overload

Bean property introspection covers the common case, but real grids regularly need columns that do not correspond to a named property: a formatted combination of fields, a computed value, a summary derived from a collection, or a value sourced from an external object. Without a typed addColumn overload, the only option for such columns is to fall back to the raw Grid API, which bypasses EasyGrid's configuration tree entirely — type-level formatters and default renderers registered via GlobalEasyGridConfiguration would not apply.

The Class<V> parameter preserves the connection to the configuration tree. A BigDecimal computed column picks up any BigDecimal formatter registered globally or at the session level, exactly as a property-backed BigDecimal column would. The caller sets header, key, and any other column-specific config on the returned EasyColumn in the normal way.

[mlopezFC]

LGTM