I really like meteor-angular, however, in the following code snippet, I think there is still friction when persisting changes back to the db. For example, in this code sample:
saveParty(name: string, description: string) {
Parties.update(this.selectedParty._id, {$set: {name: name, description: description}});
}
it is going to difficult to manually type "name: name, description: description" if there were a large number of fields.
Is it possible to do something like (kind of like what breezsjs does):
saveParty() {
Parties.save(this.selectedParty);
}
or better yet:
saveParty() {
this.selectedParty.Save();
}
Yes :)
Take a look at AngularMeteorCollection methods here - http://angular-meteor.com/api/AngularMeteorCollection#methods
AngularMeteorObject methods here - http://angular-meteor.com/api/AngularMeteorObject
and
And the examples at the bottom
Related
I use Xpath to get some elements of an XML. Is there a similar way to obtain it for an object/hash?
I need get the value of a JSON object using some kind of selectors, which would need to be flexible enough because this JSON won't always be structured the same way.
Something like this is xpath would have been //data/children/*/title for instance.
Is there something similar for objects? I don't want to convert my object to an XML, it would bring other problems.
Ruby 2.7 introduced pattern matching, which might solve your problem. For example:
data = {
data: {
children: [
{
title: 'Find me'
},
{
title: 'I am wrong'
}
]
}
}
case data
in {data: {children: [{title: 'Find me'}, *rest]}}
puts 'found'
else
puts 'not found'
end
In this case, Ruby checks the data structure and prints 'ok' if {title: 'Find me'} is in children key.
I take issue with the default line breaks I get from my vim setup. I think the only relevant plugin I'm using is vim-ruby.
I want code that auto-indents like this:
let(:account) do
create :account,
store: build(:live_store,
shop_version: build(:shop_version,
name: "Example"
)
)
end
to instead auto-indent like this:
let(:account) do
create :account,
store: build(:live_store,
shop_version: build(:shop_version,
name: "Example"
)
)
end
Does this make sense or am I off in the weeds? I find the defaults very ugly and especially frustrating when trying to enforce 80 character lines.
Thank you!
The reason that vim-ruby indents your example so deeply is to support this coding style:
let(:account) do
create :account,
store: build(:live_store,
shop_version: build(:shop_version,
name: "Example"))
end
A lot of people like this "hanging" style, which is why it's how vim-ruby indents if you use round brackets with the first argument on the same line. You could, as #Amadan points out, put all the arguments on new lines:
let(:account) do
create :account,
store: build(
:live_store,
shop_version: build(
:shop_version,
name: "Example"
)
)
end
Alternatively, my preferred supported indentation style uses curly brackets:
let(:account) do
create :account,
store: build(:live_store, {
shop_version: build(:shop_version, {
name: "Example"
})
})
end
There's a lot of different combinations of indentation preferences and we're limited in how much variability we can support (I'm a maintainer) -- the code is old and full of edge cases. I'm afraid these three styles are basically it, and I hope you can tweak your coding style to reach a compromise. It might be that at some future point I sit down and try some radical changes, but it's a difficult project to find time and energy for.
I have found a reasonable workaround. Vim will indent automatically the way I want if I use hash literals in the code. For example, typing the above example like this works fine:
let(:account) do
create :account,
store: build(:live_store, {
shop_version: build(:shop_version, {
name: "Example"
})
})
end
This feels like a reasonable enough compromise.
I'm trying to test an API response where key values are randomized alphanumerics. This is making it difficult for me to drill down into the JSON response to get the data I want to test.
I am using SuperTest/Mocha/Chai. At this point I'm just trying to test to see if the property 'id', 'name', and 'pattern' exist, and to verify the values of those properties.
Unfortunately since the parent of those properties is a randomized value, i've been unable to access it.
I'm new to API testing in general, so I apologize if I'm not including some important information. Normally I would do something like this:
Example of expects I normally write:
end(function(err, res) {
expect(res.body).to.have.property('id');
expect(res.body.id).to.equal(0);
}
So far, the only way I've found to do it is to put response.text into a variable, then use split and splice to separate out the data I want. This is ugly and probably inefficient.
Example JSON I'm working with:
{ idTag1: 'randomValue',
idTag2:
{ 'randomValue':
{ id: 'an integer',
name: 'a basic string',
pattern: 'a basic string'
}
}
}
While creating a document that is got from web interface, it does not rightly typecast integer date and other type. for example
{"_id": "<some_object_id>", "name": "hello", "age": "20", "dob": "1994-02-22"}
Since attributes are entered dynamically, their types can not be prejudged. Is there any way I can get them entered from client side, like
{"_id": "<some_object_id>", "name": "hello", "age": "$int:20", "dob": "$date:1994-02-22"}
Any help is highly appreciated.
Since you appear to be concerned about the strings that come in from a form such as a POST, the simple answer is that you cast them in Ruby.
If the field is what you expect to be a number then cast it to an int. And the same goes for dates as well.
Your mongo driver will correctly interpret these and store them as the corresponding BSON types in your MongoDB collection. The same goes in reverse, when you read collection data you will get it back cast into your native types.
"1234".to_i
Date.strptime("{ 2014, 2, 22 }", "{ %Y, %m, %d }")
But that's be basic Ruby part.
Now you could do something like you pseudo-suggested and store your information, not as native types but as strings with some form of type tagging. But see, I just don't see the point as you would have to
Detect the type at some stage and apply the tag
Live with the fact that you just ruined all the benefits of having the native types in the collection. Such as query and aggregation for date ranges and basic summing of values.
And while we seem to be going down the track of the anything type where users just arbitrarily insert data and something else has to work out what type it is, consider the following examples of MongoDB documents:
{
name: "Fred",
values: [ 1, 2, 3, 4],
}
{
name: "Sally",
values: "a"
}
So in Mongo terminology, that document structure is considered bad. Even though Mongo does have a flexible schema concept, this type of mixing will break things. So don't do it, but rather handle in the following way, which is quite acceptable even though the schema's are different:
{
name: "Fred",
values: [ 1, 2, 3, 4],
}
{
name: "Sally",
mystring: "a"
}
The long story short, Your application should be aware of the types of data that are coming in. If you allow user defined forms then your app needs to be able to attach a type to them. If you have a field that could be a string or a Date, then your app need to determine which type it is, and cast it, or otherwise store it correctly.
As it stands you will benefit from re-considering you use case, rather than waiting for something else to work all that out for you.
Found a couple of questions (and answers) on this: How is internationalization configured for Hogan.js?
,etc.
but non in particular that take word order into account. I need the ability to:
step 1. given a key -> lookup a sentence in a particular language.
step 2. this sentence may contain {{var}} , which need to be
substituted by json-values.
step 2. alone is general mustache-templating.
step 1. alone could be done with several techniques, but I prefer techniques that don't involve any specialized code outside of the Mustache/Hogan engine (in combination with a i18n-resource bundle of course) . Hogan seems to support this with something like: (from url above)
var template = "{{#i18n}}Name{{/i18n}}: {{username}}",
context = {
username: "Jean Luc",
i18n: function (i18nKey) {return translatedStrings[i18nKey];}
};
However to combine 1. and 2. in this example I would want translatedStrings[i18nKey] to return a string which potentially contains {{<some expansion>}} as well.
Someone knows of an elegant way to do this?
Rationale:
Often languages differ a lot in word order, etc. which makes for complex templates without this ability.
The latest version of Hogan.js will handle Mustache tags inside the result returned from a lambda. One minor change to the code in your question however, is that the result of the lambda should be a function in order to modify the string:
var translatedStrings = { name: "Nom {{rank}}" };
var template = "{{#i18n}}name{{/i18n}}: {{username}}",
context = {
username: "Jean Luc",
rank: 'Captain',
i18n: function() {
return function (i18nKey) {return translatedStrings[i18nKey];};
}
};
document.write(Hogan.compile(template).render(context)); // Nom Captain: Jean Luc
I created a jsfiddle that demonstrates this with the latest version.