I am trying to upgrade from NEST 1.7.1 to 2.0.4, and I am having a REALLY hard time figuring out how to fix all the attribute errors. I simply cannot find any adequate documentation. The one available at http://nest.azurewebsites.net/ is not up to date.
I'm specifically having issues converting [ElasticProperty(OptOut = true)] and [ElasticProperty(Index = FieldIndexOption.NotAnalyzed)].
For simple strings I can do something like [String(Index = FieldIndexOption.NotAnalyzed)], but it doesn't seem like I can do the same for numeric types, and I cannot figure out how to OptOut.
Related
I'm using GWT 2.9 with elemental2-1.0.0-RC1.
The following code throws a ClassCastException at runtime:
DocumentRange documentRange = Js.cast(DomGlobal.document); // Fails
Range range = documentRange.createRange(); // Never reaches here
When I change to use an Js.uncheckedCast() instead, it succeeds:
DocumentRange documentRange = Js.uncheckedCast(DomGlobal.document);
Range range = documentRange.createRange(); // Works
The documentation for Js.uncheckedCast() says:
"You should always prefer regular casting over this (unless you know what you are doing!)."
I don't know why I'm having to use it, so I'm feeling nervous. Can someone explain how Js.cast() performs its type-checking and why I need to use an Js.uncheckedCast() in this instance?
Js.cast() is a way to cheat a bit, and do something that the Java language will not permit, but might actually be legal. Ignoring "how it actually works", the idea is that you can now get past issues where Java would complain, even if it turns out to be legit.
An example could be where you take a java.lang.Double or double and want to treat it as a JsNumber so you can call toPrecision(2) on it. Since java.lang.Double is final, it isn't legal to cast to an unrelated type, but Java doesn't know that in GWT, Double is really just a js Number. So, instead you can perform the cast with Js.cast(). The compiler will insert a runtime type check in there, verifying at runtime that your number is in fact a JS Number instance.
Another example could be trying to extend some native type that elemental2 provides, either to implement a workaround for a missing feature, or to do something browser-specific. Your new class may not extend the existing class - from JS's perspective this is okay, you are just describing the API that you know will exist at runtime. As such, we need to avoid the Java language check of "does this cast even make sense?", and just tell the compiler to try it.
On the other hand, you can "lie" to the compiler with Js.uncheckedCast(). This is used in cases where you are even asking the runtime to skip the check, and just pretend that it will work. This can let you do weird things, like treating Strings as if they were arrays, or solve cross-frame problems. No runtime check will be emitted, so instead you might just get a TypeError if a method/property is missing, instead of a proper ClassCastException.
In elemental2-dom 1.0.0-RC1, there is a class called DocumentRange, but it doesnt really make any sense - it is declared as a class, which means it can be type checked in JS, but the browser spec says that it should be an "interface" (which in JS-land means that it just is a description of a type, rather than something you can typecheck). https://www.w3.org/TR/DOM-Level-2-Traversal-Range/ranges.html#Level2-DocumentRange-method-createRange
This bug is inherited from closure-compiler, which claims that this has a constructor: https://github.com/google/closure-compiler/blob/6a418aa/externs/browser/w3c_range.js#L241-L251
The fix is for closure-compiler to refer to this as an interface, and for a new release of elemental2 to be made so you can use this.
There are two workarounds you can make here. The first is to cheat with Js.uncheckedCast(DomGlobal.document) and say "yes, I know that the Document is not instanceof DocumentRange, but that's because there is no such class as DocumentRange, so just pretend it worked so I can call createRange() on it". This is what you are doing already - it hides the fact there is a bug, but at the end of the day it works.
The "correct" answer is to declare your own DocumentRange, and do a Js.cast() to that instead. This is still gross - you have to keep your new interface around until closure gets fixed, and then elemental2 gets released, and then you have to remember to clean it up.
In this case, I would suggest lying to GWT and using Js.uncheckedCast() - there is only a single method on here, and it is unlikely to change in a meaningful way.
What is the recommended way to convert a string to an integer in Red?
One way I found is:
load "123"
== 123
Is load the best way of getting an integer from a string in Red?
Is there any danger in using load in this way specifically if the string is from an unvalidated source?
Currently, that is the only way, as to action has not been implemented yet. It is safe using load, as it does not do any kind of evaluation and the construction syntax support is very basic (covering just none and logic values).
EDIT: to action is now available from v0.6.2 on, so to-integer "123" can be used too.
What are the ways to compare the expect results with our true records using Jasmine Testing Framework?
One of the way is to use a static values within expect Parameters which is good for very basic values... But it has several limitations like it does not compare objects at runtime...
How to compare objects at runtime for its validity...???
EDIT :
it("Read JSON record with Id.", function(){
result = Database.selectRecordById (STORE_ID, id3);
expect(result).toEqual(aRecord); //cValue
});
Here is the code. Now my problem is to compare the result value to aRecord. I will get result from method Database.selectRecordById. For now i am using a static value of aRecord. I want some other way which is more reliable so that my aRecord becomes dynamic. One thing i thought is to make a database which will contain all true values... but then i manually have to see that... What could be other alternative.??
As far as I see there is nothing wrong with static values for comparing result. That is how we usually do unit testing both in Java and in JavaScript.
The actual value is what you get from the actual database/method call and the expected value is a static value. The less 'moving parts' you have here, the better. If you were to dynamically load the expected values, that can go wrong as well and you do not want your tests failing if your application because your test data load was wrong. It is also a lot more cumbersome to maintain.
Hope I did not misunderstand your question.
I am trying to call a function through javascript via my NPRuntime plugin
but when i pass an integer value to a function,chrome detects that as NPVariantType_Double while firefox is taking same as NPVariantType_Int32.
Can we do avoid this without modifying script to make sure that both firefox and chrome detects it as NPVariantType_Int32.
Short answer: no, not really. They will give it to you in the format that they decide to give it to you. I recommend you cast it to a int32.
If you're really worried about how it's going to come in and need the format to remain exactly the same, pass it as a string and use some form of lexical cast to convert it to the numeric format you need.
Remember that javascript is dynamically typed, so from their perspective it shouldn't matter. This is just one of those annoying things :-/ FireBreath "solves" this issue simply by not caring what the browser provides and converting it to the datatype the function says it expects.
Taxilian is right. Chrome and Opera(as far as I recall) are returning mainly NPVariantType_Double , even if this represents the location of an element (in pixels).You can create a function that converts NPVariantType_Double and NPVariantType_Int32 to whatever you want.
I messed up in my code - I create lots of short-lifetime objects and use MEF to resolve dependencies. As anyone with some MEF experience knows, MEF holds onto a reference on these guys. The result is the short lifetime turns into LOOONNNGGG lifetime. So, this is easy enough to fix - use SatisfysImportsOnce on CompositionContainer.
But I'd like to make this x-check part of my unit tests now so that I don't accidently add an incorrect part into the container (or perhaps I missed one in the code search I just did). Sooo... how to do this?
My code, a bit abstracted, looks something like this:
_catalog = new AggregateCatalog();
_container = new CompositionContainer(_catalog);
_batch = new CompositionBatch();
I then add parts to a batch, and call _container.Compose(_batch). I thought perhaps something like the following would work to get a count, but it always returns zero:
int nParts1 = _container.Parts.Count();
int nParts2 = _container.Catalogs.Sum(c => c.Parts.Count());
However, both of those return zero. How can I get this count for tests? It is ok if perf isn't fantastic - this is part of the test, not the running app. Many thanks in advance!
There's not a simple way to do this. You'll need to go digging around in the internal implementation of MEF to find this information. Since the source code is available (mef.codeplex.com) this is quite possible, but still not too simple.