http://www.thymeleaf.org/doc/tutorials/3.0/usingthymeleaf.html#template-layout docs says:
The code above defines a fragment called copy that we can easily include in our home page using one of the th:insert or th:replace attributes (and also th:include, though its use is no longer recommended since Thymeleaf 3.0).
I personally found th:insert the only possible way to implement templates.
So what does that mean? th:insert is deprecated or will be removed in future releases? Or it is bad practice?
What makes th:insert bad reputation?
I think it's a case of generalising what was previously provided by th:include ...
Thymeleaf 3.0 introduces a new type of expression as a part of the
general Thymeleaf Standard Expression system: Fragment Expressions.
They look like this: ~{commons::footer} and yes, they are extremely
similar to the syntax that could be used inside th:replace and
th:include (now th:insert) since long ago… because they use exactly
that syntax, but generalized so that it can now be used in other
scopes.
See Fragment Expressions.
There is nothing in the Thymeleaf docs to suggest that th:include should not be used nor to suggest that th:include will be removed in a future release.
In https://github.com/thymeleaf/thymeleaf/issues/625 I got response that starting with AttoParser v2.0.3 and corresponding Thymeleaf v3.0.4 content() selector can be used, which with th:replace makes th:include redundant:
<div th:replace="thymeleaf/layout :: tmpl(~{::body/content()})">
XXX
</div>
Related
I have a situation where a th:replace needs to be conditionally resolved based on whether a brand-specific file exists.
The current code is simple:
<!--/* brand.menuLogo has been pre-resolved to point to some specific file */-->
<div th:replace="${brand.menuLogo}"></div>
But this is less than satisfactory, for a number of reasons, and it's hard to maintain.
I would like to be able to do this instead:
<!--/* brand.id has some value like 'X' for Brand X */-->
<div th:replace="somefile_${brand.id}"></div>
With the idea that if somefile_X.html exists it will be used, otherwise somefile.html will be used instead.
What's the cleanest, easiest, most readable and most maintainable way to accomplish this in Thymeleaf? I'm open-minded to any solution that works "the Thymeleaf way" whatever that is. I used the term "custom resolver" in the question as a pre-conceived notion of how it might work, but I'm not beholden to such concept.
CLARIFICATION
The site has hundreds of files, and not every file has a variation for every brand. I'm interested in a mechanism that can resolve the correct file based on a combination of naming convention and existence of the file. So if FILE_X exists it is chosen, otherwise FILE is chosen.
You can try ternary expression in th:replace value like the following:
<div th:replace="${brand.id} ? 'somefile' + __${brand.id}__ + '.html' : 'somefile.html'">
Please note that __${brand.id}__ is preprocessed by thymeleaf engine as noted in this documentation.
Does Ruby provide any way of obtaining an argument passed to a function as a string literal?
In other words, if I have the following function...
def my_func(arg)
...
end
And I call my_func(obj.prop), I want to be able to obtain the following literal from within my_func...
"obj.prop"
I know Ruby can do some pretty funky things with metaprogramming, but I haven't found a way to be able to do this just yet.
This is not possible.
Ruby is a strict language, meaning that arguments get evaluated before being passed. IOW, all information about how the argument was produced is lost even before the method starts to execute.
There is no way to access the Ruby source code of a particular method, expression, or any other piece of code. In fact, since all Ruby implementations make it trivially easy to integrate with other languages (native extensions and FFI in YARV, mruby, and Rubinius, any JVM language in JRuby, ECMAScript in Opal, any CLI language in IronRuby, native extensions and Smalltalk in MagLev, and so on), there may not even be Ruby source code for a particular piece of code.
You want to obtain a string literal. Literals are part of a language's syntax, they don't even exist at runtime. Not only don't they exist at runtime, the very ideas of "runtime" and "literal" are fundamentally incompatible. Your request is not only impossible, it is non-sensical. There is no possible language, not even a hypothetical one, no possible world, in which your question would even make sense, let alone made to work.
Code
<xforms:output mediatype="text/html" value="xxforms:serialize(xxforms:call-xpl('oxf:/ops/utils/formatting/format.xpl', 'data', instance('message-instance'), 'data')/*, 'xml')"/>
Input
<REPC_IN000023NL xmlns="urn:hl7-org:v3">
....
<hl7:patientID xmlns:hl7="urn:hl7-org:v3">
<hl7:value root="2.16.840.1.113883.2.4.6.3" extension="999999035"/>
</hl7:patientID>
....
</REPC_IN000023NL>
Expected a rendering that includes the namespace declaration, but instead the rendering omits exactly that.
Bug or feature?
Indeed, the namespace declaration for the hl7 prefix, which isn't on the root element, is not produced:
I'd recommend you don't use that format.xpl; it isn't maintained, has performance issues with large documents, and, as you noticed, doesn't handle some corner cases well (i.e. it's buggy!).
Instead, you can use the fr:code-mirror component, which delegates formatting to CodeMirror. It won't do the indenting for you, but Saxon can do it for you. This example will give you the following output:
For my production releases, I have been using the expression extractor to generate a file containing expressions that are being used by my templates. When in production, I was configure the StaticParser like so:
import '../gen/expression_cache.gen.dart' as expression_cache;
...
module.type(Parser, implementedBy: StaticParser);
module.value(StaticParserFunctions, expression_cache.functions()); // <-- this no longer works
Something has changed with how the expressions are generated, as the line configuring StaticParserFunctions no longer works. The functions() method no longer exists. So I'm wondering, what is the correct way to do this as of angular 0.9.9?
Is far as I know the Angular Dart tutorial is pretty much up to date.
https://github.com/angular/angular.dart.tutorial/blob/master/Chapter_07/web/initializer-prod.dart
https://angulardart.org/tutorial/09-ch07-deploying-your-app.html (search for generator)
When doing J2EE development, I find it handy for debugging to view the Java classes that are generated by the JSP compiler.
How can I do the equivalent in Ruby? Since it is all in memory, it won't generate a file that I can view. I believe it's the ERB module that generates the corresponding object for a template, so how can I actually view the object? Can I drop a debugger statement somewhere and use rdb? Is there some configuration value I can tell it to dump the object definition? I'm using rails, in case that makes a difference.
I don't think rails generates a class for your view. It basically calls eval after processing the file. Or do you mean inspecting the erb object while it's parsing your template?
If it's the latter you can find erb.rb in lib\ruby\1.9.1 I'd imagine you could just drop a debugger statement throughout that file.
I always make a habit of adding the following to my views (layout) which allows me to inspect or debug the parameters being used by the view in question.
<%= debug(params) %>
This will format all the parameters in yaml and display them in a Hash format.
Have a look at the method in the source code to get a better understanding. SOURCE
There are some differences compared with the Java way due to language differences.
Most template libraries for Ruby follow these steps when compiling/optimizing:
The template is compiled into Ruby source code -- not a class but a long procedure that appends to a string buffer while traversing the logic of the original template.
This ruby code is evaluated in order to be bound for later reference, preferably within a method body. This way, it is only parsed once by the interpreter.
The method (or other context) containing the logic of the parsed template is invoked to render it.
Anyway, the compiled template code therefore looks a lot like a much noisier version of your original template, and will generally not help you debugging, unless you're debugging the template language itself.
Anyone interested in template language implementation might enjoy a look around the Tilt code (use different template languages with the same rendering interface and optimization), and Temple (a great template language meta-implementation).