Skip to content

Fix #2219: specify the automatic UIPanel for a multi-child f:facet - #2220

Merged
BalusC merged 2 commits into
5.0from
issue_2219
Aug 12, 2026
Merged

Fix #2219: specify the automatic UIPanel for a multi-child f:facet#2220
BalusC merged 2 commits into
5.0from
issue_2219

Conversation

@BalusC

@BalusC BalusC commented Jul 28, 2026

Copy link
Copy Markdown
Member

Closes #2219.

What

"Using Facets" in Standard Tag Libraries required a facet tag to have "one and only one child UIComponent tag", with footnote 10 sending page authors to <h:panelGroup> for more than one, while the f:facet Vdldoc has stated since 2.3 that "When the facet contains more than one child the children will be automatically put in a container UIPanel". Implementations do the latter. The prose predates the 2.3 addition and was never reconciled with it; its only revision was the pass-through-attributes carve-out (#2032), which reads as if that were the sole case where an automatic UIPanel appears.

Three sites:

  • "Using Facets" now states the three cases — exactly one child becomes the facet, more than one child yields an automatically created UIPanel facet holding them, no child but pass through attributes yields an empty one.
  • "Creating Components and Overriding Attributes" — the facet bullet said "if such a facet already exists, take no additional action", which reads as the second child tag being silently dropped. It is split into the facet already being this tag's own component (no action) and it being another component (wrap in the automatically created UIPanel unless it already is one, move the existing facet into it, add this one).
  • Footnote 10 becomes a recommendation rather than a requirement: an explicit <h:panelGroup> still buys control over the component type, renderer type and client identifier of the container, which the automatic panel does not offer.

Plus a Change Log entry.

Testing

mvn clean package in spec/ renders HTML and PDF without warnings.

That the implicit panel is specified behaviour also settles eclipse-ee4j/mojarra#5885, where a UIInput inside a multi-child facet lost its submitted value and invalid state on the render-time Facelets refresh — a conformance bug, fixed in eclipse-ee4j/mojarra#5886, with TCK coverage in #2218.

🤖 Generated with Claude Code (Opus 5)

"Using Facets" required one and only one child per facet tag, with
footnote 10 pointing at h:panelGroup, while the f:facet Vdldoc has
stated since 2.3 that the children of a facet holding more than one of
them are automatically put in a container UIPanel. Implementations do
the latter. The prose now states the one-child, multi-child and
pass-through-attributes-only cases, and footnote 10 becomes a
recommendation for when the component type, renderer type or client
identifier of the container matters.

The facet bullet in "Creating Components and Overriding Attributes" is
split along the same lines, so that a facet name already holding
another component wraps in the automatically created UIPanel instead of
dropping the tag.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@BalusC
BalusC changed the base branch from master to 5.0 July 28, 2026 20:53
@BalusC
BalusC requested review from arjantijms and tandraschko July 28, 2026 20:54
@BalusC BalusC added this to the 5.0 milestone Jul 28, 2026
@BalusC

BalusC commented Aug 12, 2026

Copy link
Copy Markdown
Member Author

Approved by MyFaces in #2219 (comment)

# Conflicts:
#	spec/src/main/asciidoc/ChangeLog.adoc
@BalusC
BalusC merged commit 93214e3 into 5.0 Aug 12, 2026
1 check passed
@BalusC
BalusC deleted the issue_2219 branch August 12, 2026 15:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

f:facet child-count text in Standard Tag Libraries contradicts the f:facet Vdldoc

1 participant