I'm wondering how to remove certain files form IntelliJ's autocomplete. More specifically things fetched via Maven. As an example, replace will generate a long list of declarations:
Most of which are random declarations of variables and functions in JS-files which come from Maven dependencies (I'm developing Confluence plugins, hence the Confluence dependencies). What I'm wondering is how I make IntelliJ ignore all these files? For files in the project I can simply mark the directory as ignored but since these files are in my Maven repository I can't do that.
You might want to try the scope setting in IntelliJ to exclude files coming from libraries or other sources.
The scope of a library defines the set of files and folders in which the library is considered as library, that is, it is write-protected, excluded from check for errors and refactoring, affects the completion list and highlighting.
By default, all predefined libraries and libraries downloaded from within IntelliJ IDEA provide completion, resolution, highlighting and are treated as libraries in any file within the project. In other words, their usage scope is the whole project.
Libraries that you create yourself are not considered libraries in any of the files unless you specify their usage scope explicitly.
Open the Settings dialog.
In the left-hand pane, expand the JavaScript Libraries node and select Usage Scope.
In the right-hand part (on the Usage Scope page):
To make the library available in all the files within the project, click the Library cell in the topmost (Project) row and select the library in the list that appears.
To specify a narrower usage scope, expand the nodes in the File/Directory column to see the folder or file you want to limit the library usage scope to. Click the Library cell to the right of the corresponding folder or file and select the library in the list.
Click OK in the Settings dialog.
https://www.jetbrains.com/idea/help/configuring-javascript-libraries.html#d76972e18833
Related
In IIS and therefore VS, there are virtual directories which allow simplified, virtual, relative referencing in script tags. They are handy. In WebStorm you can get the same effect with Project Directories and then marking your project root as a Resource Root. If you do this, you also get coding assistance in the text editor.
WebStorm also has External Libraries, what is the point of these?
Is this for when you have a link to a CDN in your script tag and you want to get coding assistance? If you already have Project Directories, what is the point of External Libraries?
I've seen this answer and I kind of get the different modes of referencing/inclusion, but I don't get the big picture. What is the core reason for the External Libraries vs the Project Directories?
Is this for when you have a link to a CDN in your script tag and you want to get coding assistance?
Yes, this is the most common case - WebStorm can't use online resources for code assistance, it needs to have the corresponding javascript files available locally. So, if you don't like to pollute your project folder with all these library files, you can have them stored outside of your project and set up as libraries.
What is the core reason for the External Libraries vs the Project Directories?
See above - external libraries allow storing library files in an arbitrary location outside your project folder and still get code completion/highlighting/etc. Please also see the answer you refer to:
Note also that libraries are 'light-weight' as compared to .js files in your project - they are treated read-only, have the inspections turned off. Plus, you can assign documentation URLs to them, enabling external documentation for library code. So, even if you have your library files in your project, it might make sense to add them as libraries
see also this blog post
I have common asp.net mvc project.
I have there one module that contains handlebars templates, javascript modules and stylesheets.
This module is used into different pages and placed somewhere inside div tag.
The new requirement is to use this module into other solution. But I do not want just copy and paste all files related to the module (js, html, css) because it would be hard to maintenance it into different solutions.
So, my question is in what way I should organize this module to be declared only once and to be used into different solutions.
I've had the same requirement before and this is how I dealt with it:
Move your shared content
In my solution, I added a new Shared folder and created a Shared project. You don't necessarily have to move into a new project, I just did this because the shared project also included shared MVC logic.
Add linked shared files to the solutions
It's important to know that this step is optional, it's just that it helps developers in that the files are still in the expected place. Now that you have for example: Project1, Project2 and Shared. Now in Project1 (for example), add your files back in individually. But follow these steps:
Right click the folder you wish to add the file to
Hover over Add then select Existing Item
Navigate to the file in the Shared project and select the file
Before clicking 'Add`, notice the arrow
Click this, and select Add as Link
The benefit of this is that when you click on the file in your solution explorer within Project2, it will open the file in Shared.
Add pre-build events
In each project using the Shared files you will need to add Pre Build Events. Currently, although the project contains a reference to the shared file, it won't actually do anything when you run the project. The solution to this is build events:
Right click your project and select Properties
Select Build Events in the menu
In the Pre-build event command line section enter the following:
xcopy /R /E /Y "$(SolutionDir)SharedProject\Scripts" "$(ProjectDir)Scripts"
To explain: this will copy the contents of your scripts directory in your shared project, and add it to (or replace) your current projects scripts directory. You will need to add a line for each folder (e.g. HTML, CSS, etc)
Handlebars templates in ember.js applications are within "script" tags. Third party widgets, ads, and whatnot often is another "script" which document.writes something in the place it's inserted.
Script withing a script tag will not work, so is there a way to handle then within ember applications?
For the purposes of writing maintainable, DRY code, an Ember app of any real size or significance should be built using a build tool like ember-cli or brunch. These build tools will compile the application files (including templates and vendor files) from multiple directories. I'll cover those, then I'll cover a couple of ways in which you can include widgets/scripts without a build tool.
1) Whilst the Ember Guides show you how to define your templates using script tags, that's not an efficient or effective way to manage your application's templates (unless you're building an app for learning purposes or a JSbin demo, etc, when you need to put everything inside a single file). Build tools like those mentioned above use resolvers to watch your file directories and compile the templates to the Ember.TEMPLATES object, which is where your application would access them anyway.
These build tools usually have separate directories in which to place your vendor files (e.g. third-part widgets), which will usually be watched for changes and compiled into a vendor.js file that is included in your index.html page. You can also use dependency management tools like NPM and Bower to streamline this process. In both situations, the plugin methods will be accessible throughout your application.
2) If you really don't want to use a build tool then just include the script tags on your index.html page just before the closing body tag and any methods will be accessible on the window object inside your application. This is obviously not effective if you're trying to place a widget like a social sharing button in a specific place on the page.
3) Another approach when you're not using a build tool would be to run the $.getScript() method (see here) inside a view or component on the didInsertElement event. This is probably the best way to include widget-like scripts at particular places in your template. Inside the view you can use this.$().find('.some-selector') to target specific elements inside the template or this.$() to target the view's element itself.
More info:
Templates in Ember CLI
I would like to use meteor with a bootstrap admin, i.e. a bundle including several bootstrap plugins, script and everything typically made as a kind of framework for developing a web application.
Usually those bundles comes with a lot of dependencies, such as external links for fonts, IE hacks as well as their own shipped file of bootstrap, jQuery and other stuff. If we were in a regular php-like framework it would have been fine.
But in order to make such a template be "native" on meteor, I thought to refactor it in such a way that local dependencies (script and css basically) are stored into folders and not loaded via a <script src="…"></script> tag (otherwise the local path would not be found) but I doubt it is really the best practice, this is why I do consider 3 options:
To use the project/public folder in order to store all the bundle's dependencies (as if it would have been in php for example)
I might refactor the bundle's code by removing any script or style tag aimed to import the js or css into the page and add the corresponding js file aside so that meteor will dynamically load it during at runtime
Like in option 2 but instead of using the bundle's jQuery source files I would install the official jQuery's package for meteor (if existing).
The first (1) option should be the quickest one to get something running but it would not be very meteor native. The advantage however would be to keep the code near to the original one and being able to upgrade once a new version of the bundle would be released.
The 2 other options would be much more elegant (especially the third one) but it would involve a lot of refactoring and induce the risk of introducing bugs I did not expected.
My preference for now is the first option one but I'm afraid of not seing the drawbacks of this approach. Does someone have any experience in importing manually the CSS and JS files the "old fashion way" in meteor ? What is the risk of such an approach compared to using the "place in folder to include" way of meteor ?
I'm building a fairly large-scale JavaScript Backbone.js app with this folder organization:
app
index.html
libs
underscore
jquery
[...]
src
utils
modules
[...]
The index.html file basically loads up all the Backbone.js Routers etc. and instantiates AMD modules etc.
Often however, I find the need to create small applications that basically share dependencies with the Big app.
Suppose I need to create 3 small experiments (separate pages) that all load the same usual suspects (underscore, backbone and a couple of util libraries and modules I've written).
They may though differ in: 1) how they extend these JavaScript libraries, 2) what gets instantiated and 3) markup and interaction.
How do I keep this experimentation DRY?
How do I set up this "extendable Template"?
In my opinion, this is where having a good build system comes in. The more complex your setup, the more useful it is to be able to set up configuration files that can keep your dependency management consolidated in one place. This becomes particularly important when:
You need to load the same sets of dependencies on multiple static pages, but your dependency lists change often during development.
You need to be able to easily create compressed versions of the dependencies for a production version. I find this is pretty important with Backbone, because the uncompressed versions are really big but quite useful during development.
I've generally used Apache Ant for this, but there are lot of build systems out there. What I've done in the past is:
Set up an index.tmpl.html file with the core HTML markup and placeholders for JS scripts, CSS files, and underscore templates.
Make a build.properties file that defines my dependency lists. You can group them in different ways under different property names, e.g. lib.scripts.all or util.scripts.all.
In my build process, create a new index.html file, based on index.tmpl.html, with <script> and other tags to load my dependencies. I have different targets to load the raw files or to compress everything into a production-ready single script file.
You can see an example of this setup in this Github project.
If I understand your requirements, you could set up a similar build file with a few tweaks to allow you to set a) the HTML template to use (your default index or another with experiment-specific markup), b) the output file, c) the specific sets of dependencies to load, d) additional dependencies to load, e.g. experiment-specific modules or initialization scripts. You could set these properties up in a specific target (if you think you'll reuse them a few times) or just specify them on the command line when you invoke ant, via the -D flag.
This would allow you a great deal of flexibility to re-use different portions of your code, and has the added benefit of making it easier to move an "experiment" into your core production code, just by including it permanently in your build process.