+1 Mridul. Thanks, Ashish
On Thu, 8 Oct 2026 at 18:55, Mridul Pathak <[email protected]> wrote: > Hi all, > > I would like to continue the work Daniel Watford started in > OFBIZ-11456 and extend it from the form renderer to the screen, menu > and tree renderers. Today those renderers build a string such as > <@renderLink id="..." text="..." /> with the values pasted into it and > compile it as a FreeMarker template, so every value has to be escaped > correctly as template code. FtlWriter already has the better pattern: > it puts the parameters in the FreeMarker environment and compiles only > a constant call to the macro with ?with_args, so values are data and > never part of the template. The form renderer is partly migrated to > it, while OFBIZ-12128 to 12133 and the rest of the form renderer, the > screen renderer, the menu renderer and the tree renderer still build > the text. Earlier discussion is in > https://lists.apache.org/thread.html/vztych8mslsr1g1kp1hvzzw9o9zsj4mm. > > I propose to convert them in stages, one JIRA ticket per renderer, > until the only template text FreeMarker compiles is one fixed call > template and the string-building paths are removed rather than > deprecated. I prototyped it against the real macro libraries and for > the macros I tried the output is identical to today's, and the macro > signatures and the Macro*Renderer constructors stay as they are, so > themes and plugins should not be affected. A few visible behaviours > would change because values would no longer be interpreted as > FreeMarker: a literal ${...} in a value is printed as is, a null value > is rendered as an empty string instead of the text "null", HTML > encoding is done in one place instead of partly in Java and partly in > the macros, and the tree renderer writes link images in the right > position. If we find client code that relies on the old behaviour > there is a straightforward fix, which is to expand the > developer-written expression earlier (in the widget definition or in > the calling code) before it reaches the renderer, and we would make > that correction as part of the change. > > Jacopo and I have discussed this idea and he is supportive of the approach. > > Best Regards > Mridul Pathak > https://www.linkedin.com/in/mridulpathak/ >
