I am relatively new to Grails and I am little disappointed with the way _form.gsp removed with field plugin in Grails 3. _form.gsp seemed to be good time saving option when we need to customize views with Bootsrap or materialize.
Now with grails 3, install-templates does not create _form.gsp. As per this documentation, we can achieve customization by creating _wrapper.gsp, _widget.gsp etc under view/_fields/default directory. But I am not able to find the example of such custom GSPs.
Also, let's say if I customize all the four GSPs (_wrapper.gsp, _widget.gsp, _displayWrapper.gsp, _displayWidget.gsp) will it generate actual code when we run generate-view command? I mean will it replace, f:all, f:table etc tag with actual code? If not then there is quite amount of work to do I guess. Because after we are confident about our domain class and tested all CRUD operation, we run generate-view command for creating all the domain specific GSPs. Then in most cases, we need to do some changes according to our requirement, like re-ordering the fields, hiding some of the fields
So in conclusion I have two goals:
Customizing default templates and start developing.
When I run generate-view, I do not want f:all, f:table etc abstract tags. I need actual fields in place so that I can customize generated views of domain.
If any one has achieved this, then please share the solution.
Grails 3 comes with the fields plugin by default. The templates used in Grails 2.x have been replaced in full. So, your goal 2. will be hard to achieve with Grails 3 it seems.
However, here is a helpful blog which explains how you can adjust some of the fields templates by replacing them in your project: http://blog.anorakgirl.co.uk/2016/01/what-the-f-is-ftable/
Similar to the description provided, you can place a modified _list.gsp template in folder in
/grails-app/views/templates/_fields/
Hope it helps.
Related
I have multiple projects that I want to share a similar .clang-format style, but I also want to be able to make minor tweaks between each project so they can be slightly different from one another if needed. Currently each project just has the same .clang-format file copied and pasted into its own repository, but it feels wrong because all of the style options are just duplicated from project to project and if I need to change one option I need to go across all projects and manually change it in all of them.
I would like to create my own style that can be used with the "BasedOnStyle" option (See here for more info). That way I can specify that I want all of these projects to be based on the same custom style that would be kept in a shared location, and then I could easily override any project specific options on a per-project basis.
As far as I can tell, there doesn't appear to be any way to create your own style and save it so other projects can be based on the same style. I feel like this is something a lot of users would need (for example if a company wanted to define their own master style that all projects should follow there doesn't appear to be a good way to do it).
Has anyone else run into this problem and found a good solution?
I reached out to the llvm-dev email list and got a response. A feature request is in the works to do something similar to what I want, but not exactly the same. Either way, this should be suitable for my needs when it becomes available.
https://reviews.llvm.org/D93844
Structural search in IntelliJ IDEA is not only powerful, but also not trivial at all to get right. Now when I have created a working template of my own, I might want to use it in multiple projects.
I do not see a way to save globally. Is there anything I can do short of copying the relevant bits from one workspace.xml to another?
Unfortunatelly, it's not supported at the moment, please follow this feature request for updates.
Before we could use bundles like:
bundles.Add(new ScriptBundle("~/bootstrapjs", "//maxcdn.bootstrapcdn.com/bootstrap/4.0.0-beta.2/js/bootstrap.min.js").Include(
"~/lib/bootstrap/dist/js/bootstrap.js"));
How do I do this, for CDN paths now?
I know I can use gulp and so on, but I'm looking for at simple way to have a specific place to update all references to packages that I do not use on every page, like a calendar or a datepicker.
Before I had something like "#Scripts.Render("~/datepickerjs")" whenever I needed a datepicker, and I just updated the versionnumber in my bundleconfig.
I seems quiet like much work to update this every place I use it.
ASP.NET Core now uses the <environment> tag to differentiate when to load which scripts. This is actually far superior, as you can have many different variations for virtually any number of different environments, instead of just a simple boolean toggle of optimize or not.
If you want some of the similarity of being able to load a "bundle" of scripts, you can simply create a partial view that houses the scripts you want to include together as a set. Then, simply reference this partial where you need to drop them.
is anyone ever tried implementing the dojo toolkit AMD with laravel 4, or could anyone please point me to a simple sample.
just a simple AMD implemetation on laravel?
What asset manager or the default is ok. how to use it with dojo?
Please help. thanks
For 1. I suggest you may try this Laravel 4 bootstrap suite it gives you RequireJS implementation out of the box.
For 2. You can use dojo with any asset manager you want, or even without it (although it is not a good way) - just by putting its .js files in your /public directory and including them as you do in usual html from inside your view templates. If you are using Blade templates make sure the template syntax is not colliding with your js syntax. If it is, then use #include of .php file with your js code section in your .blade.php view template.
Asset manager gives you a more elegant and correct way of doing the same thing. It maybe extremely useful if you are dealing with LESS or Coffee things to be compiled into regular JS and styles.
If you want advanced asset manager I would suggest your to look at /CodeSleeve/asset-pipeline on github - it's one of many asset managers for Laravel, but one the few keeping alive (take a look at basset or laravel-grunt options on github for instance).
Asset Pipeline makes a good job making asset management similar to the one in Rails. Here is an article on how and why to use it: http://culttt.com/2013/11/04/add-asset-pipeline-laravel-4/
So far I have two short questions:
1) What precisely are the benefits of creating custom nature?
2) Is it possible to somehow programmatically read files in [project]/.setting or [workspace]/.metadata/.plugins?
I'm using Eclipse Helios (3.6).
Ad 1. I've read that you can't have two natures ofthe same set, that you can use it to associate certain perspectives/tools (ex. builder) with it but well.. anyting else I can't do easily without nature? Ex. I can easily add a builder by modifying an IProject variable.
Ad 2. I tried to find a way to read project specific settings or plugin settings but failed. No specs, different file types, inconsistent XML tags... Is it at all possible without parsing them manually?
Thanks for your help!
Paweł
Think of a nature as a flag. All project-related functionality in Eclipse is triggered by natures. Project properties pages, context menu items, etc. appear based on presence of natures. Third parties can check for presence of nature to tell if the project is of certain "type". A nature also has install/uninstall methods. This gives you a convenient place to implement all actions that need to happen on the project when your technology is enabled. Why is that convenient? Because a third party can simply add the nature without knowing what else is necessary to configure and your code takes care of the rest.
Plugins write to [project]/.setting or [workspace]/.metadata/.plugins locations in different ways. The file formats are never documented as they aren't meant to be manipulated directly. Some plugins re-use the common ProjectScope and InstanceScope classes to read/write the data. Some read/write on their own. I would start with what information you are trying to read, figure out which plugin it belongs to and then see if there is public API in that plugin for accessing that information. Reading these settings directly is almost never going to be the correct approach.