Contrib.social

Consider nicmart/tree for core inclusion

Open on Drupal.org →
Created on 16 May 2025, about 1 month ago

Problem/Motivation

I just started reworking the render system into OOP. It'll take a year or two but here we have a shortcut for one piece of a complex puzzle: form API elements form a tree. Surely there's a library for handling those.

Proposed resolution

Add nicmart/tree.

  1. Maintainership of the package: single maintainer, couple contributors. PHP 8.4 support was released one day after 8.4.0 itself.
  2. Security policies of the package: there doesn't seem to be one probably because there's not really a security surface of this thing. There is no input, there's no output, there's no I/O of any kind, there's no fancy code execution, there's just nothing. (Famous last words?)
  3. Expected release and support cycles: none. There's no need. While no software is ever complete this is a tiny, tiny library with well defined requirements.
  4. Code quality: looks good to me. Did I mention the whole thing is tiny?
  5. Other dependencies it would add, if any: There are no dependencies, only dev dependencies which do not matter. (Um. It's too small for that. Did I mention that already?)
  6. How well the dependency fits Drupal's need: it can add a child to a tree, find the parent of a node, iterate children -- all of that in a trait which is perfect. Slap the trait and the interface on RenderElementBase, children handling is done.

Remaining tasks

Agree, add.

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

✨ Feature request
Status

Active

Version

11.0 🔥

Component

render system

Created by

🇨🇦Canada Charlie ChX Negyesi 🍁Canada

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024