Novità in Twig 4.0: comporre i blocchi a runtime (Symfony Blog)
Un CMS consente spesso a ogni sito di personalizzare il modo in cui vengono visualizzati i campi di contenuto. Il tema predefinito definisce il wrapper del campo, mentre il tema di un sito sovrascrive il blocco usato per renderizzare un'immagine. Il wrapper chiama quel blocco, ma nessuno dei due temi estende l'altro. La sola ereditarietà non può far sì che il wrapper veda l'override del sito. BlockChain compone i loro blocchi a runtime. È stato rilasciato per la prima volta in Twig 3.29, quindi puoi già usarlo oggi.
Lo stesso schema funziona per una cella di una data-grid: il tema admin fornisce il wrapper, mentre il tema dell'applicazione personalizza il valore:
Crea una chain in ordine di precedenza, poi renderizza il blocco che ti serve:
Il risultato è <td class="admin"><strong>Pending</strong></td>. Ogni voce può essere il nome di un template, un template caricato o un'altra chain. Puoi riutilizzare $defaults in altri stack di temi.
Vince il primo blocco corrispondente: cell proviene dal tema admin, mentre block('cell_value') sceglie l'override dell'applicazione. parent() resta all'interno della gerarchia di ereditarietà del template che lo definisce; non salta al tema successivo. Consulta la documentazione di BlockChain per le regole complete di lookup, la gestione del contesto e gli altri metodi.
Lo stesso schema è utile per i controlli dei form, i campi CMS e i frammenti di email: il tuo renderer sceglie il nome del blocco e Twig trova il tema giusto.
Symfony Forms: il renderer dei form di Symfony combina da tempo blocchi di temi non correlati tra loro: una form view può avere un proprio tema, ereditare temi dalla sua view padre e ricadere sul layout predefinito. Un blocco form_row di un tema può chiamare block('form_widget') e trovare un override in un altro. Prima di BlockChain, il Twig Bridge doveva risalire i template padre, unire le mappe dei blocchi e passare tali mappe all'API di rendering interna di Twig.
Ora il Twig Bridge usa BlockChain quando è disponibile.
Questa integrazione è disponibile in tutte le versioni di Symfony attualmente supportate. Se aggiorni a Twig 3.29, aggiorna anche il Twig Bridge.
Oltre Symfony: altri renderer implementano una composizione di blocchi simile e potrebbero trarre vantaggio dalla stessa API di Twig:
- Ibexa Core seleziona blocchi per tipo di campo, come
ibexa_string_field, tra template di campi CMS locali e configurati. Attualmente il suo field renderer costruisce da sé la mappa dei blocchi. - Prezent Grid sovrappone temi di griglia e risolve i blocchi widget per i tipi di colonna. Una chain potrebbe comporre i suoi temi mentre il grid renderer mantiene la sua logica di fallback per tipo di colonna.
- Listing attraversa i template padre e unisce i loro blocchi prima di renderizzare i blocchi di listing e di colonna. Una chain potrebbe farsi carico di quella traversata.
La necessità di comporre blocchi tra template indipendenti non è specifica di Symfony, ed è per questo che l'API è arrivata in Twig.
Altri articoli recenti
Laravel AI 1.1 e 1.2: Agent Skills, Cohere e structured output più solidi
Le release 1.1.0 e 1.2.0 di laravel/ai portano gli Agent Skills, l'approvazione obbligatoria per i tool built-in e nuovi provider come Cohere e Laya self-hosted. Sul fronte qualità arrivano i fix allo structured output per Bedrock e il supporto alle provider options. Aggiornati anche i modelli di default, con Claude 4.7+ che ignora i sampling params.
Laravel 13.35.0: scheduler più controllabile, code più flessibili e response Markdown
Laravel 13.35.0 porta Schedule::alwaysOnOneServer(), il supporto a schedule:interrupt per i comandi di lunga durata, --memory in percentuale per queue:work e il nuovo metodo markdown() sulla response factory. Tante piccole migliorie anche a test, view compilate in parallelo e dischi local.
BashBox: un interprete Bash in sandbox per agenti AI in PHP
BashBox è un interprete bash scritto in puro PHP che permette di eseguire gli script generati dagli agenti AI senza mai ricorrere a proc_open, exec o shell_exec. Ogni comando è una classe PHP che lavora su un filesystem virtuale, con limiti di esecuzione, quote disco e accesso di rete configurabili. Ideale per chi sviluppa agenti con il Laravel AI SDK o altre librerie simili.