Given a compiled view model hierarchy instantiated with this data:
"applications":[
{
"application_id":1,
"name":"Test Application 1",
"description":"An Application For Testing",
"settings":[
{
"name":"Application 1 Setting Key 1",
"value":"Application 1 Setting Value 1"
}
],
"projects":[
{
"project_id":1,
"name":"Test Project 1",
"description":"A project for testing 1",
"settings":[
{
"name":"Project 1 Setting Key 1",
"value":"Project 1 Setting Value 1"
}
]
}
]
}
]
I'm having difficulty tapping into the observables at levels farther down in the tree.
No problem observing changes to properties of an application:
$.observe(data.applications(), ".[]^*", ...
But how about changes to properties of a setting under an application? These are all FAILs:
$.observe(data.applications().settings(), ".[]^*", ...
$.observe(data.applications(), ".settings.[]^*", ...
$.observe(data.applications(), ".settings().[]^*", ...
I see the documentation specifically mentions parentheses will not work in chained paths like the last example so there wasn't much hope for that last one.
I seem to be able to get away with this:
$.observe(data.applications(), ".[]._settings.[]^*", ...
and if that's the only way please confirm, but the underscore makes me feel like I've tapped into underlying/protected/unofficial representation of data path. Any other way to chain compiled vm paths?
Given that applications() returns an array, as does settings(), you can't write:
$.observe(data.applications().settings(), "[]^*", ...
If you want to target a particular application, such as data.applications()[0], you could write:
$.observe(data.applications()[0].settings(), "[]^*", ...
If you want to target all the settings properties under any application, you can write:
$.observe(data.applications(), "[]._settings.[]^*", ...
You are right that _settings is supposed to be 'internal'. The intended design was indeed to let you write:
$.observe(data.applications(), "[].settings.[]^*", ...
but there is a currently a bug which prevents this from working. An upcoming update will either fix this bug, or propose a slightly different pattern. For now it would be better to stay with _settings, which will at any rate continue to work after the next update. Look out too, after the next update, for possible new documentation topics on the [].* wild cards and other related features...
BTW if you want to listen to changes after modifying the data hierarchy higher up (for example the applications() array - which you might change using the merge() feature for VMs), then you will need to put a ^ at an appropriate level in the path, to listen to any changes below that level. For example you can write
$.observe(data.applications(), "[]^_settings.[].*", ...
or
$.observe(data.applications(), "^[]._settings.[].*", ...
or
$.observe(data, "_applications^[]._settings.[].*", ...
Another option is the ** wild card - which you can use at any level to show all changes below that level:
$.observe(data.applications(), "**", ...
or
$.observe(data, "**", ...
or
$.observe(data, "_applications^[].**", ...
Related
I'm writing a nuxt module following this guide.
Now I would like my module to add a proxy rule to the host application. Its a lot of guesswork and nothing has done the trick so far. I tried
nuxt.options.proxy.options.push(
{
target: 'https://target-url.com',
changeOrigin: true,
pathFilter: ['path/to/match']
}
)
}
but my IDE complains that proxy is not a known property of NuxtOptions. I did shorten the above code for the sake of this post. In my code I also made sure the respective objects exist before assigning something to them.
next best guess (based on the example for adding a css library) was to do the same thing, but on the runtimeConfig like so:
nuxt.options.runtimeConfig.proxy.options.push(...)
no complaints by the IDE anymore (duh, the runtimeConfig object is of type any) but no sign of the proxy actually working.
I noticed a property in Storybooks Options Docs called selectedPanel which I assume will allow me to pre-select an addon panel.
I'm unclear on how to use it. The example is:
options: { selectedPanel: 'storybook/a11y/panel' }
What I don't understand is where the 'storybook/a11y/panel' string comes from. What if I want to preselect the 'Source' panel?
For anyone looking to default to the knobs panel: selectedPanel: 'storybookjs/knobs/panel' appears to work!
I've encountered the same issue and managed to find out that the panelId can at least be found in the addon's register source code step. For example, I wanted to open Readme tab for certain stories.
I ended up finding the id of the panel in registerWithPanelTitle.js, and then using it with the storiesOf API like this:
.addParameters({
options: { selectedPanel: 'REACT_STORYBOOK/readme/panel' },
})
For a11y, it can be found in constants.ts.
Although, I've searched for those in the distributed node_modules versions in my case.
P.S. If you want to reorder the panels for all of the stories globally, the list that the addons are imported in handles it.
I was using the #storybook/addons-essential in main.js and simply added #storybook/addon-controls to the front of the addons array option, like so:
module.exports = {
addons: ['#storybook/addon-controls', '#storybook/addon-essentials'],
...
}
This puts the controls tab first, which is auto-selected.
I am using the simple create script to add the script to the repo manager successfully : https://github.com/sonatype/nexus-book-examples/blob/nexus-3.x/scripting/simple-shell-example/create.sh
and passing a JSON file like this
{
"name": "apachesnapshots",
"type": "groovy",
"content": "repository.createMavenProxy('apachesnapshots-io',
'http://repository.apache.org/snapshots/', 'default' ,org.sonatype.nexus.repository.proxy.ContentMaxAge.-1)"
}
For Release repositories, it says that the Maximum component age should be -1. I am getting 1440 by default. I have figured out the parameter that i need to pass in repository.createMavenProxy() should be ContentMaxAge. But not able to figure out if it should be added at a particular position and how to set its value to -1.
You can use the Repository Manager within the API to get attributes and then change them accordingly.
To see the configuration, use a script like:
return repository.getRepositoryManager().get('my-proxy-repo').getConfiguration()
To change them, use something like:
repository.getRepositoryManager().get('my-proxy-repo').getConfiguration().getAttributes().'proxy'.'contentMaxAge' = -1
Hope it helps,
Steve
I'm trying to configure a phabricator instance, and I find that change the arcanist default template when we use arc diff can be very useful for the team.
Actually the template contains this text:
<<Replace this line with your Revision Title>>
Summary:
Test Plan:
Reviewers:
Subscribers:
# Tip: Write "Fixes T123" in your summary to automatically close the
# corresponding task when this change lands.
# NEW DIFFERENTIAL REVISION
# Describe the changes in this new revision.
#
# arc could not identify any existing revision in your working copy.
# If you intended to update an existing revision, use:
#
# $ arc diff --update <revision>
I'm googling to find any way to change this default template, but I can't find it...
There is any way to "personalize" this template?
As reported in Phabricator Task T12276 by a question from user #milianw, actually it seems there is not the ability to customize the commit message.
This is the official reason:
Please keep in mind Phabricator is an enterprise tool, and
the majority of installs (99%) are businesses who rely on the
accountability we've built into the software.
― chad, Feb 18 2017, 11:55 PM
Anyway I tried to explore the class DifferentialCommitMessageField and I've found this method producing the list of all available fields:
final public static function getAllFields() {
return id(new PhutilClassMapQuery())
->setAncestorClass(__CLASS__)
->setUniqueMethod('getCommitMessageFieldKey')
->setSortMethod('getFieldOrder')
->execute();
}
And look at all the class that are inheriting DifferentialCommitMessageField. Some of them:
DifferentialTagsCommitMessageField
DifferentialSubscribersCommitMessageField
DifferentialAuditorsCommitMessageField
DifferentialReviewedByCommitMessageField
DifferentialTestPlanCommitMessageField
DifferentialTitleCommitMessageField
DifferentialSummaryCommitMessageField
...
So maybe you can customize a field changing the related class. You can change some default values, or you can try disabling a field declaring this method in one of these classes:
/**
* This method is inherited from DifferentialCommitMessageField
*
* #override
*/
public function isFieldEnabled() {
// return true;
return false
}
In short you can try to extend Phabricator to do it. Currently this feature is not a priority for their general enterprise use cases.
Anyway, do not forgot that Phabricator is a Free/Libre and Open Source software. You have all the rights to play with the code and make some improvements. If you are really interested in this feature and you have the possibility to add this customization feature, some users may be interested in your patch, so you may also consider to propose your changes to upstream, if it works and does not introduce regressions.
Boost.Build documentation is quite laconic when it comes to testing.
All tests in my project are defined using unit-test rule.
The only property mentioned, by the documentation, is testing.launcher, but that can only disable tests' execution when set to testing.launcher=true.
How to completely disable compilation of unit-test rules? I would like to do that temporarily, for example, by setting a property from commandline. I could not find any information how to do that or any reference documentation for other testing.* properties.
If you mean disabling them by default? You can do it by adding "explicit ;" for each unit test. If you have many such targets you can save some typing and declare a rule that does it for you, plus declaring the unit test like:
rule explicit-unit-test ( target : source : properties * )
{
unit-test $(target) : $(source) : $(properties) ;
explicit $(target) ;
}
If you want something else.. I guess you need to better explain your question because I can't think of what else you could want.
As I read most of the Boost.Build documentation and the relevant part of its code I found no way to temporary disable building specific rule or the set of targets (for example by matching tests' targets with a regular expression).
It is, also, worth noting, that unit-test was deprecated in favor of the new testing rules: run, run-fail, compile, compile-fail, link, link-fail.
Now, probably, I'm going to create my own rule, as in #GrafikRobot's answer, but instead of making the target explicit I will make the rule empty in the presence of a certain feature.
I use explicit test suites for this purpose as in
explicit X ;
test-suite X
:
[ run test1.cpp ]
[ run test2.cpp ]
[ run test3.cpp ]
[ run test4.cpp ]
;
You will need to request explicitly the execution of the tests in the test-suite X using
bjam X