When editing JSF XHTML files and using autocomplete for resource bundle keys, IntelliJ seems to scan the whole project including libraries for ALL property files - this is very annoying because you get many thousands of irrelevant keys mixed up with your own small JSF declared resource bundle. Is it possible to ignore library property files? This was default behaviour in Netbeans for example, one of the things that really annoys me in IntelliJ.
Unfortunately, it's not possible to control it in the current IDEA version (12), all the files are always scanned. Please submit a request to make it configurable and we'll consider implementing it in the future updates.
Related
I'm probably missing something very basic here, but I've spent quite a while searching for just about any term I could come up with.
I wanted to check out Dart and Dart.Polymer, so I grabbed some examples from various tutorials. I managed to get everything working, but it seems ALL HTML/JS/CSS content from custom Polymer elements and paper-/iron-/... elements get pasted to index.html, along with various other JavaScript stuff.
This leads to my index.html being 16.000+ lines long in release mode builds, (20.000 in debug) in this Dart Academy Tutorial, and here is the corresponding source in GitHub
The tutorial also links to a live version that has pretty HTML/imports.
The same happens with the basic Polymer sample project in Webstorm.
My different setups:
Windows 10 and Ubuntu 14.04 (tried both)
Dart SDK current stable and dev version
pub build --mode:release and debug, from commandline and within Webstorm
various transformers, various orders, various dependency versions in pubspec.yaml
Aside from the index.html file my output folder seems fine, elements are present in e.g. output_folder/build/web/packages/polymer_elements/.
I know that everything that is compiled into the index is necessary, but why does it not generate links to the files in the created build/polymer_elements folder? I assume it is possible and the live versions of the examples I found have not been edited manually to link to all elements and scripts and cut them from index.html. I know it probably does not even affect load times in a significant way, but it still bugs me.
Thanks for any help in advance, don't be shy to point out if I read over something very basic or just did not search for the right term :D
This is a deployment optimization, similar to the vulcanize tool for polymer js, except that its the default in Dart. Html imports create tons of extra requests which is slower than just downloading the one large file.
Inlining transformed code (JS/CSS) is normal behavior and none of the options to dart2js will affect this.
I believe the demo output linked in the tutorial you mentioned was unfortunately not the actual dart output. I believe https://polymer-checkout.firebaseapp.com/ is a demo of the original polymer version, not the dart version.
Why must we run a build.dart script to develop with web_ui ?
I thought it was an frequent noob question about web_ui but I do not find an answer about that. Maybe I miss some web resources or articles.
With Angular.js or Polymer MDV don't need it, and they use bidirectionnal binding.
With future version of Web_ui or Chronium version, does the build.dart will be still necessary ?
This side of web_ui disappoints me a little bit and I feel it could discourage developers to use it.
Another point is I don't like project organisation with HTML sources in "web" and another "web/out" directory ? Can we configure the script to have another out directory like "templates" for templates and "web" for output ?
Than
If you want to use #observable, then you need to run a code generation step. Because Dart is a more structured language, it's not currently possible to add methods or change structure of an object at runtime. Therefore, we must run through a small code generation step that converts #observable into the code to track and notify for changes.
Polymer doesn't need this because they can alter the object at runtime. Also, Object.observe is landing in V8 (already landed?) which means the runtime performs observability automatically.
We know this is a problem, and we have a few ideas on how to solve it.
Build a devserver that does the building for you automatically.
Implement (eventually) mirror builders, which would allow you to alter program structure at runtime.
Option 1 is a near-term solution, and option 2 is a long-term solution.
I've just discovered this property in MVC projects, but I'm having a hard time determining if it has any real effect. The following makes me believe this property has almost no real effect out of the box:
It does an in-place compilation of the site (AFAICT), and leaves the site "updateable" so that the markup files are not affected. This is important for in-place compilation so the sources aren't wiped out.
Because it's in a WAP project, all the code files will be compiled into the project's output assembly anyways (unless they're in App_Code, but that's just odd).
So the sources in the project were already compiled, and the markup files aren't affected. What is the actual impact of using MvcBuildViews?
When <MvcBuildViews> is set to true, building the web project results in errors if the views contain any server-side code issues. Note that this includes C# errors (compile-time / type-safety / etc.), but not JavaScript errors, as those are intrinsically non-compiled.
This feature works for Razor and WebForms views, but it seems to have no effect when the Spark view engine is being used.
I need to translate SAP BO InfoView interface. The language we require doesn't have native BO language pack.
I discovered a bunch of .properties files, translated them, but not all of the texts was converted.
Maybe someone could give me some advices, or some ideas for solution?
Thanks.
I would think any text not in the properties or xml config files are in 2 main places:
Hard coded in the JSP files. A general search and replace should work at finding where these are.
The Java applet WebI controller. This one is compiled and packaged jar. I believe this is where the text that you haven't been able to translate yet resides. This one will be trickier to update and changes to it will most likely end any support from SAP if you run into troubles.
I have started using MonoDevelop for F# on a Mac. It's pretty cool, except for the fact that it crashes quite a lot. One thing that is bothering me is that I can't change the order of the F# source files in a project. Is this possible? It will make organising projects a bit of a nightmare if it isn't.
Yes, you can reorder files. There is a special tab for doing that in project options (under the build tab).
Unfortunatelly, this cannot be done using the file browser (because MonoDevelop automatically sorts files by file name and there is no way to disable it).
Assuming you're using MonoDevelop 4.x and a recent version of F# Binding, you can drag and drop to move files into a correct order (no shortcut key supported yet).
Here is the original issue and the pull request if you're interested in (big thanks to Dave Thomas for implementing this).
As a last resort, you can open fsproj files in a text editor and rearrange xml nodes corresponding to source files.