How can I create a custom block to capture data but not expose to template when rendering?

[dswitzer]

I'm looking to implement something like what LiquidJS has for capturing blocks:

https://liquidjs.com/tags/layout.html#Multiple-Blocks

In my case, my current thinking is I want to capture the output inside a block but not expose that captured data to rest of the template. So I might have something like:

{% export header %}Header{% endexport  %}

This text inside the block would be captured, but not available to the template like {% capture } would be.

In looking at the Capture class for inspiration, I see it's storing the results in the TemplateContext and I can use a Template.ContextHolder if I want to extract that information after rendering. However, it puts the data in the normal context, which makes it available in the template.

I thought I might be able to extend the TemplateContext class to add tracking of these exported captures, but it doesn't look like there's a way to have the Template instance use a custom TemplateContext.

My next thought was I might be able to create a new "registry" entry in the TemplateContext instance, but the getRegistry() code throws an exception if you try to create a registry that does not exist.

Any thoughts on how I might capture some data and not expose it to the template, but be able to read it in the a ContextHolder later?

[msangel]

Duplicate for #266
No solution so far.

[msangel]

but it doesn't look like there's a way to have the Template instance use a custom TemplateContext

Agree, this is not handy and worth to fix this.

the getRegistry() code throws an exception if you try to create a registry that does not exist

This is synthetic limitation and can be dropped.
In the end users might want to create own tags with own logic that will be handled own registries (the way current ones are used).

Any thoughts on how I might capture some data and not expose it to the template, but be able to read it in the a ContextHolder later?

I would go with ThreadLocal but that is a dirty hack.

[dswitzer]

Do you feel like opening the registry up for general usage would be appropriate?

It seems like the registry is being used to track internal state information, so feels like this might be the best way to go.

Is there a reason the unknown registry type exception needs to be thrown?

Would you be open to a PR that allowed creating new registry items?

If so, would you prefer that you need to do something like call an addRegistry() function so that getRegistry() would still throw an exception if the registry was not first declared? Or can we just allow getRegistry() to be boundless and it will just create a registry for any name that's supplied?

[dswitzer]

@msangel,

So it sounds like you'd be open to a PR in which the limitation of getRegistry() being tied to only specific contexts was removed.

I'd be happy to work on a PR.

[msangel]

0.9.2.1 should have it.
Commit was made directly to master as it is simple 76ae8fd

[dswitzer]

Fantastic! Thank you so much!

[dswitzer]

Are you planning on pushing 0.9.2.1 to Maven or should I just compile it myself?

[msangel]

Sorry I forgot to click free buttons yesterday. Will finish the release today.

[msangel]

This time I finished the flow. 0.9.2.2 should be in public repo in few hours now this time for sure