I know there's already a question on converting line breaks to <br> tags in Thymeleaf, but the "#strings.replace" solution from there, relies on getting the line.separator system property to make it platform neutral. Since Thymeleaf 3.0.12 this is now broken (see this GitHub issue) when used with th:utext. Is there a recommended replacement for this, other than just using "\n"? For reference, the current line (which we use all over our codebase) looks something like this:
<div th:utext="*{#strings.replace(#strings.escapeXml(fieldName),T(java.lang.System).getProperty('line.separator'),'<br>')}">
I made a Thymeleaf dialect that makes it easy to keep the line breaks, if the css white-space property isn't an option. It also bring support for BBCode if you want it. You can either import it as a dependency (it's very light) or just use it as inspiration to make your own. Check it out here : https://github.com/oxayotl/meikik-project
Related
I'm working on a project where YAMLs are used (among other use cases) for storing synonym lists. A file may look a little like this:
- "streifen,gestreift"
- "fleeceoverall,fleeceanzug"- "federball,badminton"
- "hochgarage,parkgarage"
In this case - "federball,badminton" is on the same row as - "fleeceoverall,fleeceanzug" which causes the build of the application to fail with an error stating
Unexpected characters near "- "federball,badminton".
I tried to configure a code style profile for code inspections as mentioned here in the PhpStorm documentation:
https://www.jetbrains.com/help/phpstorm/customizing-profiles.html?keymap=secondary_default_for_macos
But I don't know what to adjust here. I using the IDE-Standard which looks like this for wrapping and braces (which I guess is what I'm looking for ;) :
I also took a look at validating my YAML against a JSON file as mentioned here: https://www.jetbrains.com/help/phpstorm/yaml.html# but ultimately I don't understand how this works :/
So I guess I'm a little lost on how to avoid the errors at build time beforehand and would love some advice!
I am using Spring RestDoc together with AsciiDoc to describe my rest api. RestDoc generates different files depending if there are request parameters described / response fields etc. I would like to have one template conditionally including whatever file exists.
something like this:
Request:
include::{reqresPath}/http-request.adoc[]
Response:
include::{reqresPath}/http-response.adoc[]
Parameters:
ifeval::[{{reqresPath}/request-parameters.adoc}.exists]
include::{reqresPath}/request-parameters.adoc[]
endif::[]
ifeval::[{{reqresPath}/request-parameters.adoc}.exists]
include::{reqresPath}/request-parameters.adoc[]
endif::[]
or at least exclude warnings in case of a missing file. But I could not figure out how to suppress these.
As of today, where is no operator for ifeval available, which can be used to check the existence of a file.
The way I would go is to write an extension for Asciidoctor, which can also be done by using Java. If your projects is big enough, I would suggest to go for this solution.
The most extreme way is to make a custom TemplatedSnippet which is generating an empty snippet to be included...
I hope there is a better way to do this.
Edit:
Take a look of http://asciidoctor.org/docs/user-manual/#by-tagged-regions
related to: How do I prevent sphinx from making a url a hyperlink?
In the question above we learn how to escape individual URL's in reStructured Text to prevent Sphinx from turning them into hyperlinks when converting to HTML. However I have a lot of URL's and I would like to keep my .rst files as clean as possible. It is an API documentation, so adding backslashes or quotes makes it less readable. Is there a config option to prevent Sphinx from parsing URL's altogether?
Unfortunately, I don't think there's any easy way. Implicitly detecting URIs happens at the reST-parsing layer:
https://github.com/qsnake/docutils/blob/68af50cccd2c8bb88264bffad44faa8e47e5d7dc/docutils/parsers/rst/states.py#L627
Sphinx is a set of predefined domains & related tooling on top of docutils' reST implementation, so this is lower-level than the things it provides config options for.
There might be some way of getting the HTML writer to not emit <a> tags out the output side of things, but my guess is that even if it's possible, it's likely to be pretty involved.
Did a MediaWiki upgrade from 1.15.1 to 1.20.2 by following the simple update instructions (basically a new installation, copying over the old LocalSettings.php, update script and copying over images). Weird thing now is that all of the File: prefixes don't work. Instead the internal links to images is a "file:name of image" URL rather than "http://mediawiki address/index.php/File:name of image".
Anybody else getting this. Assuming it is something wrong with the old LocalSettings.php.
Ran the refreshLinks and refreshImageMetadata maintenance scripts without fixing the problem.
In the comments, you wrote that you have file: added to $wgUrlProtocols. This is very likely what's triggering the problem.
It looks like something has changed in the parser between MW 1.15 and 1.20 so that it's now parsing file:whatever as an external link (since it matches the file: prefix you've defined in $wgUrlProtocols) even if it's inside square brackets.
The obvious workaround would be to change the $wgUrlProtocols entry from file: to file:// so that it will only match if the slashes are there (as they should be, according to standard file: URL syntax). Since your on-wiki filenames are, presumably, very unlikely to begin with double slashes, they should not match this more specific prefix.
That said, this could still be considered a bug in MediaWiki. You may want to file a bug report about it, if there isn't one yet.
(Edit: Looks like Mark A. Hershberger filed one already.)
We're using Freemarker version 2.3.16, and I've just tracked down a weird bug in one of our apps. It came down to there now being hyphens in some of our product code strings. The codes are used to pull hashes of localized text from the global scope using .vars.
Reducing the issue brought me to an example that anyone can try:
${.vars["foo-bar"]} in a template outputs 0
${.vars["foo+bar"]} outputs nullnull
${.vars["foobar"]} correctly triggers an InvalidReferenceException
All three should trigger exceptions. Instead, it appears the .vars parameter string is being evaluated! :-(
http://freemarker.sourceforge.net/docs/app_faq.html#faq_strange_variable_name implies this should work.
I saw mention of a similar issue a few weeks ago on the Freemarker mailing list, and it was suggested to prefix the parameter string with "#". That might work with other hashes, but it does NOT work with .vars. I just took a working example (.vars["resources_title"]) and changing it made it throw an InvalidReferenceException (.vars["#resources_title"]). I also tried it on the hyphenated reference, and it also threw the exception.
Upgrading to 2.3.18 did not seem to make a difference.
Sorry for the delay. After some good mailing-list help on places to put breakpoints, here's I wrote back to the list on June 10th:
Short story: It's not a Freemarker issue. Rather the Struts team chose to hard-wire Freemarker to treat .vars names as OGNL expressions, and there seems no way to tell OGNL to not parse them. So under Struts, "-" and "+" (and possibly other characters) cannot appear in .vars names.
Long story...
freemarker.core.BuiltinVariable (line 192) is where Freemarker starts to process .vars expressions
freemarker.core.Environment (line 1088) hands control over to the "rootDataModel" which the Struts team hard-wired to be an instance of org.apache.struts2.views.freemarker.ScopesHashModel
line 70 of that class (using version 2.1.8.1 of Struts) calls "stack.findValue"; "stack" has been wired to be an instance of com.opensymphony.xwork2.ognl.OgnlValueStack
at line 236 this class in turn asks an instance of OgnlUtil to find the object, and that's where the name is assumed to be an OGNL expression and is parsed, turning "foo-bar" into ( foo - bar )
At no point along the way does there seem to be a choice to NOT treat the .vars name as an expression (a comment in FreemarkerResult hints at the possibility, but the code doesn't follow through). In theory I could have my implementation of FreemarkerManager create a variant of ScopesHashModel, but that would take a lot of work to change all the associated classes with it.
(Nor does there seem to be a way to escape "-" characters in OGNL expressions. Seems there was discussion 5-6 years ago to do this, but.... .vars( "foo\\-bar" ) fails on finding "-" after "\", so presumably "-" isn't escapable?)
:-(
I'm not clear what the use-case is for treating .vars names as expressions... but I don't think Struts is going to change, now. Rather than override a half dozen Struts classes, I instead changed the code that loads our ResourceBundles into the value stack: it now changes the names to replace "-" and "_", and likewise my .vars names are changed the same way in the template and... tada. It works. Woo.
Works for me. And like already mentioned on the freemarker-user mailing list: maybe you use a strange data model, or even a fancy ObjectWrapper. But a discussion like this is probably better suited for the freemarker-user mailing list...
It works if it added with escape foo\-bar.
"Only single backslash"
Since freemarker version 2.3.22 is it possible to use dot (.), minus sign (-) or colon (:) in a variable name (details here).
In my case, it fails if I tried to use with freemarker 2.3.21 variables like :
api["x-link"]
If I change freemarker to version 2.3.22 it works.