-
Notifications
You must be signed in to change notification settings - Fork 170
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduces a limited length render filter and HTML tag close filter #1128
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These seem like good features to include
|
||
@Override | ||
public String getName() { | ||
return "render"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
return "render"; | |
return "closehtml"; |
if (args.length > 0) { | ||
/* | ||
This means a render limit length has been provided. | ||
Here we begin a left to right render where we add to an HTML string until the length reaches a certain limit. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, not necessarily an HTML string, but the functionality makes sense
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, just a few points that we should address before merging
@@ -24,6 +25,10 @@ public String getName() { | |||
|
|||
@Override | |||
public Object filter(Object var, JinjavaInterpreter interpreter, String... args) { | |||
if (args.length > 0) { | |||
String firstArg = args[0]; | |||
return interpreter.render(Objects.toString(var), NumberUtils.toLong(firstArg, 0)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should cap the limit to config.getMaxOutputSize()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And we should add some nicer error handling here if we can't coerce the String to a Long
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's what I thought, except default max output size is 0 (unlimited I assume?) so clamping it always goes lower than the provided value.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just changed the default value to explicitly take on whatever is in the config. We could instead just switch to the other case or throw an error.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only clamp if the max output size is > 0
public String render(Node root, boolean processExtendRoots) { | ||
OutputList output = new OutputList(config.getMaxOutputSize()); | ||
|
||
public String render(Node root, boolean processExtendRoots, long renderLimit) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't need to be public
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's easier to increase visibility later than to decrease it
public String render(Node root, long renderLimit) { | ||
return render(root, true, renderLimit); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't need to add this method
} | ||
|
||
/** | ||
* Render the given root node, processing extend parents. Equivalent to render(root, true) | ||
* Render the given root node, processing extend parents. Equivalent to render(root, true, -1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't need to change this, also it's not the same as that since it passes the max output size from the config
long safeRenderSize = (config.getMaxOutputSize() == 0) | ||
? renderLimit | ||
: Math.min(renderLimit, config.getMaxOutputSize()); | ||
OutputList output = new OutputList(safeRenderSize); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Someone could pass a negative or 0-value render limit and bypass the max output size.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And it would be good to test these different cases for ensuring render limit doesn't allow rendering more than configured
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So by default, this using 0 (unlimited) as the render size makes me wonder what the problem is here. Do we have cases where we modify this config value for limited length rendering? As per my logic here in the filter, if no value/an invalid value is provided, we just pass in 0 anyway, so that to me seems like an easy workaround.
Right now, config.getMaxOutputSize()
returns 0.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If config.getMaxOutputSize()
is 100 and renderLimit
is 0, then it will bypass the configured limit and render unlimited characters.
For HubL, we are always setting a non-zero value for config.getMaxOutputSize()
private long clampOutputSizeSafely(long providedLimit) { | ||
long configMaxOutput = config.getMaxOutputSize(); | ||
|
||
if (configMaxOutput == 0) { | ||
return providedLimit; | ||
} | ||
|
||
if (providedLimit <= 0) { | ||
return configMaxOutput; | ||
} | ||
|
||
return Math.min(providedLimit, configMaxOutput); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, can we just get some tests for this logic?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done, thanks a lot Jack. To avoid repeating tests or changing signatures I moved this into a small static utils class which I tested on it's own. Let me know if you'd rather I just make it public in the interpreter or add more tests to the render method as a whole and take it back to being private.
I did like this a bit for simplicity though.
Currently, Jinjava provides filters for truncating HTML. The purpose of these is to shorten or summarize rich text. They correctly handle HTML so that tags are not left hanging open. However, they do not accommodate text that contains raw HubL as well as HTML. The purpose of this PR is to allow summaries of objects that contain raw HubL text.
This also includes a filter that closes HTML tags that may have been left hanging open.
Example usage in pseudocode:
This serves as an alternate option to the
truncatehtml
filter that will do the same thing to raw rich text but also correctly render HubL included in it.