I was wondering what the difference between these two attributes is when using the "aurelia-i18n" plugin
They are both defined in my main.ts inside the i18n plugin "startup"
lng: "en",
attributes: ["t", "i18n"],
fallbackLng: "en",
However, the i18n attribute only seems to work in "Views" and doesn't work when used inside a custom element. However t does work in custom elements. I was wondering if there was some kind of difference between these two, that is not described in the docs?
True there is/was a bug filed for that but in the meantime got resolved with the latest release. An accompanying issue is this here, which is also documented with a recent docs update
No other differences should be present, and the sole purpose is to give developers the freedom to chose other aliases.
Related
I'm part of a team that's using NativeScript and angular and we keep getting errors that look like:
Error: com.tns.NativeScriptException: Attempt to use cleared object reference id=<some-object-id-number>
From some research it's because we use markingMode: none in order to speed up our application. We want to keep using this so we need to find the source of the errors. From the documentation, it comes from creating a native object then wrapping it in a JS method so the garbage collector removes the native object in the method but since it's still being referenced an error is thrown. The documentation also indicated that this most likely stems from using plugins that haven't adapted to markingMode: none. The plugin I believe that's causing this is the nstudio nativescript-checkbox plugin. So I looked through the source code to try to find the native options that fit the criteria and my issues are the following:
I'm not sure if I'm finding all the native objects.
I don't know where to release them in the code.
I'm not sure if this plugin is the only one that's causing issues (we use a lot of plugins and all of them are pretty integral to our code).
I scoured our code base and couldn't find any instances where this may be a problem, but I could be wrong.
If anyone has experienced this markingMode: none issue, specifically with plugins, I would love to hear how you dealt with it and if you had any tips/suggestions moving forward. Here's the documentation detailing this issue:
https://docs.nativescript.org/core-concepts/android-runtime/advanced-topics/marking-mode-none
The NativeScript developers said it was fixed in this bug fix with an update, but I haven't noticed a change:
https://github.com/NativeScript/NativeScript/issues/7125
UPDATE: I commented out the checkbox plugin and no error, this is definitely being caused by the plugin
Removed all instances of the checkbox component and the side navigation bar and made our own custom components for them.
This question is not an exact duplicate, it is a "translation hub" for non-obvious questions:
About core version: this question is about "How to check at runtime", but there are good answer at this other question: "How to find the exact version of D3 given the minified file?".
About module version: "D3 is a collection of modules" (see official D3 API documentation), module is the correct term, but you can use this question: "How to find out about loaded d3.js extensions and their versions at runtime?".
There is a property like d3.version for "core version"? or some "per module" property or method to check version? (imagining for example something like d3.csv.version)
The API docs show nothing about it.
PS: supposing that it is stable and can be checked for example in embedded D3 like Plotly.d3.
You're correct, you can figure out the version using d3.version.
Just checked using console.log(d3) to see all the methods and properties available, and version was listed.
Here's a fiddle: https://jsfiddle.net/3e42bxom/2/
I saw some post on SO referring to xPath templates for PHP. But the version I am currently using (4.1.1) does not have those templates anymore.
Does somebody know how to add custom rules from this version on?
Thanks in advance
It is no longer possible to add custom rules for PHP. We'll eventually add the support of writing custom rules in Java (as it is currently the case for Java and COBOL). See http://docs.codehaus.org/display/SONAR/Extending+Coding+Rules.
Note that if you think that your custom rules might benefit others, you can submit them on the developer list (http://www.sonarqube.org/resources/join-our-community/). If we find them valuable, we'll implement them.
I'm developing a site for my company and I also need to modify the native component "mailto" to fit our needs.
I'm working with a joomla 2.5
I was wondering if future updates occur, what will happen to the lines I've added, for example, in "\components\com_mailto\controller.php"...
I haven't find answers on the net.
Also, for the same reason, I've modified the default layout of an article. Should I rename it? and if yes, how, because I couldn't do it (when I've tried the article did not display).
Thanks for your help
Before starting to edit core Joomla components, should should always have a look at the options you have. I don't believe in editing core file as it simply causes problems for updates when released, therefore in my opinion, you have 2 options:
I always make a note of all my requirements and start looking for a 3rd party extension that caters for my requirements.
If I cannot find a 3rd party extension and don't particularly want to start digging into it's code, I would go with developing a plugin. Plugins are used to manipulate the behavior or something and therefore come in extremely handy for when you would require core editing.
Editing the layout of an extension view is completely fine, but it's strongly recommended you make a Template Override so that if the extension does ever get updated, your changes won't get overridden.
So to answer you initial question, any line you have added to the controller.php file will get overridden when you decide to update the extension.
Hope this helps
While the answer from Lodder is totally valid, as a last resource you can also consider forking the com_mailto as a separate component.
This has some disadvantages:
you need to rename all the files involved (controllers, models, views)
you need to maintain it and keep in in sync with future updates (consider than you are now on 2.5.x and in a year you might want to upgrade to 3.x).
It seems like there is no ComboBox component in Cappuccino framework.
I see that there are many widgets in Cappuccino that are not used very often (like Predicate Editor), but ComboBox is missing. Is it abandoned on purpose?
Is it possible to transform CPPopUpButton into Combobox somehow?
A CPComboBox actually does exist. It's just not in the latest stable release yet…
Here's a link to the class: https://github.com/cappuccino/cappuccino/blob/master/AppKit/CPComboBox.j
We're working hard on getting the next major release out the door, please be patient or if you'd like to try out the latest release candidate you can here:
https://groups.google.com/d/topic/objectivej/svifpqxvjfA/discussion