You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A few weeks ago, I asked a question in the Slack channel (link to message) about adding custom HandlebarHelpers to the existing HandlebarUtils string manipulations.
@jonatan-ivanov suggested creating an issue, so I thought I could also provide a possible solution with it. This is just a proposal, so please let me know what you think and how it can be improved.
Objective
(One small example) I want to cut the package names and keep only the class name of the defining Convention (rendered when using ObservationDocumentation structure).
I have taken a look in the StringHelpers provided by Handlebars.java but couldn't find what I need. Perhaps I overlooked something.
Proposed Solution
My approach now is to change HandlebarUtils to a Singleton, making the instance more extensible and allowing custom HandlebarHelpers to be registered. As of my view and tests, this change does not affect current functionality but introduces extensibility.
I've implemented the changes in my fork, do you want me to open a PR?
Example Usage
I created a simple example demonstrating how to use this, and it worked as intended. If you're interested, please check out the repository.
Here's a small peek at how I would add custom helpers:
Custom Handlebar Helpers for HandlebarUtils
Background
A few weeks ago, I asked a question in the Slack channel (link to message) about adding custom HandlebarHelpers to the existing HandlebarUtils string manipulations.
@jonatan-ivanov suggested creating an issue, so I thought I could also provide a possible solution with it. This is just a proposal, so please let me know what you think and how it can be improved.
Objective
(One small example) I want to cut the package names and keep only the class name of the defining Convention (rendered when using ObservationDocumentation structure).
Current Workaround
Currently, I achieve this through a Gradle Copy task to filter the end result, similar to how Spring AMQP handles their documentation.
I have taken a look in the StringHelpers provided by Handlebars.java but couldn't find what I need. Perhaps I overlooked something.
Proposed Solution
My approach now is to change HandlebarUtils to a Singleton, making the instance more extensible and allowing custom HandlebarHelpers to be registered. As of my view and tests, this change does not affect current functionality but introduces extensibility.
I've implemented the changes in my fork, do you want me to open a PR?
Example Usage
I created a simple example demonstrating how to use this, and it worked as intended. If you're interested, please check out the repository.
Here's a small peek at how I would add custom helpers:
The text was updated successfully, but these errors were encountered: