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.
Related
After about a week of tinkering, I have managed to introduce webpack and Vue.js single file components into my existing Orchard (ASP.NET) module.
Now I've unexpectedly hit a snag, and for the life of me, I'm stumped. I have several image resources that are part of my custom Orchard theme, which is a separate module (*.csproj) within my Orchard solution.
So (at the risk of demonstrating my woefully inadequate understanding of URL concatenation in web projects) I innocently add this line to my Vue.js single file component:
<img src="~/Themes/MyOrchardTheme.Theme/Images/AnImage.png">
Now when webpack tries to process this and bundle my component I get this error:
Can't resolve 'Themes/MyOrchardTheme.Theme/Images/AnImage.png' in 'redacted' C:\Projects\Orchard\Modules\redacted\Module not found
This kind of makes sense, because the layout of my projects and resources locally and the layout after deployment to Azure obviously differ.
So what is the right way to specify the url for my image as it will exist at runtime on the server, without specifically testing for it's existence when transpiling with webpack?
I'm not going to accept this as the answer, in case someone can offer something better, but after some tinkering I was able to solve my problem by using this:
<img :src="theimage" />
and adding a computed property like this:
computed: {
theimage: function () {
return '/Themes/MyOrchardTheme.Theme/Images/AnImage.png';
}
This will bypass the Webpack transpiler (or vue-loader or whatever) check to make sure the resource can be located and has the added benefit that I can programmatically control the image displayed, which (although not mentioned) is ultimately what I wanted to do (code not shown). I was expecting to use v-if or v-show with multiple image tags, but using a computed property killed two birds with one stone.
Thanks to everyone who provided feedback. - I have a great deal to learn!
I am trying to change the number of custom fields I can create in OrgangeHRM PIM section.
I have found a few articles on this site that say what part of the code to change but non saying where to find the file where the code is stored is in.
If anyone can help then that would be great.
I am running version 4.0 of OrangeHRM.
Thanks
orangeHRM have slots for custom field (i dont remember, but i think 10 slot in orange 4.0), you can use this for put what you need.
Out the box, you can follow guides for add more custom or pre-format fields, but not is more recomendable, this can make broken code.
meanwhile, you think work out the box, remember orangeHRM is a symfony based software, if you know how work symfony (MVC framework), work it whit OrangeHRM is more easy
good luck
About Translate JMeter projects,
I follow the translating steps and open I18NEdit,
I see the translation text options but I notice that I can't localize Menu items as File, Exit,..
It seems that there are texts (messages.properties) that can't be localized.
Is messages.properties localization is done manually by adding messages_[locale].properties?
Am I missing something ? Is it on purpose or should an enhancement be opened?
We don't really use i18nedit for translation. But you can still use it.
Anyway, Internationalization in JMeter is based on properties files:
src/core/org/apache/jmeter/resources/messages_[locale].properties
src/components/..../*.properties (except some like colors.properties)
src/protocol/..../*.properties
No need to translate deprecated components.
The 2 latter are related to components that rely on TestBean approach (no specific GUI)
Note that a PR (github mirror) is preferred over a patch:
https://github.com/apache/jmeter/blob/trunk/CONTRIBUTING.md
I'm developing a plugin for Redmine and encountered an issue of how to implement plugin specific settings in Redmine in the most neat way.
Is it possible to have a plugin specific settings in {redmine_home}/plugin/{my_plugin}/config/settings.yml while sharing with a core a model (in MVC terms) logic which reads YAML file, sets attributes of the model class, provides easy access to them, etc. ({redmine_home}/app/models/setting.rb)
I think copypasting or require'ing the core model in the plugin model is definitely a poor design so right now i'm tending to have a plugin specific settings in the core config {redmine_home}/config/settings.yml and when it comes to plugin controller to read a settings it relies on the core model to do that. ({redmine_home}/app/models/setting.rb)
Is this a proper design? Is there any better ways to do this?
Thanks.
I just checked 3 different plugins in our project all used something like:
options = YAML::load( File.open(File.join(Rails.root, 'plugins/fancy_plugin/config', 'settings.yml')))
So just copy pasting.
I'm working on a Sproutcore UI for a project called "BWUnit". When using sc-gen to create models, etc it converts "BWUnit" to "BwUnit" in the generated files. Is there a way to prevent this from happening so I don't have to manually edit the files, replacing "BwUnit" with "BWUnit"?
so SproutCore unfortunately doesn't support what you want out of the box. This is their naming convention: http://wiki.sproutcore.com/w/page/27759680/FiedNotes-Suggestions%20on%20running%20the%20Sproutcore%20framework%20on%20a%20Windows%20(7)%20computer%20using%20a%20specific
If you are brave, however, you can edit the built tools and change the behavior of how the project and app names are prepared:
https://github.com/sproutcore/abbot/blob/master/lib/sproutcore/models/generator.rb#L462
If this is a feature you want and need, please open an issue here:
https://github.com/sproutcore/sproutcore/issues
Cheers,
Johannes