It should be possible to configure freemarker to use the old #-less syntax.
However, to give users time to prepare for this change, in FreeMarker 2.1 and 2.2 the usage of # is optional, unless the programmer enables strict syntax mode in the FreeMarker configuration by calling setStrictSyntaxMode(true) on Configuration. In fact, we strongly recommend this to programmers. Starting from some later release this setting will be initially set to true. Also, you can specify if you want to use strict syntax or old syntax in the template files with the ftl directive.
http://freemarker.org/docs/ref_depr_oldsyntax.html
How can I configure the fmpp preprocessor to use this old syntax with the Ant integration? Is there a setting or how can one call setStrictSyntaxMode(false)?
I am grateful for any assistance!
It seems you can't... it's not exposed through FMPP's setting API. If it's any consolation, the new syntax is more practical, because it catches more typos, and because the Eclipse plugin supports it. So if you have some old templates, certainly it's better to take that 15 minutes and search-and-replace the FTL tags with the # version.
I was able to solve this by adding an "oldSyntax" Setting myself using the "setOldTemplateSyntax" method that is offered by the Engine.
https://github.com/freemarker/fmpp/issues/20
Related
In Grails 2 we used the "External configuration plugin", which included the method checkNow() for checking and refreshing values from an external config file.
Does it exist a simple approach for doing something similar in Grails 4+? I have seen references to Spring Cloud Config Server, but it seems a bit overkill for me. All I really want to do is be able to (now and then) update a config value in runtime. It could also be purely by a few lines of code, and does not have to originate from changes in the config file. This would avoid having to restart our server for minor changes in config. Thanks!
I'm replying to myself with a ridiculously simple answer: "just change it". Using the console plugin (or any other form of code execution), I can just assign grailsApplication.config.any.property a new value. It won't persist and it won't update any listeners or anything. But it is a glaringly obvious solution that I just assumed wouldn't work due to the getProperty() calls (I interpreted the name as reading from file) and googled discussions about Spring Cloud Config.
So, move on... nothing to see here. Just mild embarrassment :-P
While I understand that it is not "best practice", I have a lot of legacy plugins that I am upgrading to Grails 3, and I need to set their GSP encoding back to the old default of "none" (because everything is already encoded where it needs to be, and we expect non-encoded data elsewhere.) Unfortunately, this appears to not work per the documentation.
The Grails 3.2.11 docs say:
Per Plugin Encoding
Grails also features the ability to control the codecs used on a per plugin basis. For example if you have a plugin named foo installed, then placing the following configuration in your application.groovy will disable encoding for only the foo plugin
foo.grails.views.gsp.codecs.expression = "none"
This did not work, using Grails 3.2.11. Encoding is still "html".
Other things I tried, that also did not work:
Just changing the plugin's application.yml from the default values (this seems like it would be ideal to me, and was what I originally expected would control the plugin encoding)
Same line, in runtime.groovy
Same line, in the plugin's plugin.groovy
Same concept with the prefix, in both the application's and the plugin's application.yml
Changes per suggestions in How can I exclude a plugin from grails default gsp encoding?
I'm perfectly willing to write this up as a Grails bug, but figured I would ask here first in case somebody else has already solved this!
Thanks in advance!
See linked grails issue for answer; short version is that:
all codecs must be valid, or defaults are used due to exception thrown in codec processing
plugins should be cleaned before publishing, or precompiled gsps may still use previous codecs
I was hopping to have an easy way to customize the display behavior of the Grails fields plugin after reading its docs, but I just realized that it demands an enormous effort as there is no available templates to start from.
I can see the display functionality is hard-coded in FormFieldsTagLib (from methods like renderDefaultInput() ) but I think it is imperative to have the templates themselves (or a way to generate them, somewhat like generating static scaffolding in Grails).
I can see no consistent (and reasonable) way to customize display behaviors for the Grails fields plugin without that. Am I missing something?
Imagine the use case where someone wants to change the boolean default rendering just to display the field label after (and not before) the checkbox, and keep it available to all the boolean fields within its application. Which concerns will he need to handle regarding if the field is required, has errors, prefix and so on? When all he needed was just moving two divs around.
Grails version: 2.5.4, fields-plugin version: 1.5.1
You aren't missing something. You'd have to re-create the existing implementation of each field type rendering in a template for use with the plugin. There isn't a way to generate a file to start with (like scaffolding).
I won't bore you with the historical reason as to why this is the case, but if you do create a set of base templates it would be a good idea to contribute back to the plugin.
I had an issue with the <f:table> tag, and found this post, which led me to find the base or default template inside the plugin repo.
Take a look at
https://github.com/grails3-plugins/fields/tree/master/grails-app/views
That may help you finding some default templates, along with the official doc and this answer on where to put the override.
Hope it helps you.
Setup: Portable editions of Sublime Text 2 with its plugin Sublimelinter and node.exe.
sublimelinter_executable_map has to set in a way so that Sublimelinter uses node.exe as JavaScript engine.
Could one do this using a relative path instead of a fully qualified path?
Trying with different forms of relative paths as given in MSDN, the plugin failed to detect node.exe. The console message i got was SublimeLinter: javascript disabled (One of the following JavaScript engines must be installed: node.js, JavaScriptCore)
Your GitHub issue on this topic:
https://github.com/SublimeLinter/SublimeLinter/issues/612
Is a duplicate of these:
https://github.com/SublimeLinter/SublimeLinter/issues/611
https://github.com/SublimeLinter/SublimeLinter/issues/459
This seems to be a hot topic.
I forked the repository and started to code a patch for you, which seems to center around this segment:
https://github.com/SublimeLinter/SublimeLinter/blob/4ef4b2ca08e0224b8af59bf3406c4927432efb94/sublimelinter/modules/base_linter.py#L380
But then, it dawned on me... environment variables. Since this seems to be a prevalent issue with many unsolved requests, it seems that you ought to set the PATH environment variable, and place the location you are looking to be found first, earlier in that variable.
Don't know your Windows version, and the process to set an environment variable will be different for your version, so you ought to experiment with that, and then use that method as the standard for all your environments ( as it seems implied you have more than one to maintain ).
Update: Ruby seems to allow relative paths, but JavaScript does not, because of this section:
https://github.com/SublimeLinter/SublimeLinter/blob/4ef4b2ca08e0224b8af59bf3406c4927432efb94/sublimelinter/modules/base_linter.py#L380
Which hinges on: JAVASCRIPT_ENGINE_WRAPPERS_PATH
So the answer is, unless that code is adapted, no. Relative paths cannot be used for JS.
I'm investigating Grails vs. other Agile web frameworks, and one key use case I'm trying to support is the ability to modify controllers and install plugins post deployment. It appears that this isn't possible with Grails, but I want to make sure before I write it off.
As far as modifying controllers goes, it would be sufficient if the Groovlet behavior existed (compile-on-demand).
As far as plugin installs go, I understand this may be a long shot, but I thought I'd check to be sure.
For your information, I need this because I work on a product that requires a little site-specific customization, such as adding validation of simple meta-data, integrating with customer security environments, and maybe even including new controllers/pages quickly.
Out of the box, no, grails doesn't really support what you want. There may be ways to customize it but I've never looked into it. A PHP framework might be more of your ally since there is no real deployment process other than copying PHP files to a location.
That said, I personally would prefer a strict set of deployment policies. And honestly, deploying changes with Grails is as simple as running the 'grails war' command and copying that war to your servlet container. The site's downtime is negligible and if you have multiple web servers with a load-balancer, your customers should never see down time due to deployments.
Although it's not recommended for complex coding; You could execute groovy code from a string that you could store in database or a file on the fly at run time:
check out Groovy template engine:
http://groovy.codehaus.org/Groovy+Templates
but even then, you are still limited on what you can do or can't do let alone debugging will lack. you may want to consider an interpreted language; few to mention PHP/Perl/Coldfusion.