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.
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
It seems that in ASP.NET Core MVC, if I want to use a View Component, I have to put them in Views\Shared\Components\[ViewComponentName], and then name the file "Default.cshtml".
This is rather frustrating, as in the beginning of a large project I am helping to port from Perl CGI, I'm creating a good number of View Components and having five tabs in Visual Studio all named Default.cshtml is confusing.
Is there any way I can avoid this naming convention? Maybe even take them out of their folders so that the file will look like…?
Views\Shared\Components\[ViewComponentName].cshtml
I don't know if there are just some settings I can tweak or what. For the most part, I'm very new to ASP.NET, and still figuring things out. Using ASP.NET Framework instead of ASP.NET Core is an option, though I'd prefer not to, as a lot of the boilerplate is already done.
The documentation on ViewComponents says this:
We recommend you name the view file Default.cshtml and use the Views/Shared/Components/{View Component Name}/{View Name} path.
Which makes me think that there is a way around this restriction, but it doesn't specify how that would work or what it would look like.
Like Nic I agree that having several to dozens of files named default.cshtml is annoying. More so is having several to dozens of folders with just a single file in each folder
Components/ViewComponentName/default.cshtml
Components/AnotherViewComponentName/default.cshtml
Components/AThirdViewComponentName/default.cshtml
et cetera
I understand the reasons for the recommended name and location...but I simply disagree and will accept the consequences. For those who share my cavalier attitude, View() allows you to specify a View name
return View("Schools", items);
or even to specify a path to the View if you put it in a non-standard location
return View("/Pages/Components/Schools.cshtml", items);
I'm using Razor Pages but I'm sure this works for Views/Shared/Components as well.
I have few separate apps that have absolute same logic and functions but have different icons and some design elements. The problem is that when some changes to logic and functions are made - I need to manually add this functionality to all apps and after this - I need to resubmit each app.
Maybe there is some way to separate all logic so I need to change it only in one place, and all my apps would get it?
In my opinion the neatest solution is to have one codebase with multiple targets. Yes you still have to resubmit each app when you change some code, but you would have to do that anyway would you not?
You can pick one of your apps to convert to your 'main' codebase.
E.g. Pick app one and duplicate the target multiple times:
You will want to change your scheme names after doing this:
You can set the bundle identifier and deployment info separately for each app just as you did before, and icon sets:
To differentiate between your apps in code you can use compiler flags (Target -> Build settings - Other swift flags) :
You can then do something like this in your code:
#if APP_ONE
...
#else
...
#endif
One solution (though not necessarily the best) is to have a single code base. I.e. you have only one physical copy of each of your classes. All your code files are located in a folder of one of the projects and the other projects use those files as well. It's just a matter of setting paths.
In this structure when you change or add some code in one of the projects (and doesn't really matter which one), all the projects are updated.
The image catalogs are different for each project.
The disadvantages of this approach are that you still need to build and submit each app separately and when adding a new class you need manually to add it to all the projects. Otherwise they won't compile.
The advantages are that when building an app, you build only one app and not all together (less time). It's also easy to manage changes to a specific app - you can just add some extension with additional functionality to only one project - the rest won't need it.
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.
if I'm using rails 3 which uses asset pipeline to compile all
Javascripts, does that mean I can have only one Knockout view model for my entire application? If not, how do I specify which view model is binded with which view? In the tutorial code, it looks like 1 view model is bound per page, but that doesnt work in rails since all JS are loaded upon first page load.
No, you do not need to include all javascript on every page! This is a very bad idea.
There are many methods for limiting javascript to a single page, you should pick one:
Method 1
Method 2
Method 3
Please, please, please do not try to load all your javascript on every single page.
Update (after your comment below):
I think you are confusing a few different things here.
First, even if you compile all your javascript into a single gzipped/uglified file, that still doesn't force you to use one knockout viewmodel for your entire application. That file can contain multiple viewmodels. They don't even need to know about each other.
Second, the way the rails pipeline works is by concatenating related or dependant javascript files together. It does this to reduce the number of requests the browser has to make to get the javascript it needs for each page. It doesn't necessarily mean all your javascript becomes one file. Just that the javascript for each page become one file. For more information, check out the Rails Asset Pipeline Documenation, it has a great explanation of how it works and how to use it properly.
Third, neither of these things mean you need to write all your javascript as if it were one file. In fact, this is a bad idea. You should seperate your javascript into relevant files by functionality. This allows them to be reusable, as well as eases development work.