I would like to filter an array in my XPage with serverside Javascript. Unfortunately I get the following error:
Error calling method 'filter(Function)' on an object of type 'Array [JavaScript Object]'
I have an Array of Strings like ["elem1","elem2","elem3"]
I call the function like this:
list.filter(function(){
});
Is there any reason why this error happens? Does this function even exist in ssjs?
This question is not duplicate since it is not clear that Xpages/Lotus Notes runs Rhino in background.
It sounds like whatever server-side JavaScript environment you're using doesn't support ES5 features (that's features from the 5th edition specification from December 2009).
You can use a polyfill for that and other things that were added to Array, see MDN, but beware: If ES5 features aren't supported, it's impossible to add things to Array.prototype without making them enumerable, meaning any code (mis)using for-in to loop through arrays will be affected.
There is Rhino behind XPages. And this SO topic
No Array.filter() in Rhino? says, it is out of date.
Edit:
No, it is not. Years ago I read somewhere about it. Now it seems it was not true. According to comment by Dan Sickles (quoting Philippe Riand?) here:
It runs on the server jvm and uses javascript as the application
language. For licensing reasons, IBM wrote their own jvm javascript
engine instead of using Rhino. With Rhino shipping in java 6, they
should be able to ship it in Designer 8.5 (or later). The licensing
problems may have been around the extensions like #Formulas and type
declarations. Classes, modules/namespaces and type declarations are
coming in javascript 2 and even google is helping to get that
implemented in Rhino. I'd hate to see a non-standard, javascript
engine underlying the coolest web development technology in Domino.
Speaking of Rhino, the "most important new feature that is not as
certain to be in 8.5 as XPages" uses Rhino and other jvm scripting
languages on the client. If this makes it into the product, two years
from now most new Notes applications will be written in neither
Lotusscript nor Java. I'll leave it at that.
In fact, there are few topics how to use Rhino in XPages, so with newest Rhino version your code would work. Anyway, my advice is to use Java calls.
Related
I'm looking for the way to get low level code of javascript built-in function.
For example, there is an polyfill(I want like this form and I call this low level code in my way) in mdn site of 'Array.prototype.indexOf()'
(https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/indexOf)
And I get to understand that it is kinda low level code of built-in method.
Here is my question, where can I see the code to look inside of method of 'String.prototype.toLowerCase()'?
It'll depend on your javascript implementation.
For V8, here is the guts of toLowerCase (and toUpperCase)
Low level functions (such as these) are generally written in whatever language the javascript engine is written in - that's why they're so fast. So don't go in expecting something that's easy to read for the average javascript-only developer :)
The answer you are looking for probably doesn't exist but I'll do my best do help you out.
The low level function are dependent on which Engine you are using.
A few examples are:
V8 — open source, developed by Google, written in C++
Rhino — managed by the Mozilla Foundation, open source, developed entirely in Java
SpiderMonkey — the first JavaScript engine, which back in the days powered Netscape Navigator, and today powers Firefox
JavaScriptCore — open source, marketed as Nitro and developed by Apple for Safari
I assume you are looking for the function to understand what they are doing. If this is the case and you don't understand the languages that the engines are written it might be an idea to look at the polyfill implementation of those functions. Those are written in javascript and might help you understand them if that's what you are looking for.
Good luck! :)
JavaScript is defined by a standard, with many major implementations.
The definition for that method and others can be found in the TC39 website. It is only defined algorithmically, not in actual code.
That being said, for the open-source implementations, you can actually look at the source code for those implementations, though they will probably be in some other language, such as C++.
The major current open-source implementations of JavaScript are Google's V8, Apple's WebKit and Mozilla's SpiderMonkey.
So I am asking does each web browser have there own compiler example IE compiles Javascript from a website and generates sequence A of byte code .
On the other hand, google chrome compiles the same Javascript from the same website and generates sequence B .
I am wondering this because if that is the case would it be beneficial to run the compiler on the Javascript and upload the generated byte code to the website rather than the Javascript itself. And send different byte code based on each browser.
Or are there some other limitations.
As others have pointed out, there are different ECMAScript engines and some of them use a JIT (Just-In-Time) compiler while some others use runtime interpreters, being the former the preferred option for most browsers nowadays as it gives some performance benefits over the latter option.
You can see another question about this on: https://softwareengineering.stackexchange.com/questions/138521/is-javascript-interpreted-by-design
For example, V8 is the JavaScript engine used in Google Chrome, node.js and can also be embedded into C++ applications.
About your idea of sending compiled or precompiled code to the client instead of the raw JS, there are some projects working on something similar:
Asm.js consists of a strict subset of JavaScript, into which code written in statically-typed languages with manual memory management (such as C) is translated by a source-to-source compiler such as Emscripten (based on LLVM). Performance is improved by limiting language features to those amenable to ahead-of-time optimization and other performance improvements.
The important fact about Asm.js is that existing JavaScript engines do work quite well with its style of code, so you can start using it right now! But the code it produces is still (a subset of) the JS we know but written in some way that helps JS engines to run it faster:
Of course, there are also a lot of restrictions about what you can do with it, as it is mainly oriented to work with just numbers. See http://ejohn.org/blog/asmjs-javascript-compile-target/
Real support for Asm.js is still a limitation, so you can't use things like "use asm" and although you can run Asm.js code on today browsers and get some performance improvements, it won't be as good as it could be in browsers that could optimize Asm.js code. However, we may start having that and some other improvements in the (hope that near) future. See https://blog.mozilla.org/research/2015/02/23/the-emterpreter-run-code-before-it-can-be-parsed/
Meanwhile, and for a more general purpose JS that needs to work with more than just numbers, you can use Google Closure Compiler. I would recommend that you take a look at the FAQ first, and then you could start playing with it in the online tool.
There are several JavaScript (or rather ECMAScript) implementations in wide use, and while in theory there are standards, most widely used one being ES5 (ECMAScript 5) - yes, not everything in all browsers is properly, consistently implemented (I'm looking at you, old IE).
Here's nice compatibility table for ES5 (the one you're writing in today): http://kangax.github.io/compat-table/es5/
And here's same thing for shiny-new ES6: http://kangax.github.io/compat-table/es6/
Note the disclaimer at the top of these tables:
Please note that some of these tests represent existence, not functionality or full conformance.
Also, on the issue of whether JavaScript is compiled or interpreted language: it is definitely interpreted language - at least originally. But most common JavaScript engines in use today implement JIT (Just-In-Time compiler), translating much of JavaScript to byte or machine code before executing it (ergo - compiling).
Most widely used (and most performant as well) of these engines is V8, used by WebKit (and therefore present in Chrome, Safari, Opera, ... - Node.JS is using it as well). Read more about V8 and its JIT implementation: How the V8 engine works?
Yes, each browser has its own implementation of an ECMAScript engine, most commonly implementing/supporting ECMA-262, commonly known as JavaScript. While there are several large related families of browser engines such as Webkit, each engine further can have its own JavaScript engine. For example, as many have pointed out, Google use the V8 engine. Because these engines each do things a little differently, there is no one set of code that is promised to be deterministic across them, the way say Java code will run the same on any machine that supports the JVM.
Inherently, JavaScript is not compiled like a traditional language such a Java or C/C++. This is why, without the help of a 3rd party program, you cannot find non-syntax errors in your JavaScript code until that code runs. ECMAScript is an interpreted language.
Now, this is the tricky part. Most modern JavaScript engines do in fact compile JavaScript, often to another language (also known as Source-to-Source compiling or transpiling) such as C, to perform performance optimizations on it. Of course, at some point, all code gets compiled into byte code.
Your best bet for writing JavaScript that will work on all major browsers is to use core/standard features. For example, this means passing timestamp string in the form of "yyyy/mm/dd" instead of "yyy-mm-dd" when using new Date() since Firefox does not support the latter format - the Chrome developers simply added it to be nice to you. IE is notorious for handling certain non-standard features differently. I'm a big fan of http://caniuse.com/ to help with this.
Nowadays most javascript engines are JIT compilers. More here: What does a just-in-time (JIT) compiler do?
So yes, javascript is compiled (not interpreted), and most major browsers do it differently.
If it's a scripting language as the name implies it must be written in a lower level language right? Like how PHP is written in C what language is JavaScript written in?
Javascript is just a standard, more formally known as ECMAScript. It can be implemented in any language, just like any standard.
Chrome's Javascript engine, V8, is written in C++.
From the project page:
V8 is written in C++ and is used in Google Chrome, the open source browser from Google.
V8 implements ECMAScript as specified in ECMA-262, 5th edition, and
runs on Windows (XP or newer), Mac OS X (10.5 or newer), and Linux
systems that use IA-32, x64, or ARM processors.
Firefox's Javascript engine, SpiderMonkey (and now TraceMonkey) is also written in C++. And as maerics below said, Rhino is written in Java.
All the answers so far are correct, but since it hasn't been mentioned yet, JavaScript can be written in JavaScript.
Most Javascript interpreters are written in C/C++ (V8, Nitro, etc…), however a compliant interpreter can be written in any language (Rhino→Java, Interpreter→Javascript, etc…).
Whichever language the client webbrowsers javascript interpreter was written in :)
Javascript is an implementation of the ECMAScript standard, but there is no singular canonical interpreter like you see with PHP.
Most of the major implementations (standalone or as parts of web browsers) out there tend to be largely written in C or C++ for performance reasons, but that's not necessarily always the case. Rhino, an engine maintained by Mozilla, is written in Java.
Most implementations of Javascript show behaviour that is clearly caused by the use of pointers and byref parameter passing, which normally points towards the use of C, or C++
This is clearly notable for instance when you are taking apart a multidimensional array in a loop, with the help of intermediate array's. These tend to behave very "strangely", if you are not familiar with pointers and byref passing of parameters (You need do var hlp = new Array() each time or it will overwrite the previous values which you already stored somewhere else)
I'm rather curious as to how an implementation of javascript in for instance Java, because I imagine that this kind of behaviour will be quite different in that case?
C++ is the fundamental language for anything modern and fancy. Most modern high level languages are subset of low level language,C++. All modern languages you see today is a subset of C++ someway or the other. Even Java is a subset of C++.
Where can I find a list of all the differences between V8 and ECMAScript? For example V8 supports const, which isn't part of the ECMAScript standard.
Edit: Direct answer: Track status of ES5 implementations in progress which indicates the V8 googlecode issues tagged es5
or https://github.com/joyent/node/wiki/ECMA-5-Mozilla-Features-Implemented-in-V8
V8 implements all of ES5 currently aside from a handful of edge cases, and only then in order to be compliant with the majority of how other current browsers handle the given situation.
Because it won't be living on its own nearly all of the differences you'll be dealing with will be in the host environment implementation wrapped around it. For most uses this is the various APIs web browsers provide. As a non-browser example, Node.js provides custom APIs for file system and network interaction. In terms of core language there's just not that much wiggle room. Minus the DOM, JavaScript is a pretty damn simple language to use (part of why it's so awesome) and has a really specific Specification document.
ES5 is an iteration up from ES3 and nearly 100% backwards compatible if not using 'use strict'. After nearly a decade of stagnation along with inability to gain a consensus among major JavaScript engine implementers ES5 was born and limited primarily to cut out and address the worst issues with the language. The extent of mainstream use ES5 is Array extras, Object extras (mainly Object.create), Function.bind, and strict mode (which is entirely about stripping features out), and a handful of natives helpers like built in JSON and base64.
Most of this 240 page specification is spent in laboriously defining every detail about behavior that has existed in JavaScript for almost 15 years, as well as the list of features which will be deprecated and eventually removed (with, various uses of eval, etc.).
Harmony (ES6) is the first real big change we're going to see. ES5 accomplished the goal of getting engine implementations on the same page and gutting most of the problematic parts of JS. Looking forward to ES6, it's time to address some fundamental language issues that require syntax changes to fix. ES6 is scheduled for finalization in late 2013 but large chunks are already implemented in JS engines in order to test them and see how they work in practical usage. The web is a living thing and implementing new standards isn't a matter of creating a new spec and then unleashing it on the world like it is most other industries. Ideas are floated and must past muster at both the implementer level (the guys who write V8, Spidermonkey, JSC, Chakra, etc.) and then the actual user level (user in this case being web developers writing code to run in those engines). Ivory tower dictation just results in lack of use.
Specifically in the case of const: this is currently not exactly defined entirely. It's a keyword with similar but not exactly the same functionality in V8 and Spidermonkey, and has a similar but not exactly the same meaning for ES6. You're probably safe to use it if you expect your target audience's engine to support it currently, but as implemented it wasn't technically part of any official spec. migrating let' andconst'
Beyond that there's "Host Objects" which are exposed by the given engine a JS script is running in. JavaScript existed first as an implementation and second as a specification, so until recently it wasn't obvious to non-experts to know where the diving line is. When it's running in a browser (as is usually the case) the Document Object Model is exposed as a host object for automatic usage. The functionality of the DOM is largely described using IDL and is under the purview of the W3C. The multitude of specification implementations encompass 6 top level sections, almost 50 separate working groups, and around 1000 separate specifications. These are interfaces exposed to JavaScript but completely ungoverned by the requirements of any JavaScript specification. The DOM encompasses a huge space of described functionality and continuously changing implementations thereof.
I drive into this issue:
I create COM object using C#, register it and managed to work with it using powershell.
when i trying to do the same with JavaScript it fails, but javascript keeps throwing object null errors.
Do you have any advice on how to fix this problem? or maybe you JavaScript doesn't support COM (if so, where can i read more about it)???
Thanks a lot!
Use Shanti Rao's JSDB shell. It's based on the core Spidermonkey engine (Mozilla's Javascript implementation) used in Firefox, but has a bunch of bindings for databases & ActiveX objects and such. It has a few limitations but unless you're using something complicated you should be able to make use of it.
Example:
x=new ActiveX('MSXML2.DOMDocument.6.0');
x.async = false;
// I forget how to use IXMLDOMDocument but other calls go here
I know this is a bit late, but for others who find this, yes this can be done easily. This assumes you're running on Windows since you're looking for Windows/JavaScript interoperability.
The most important question is "what JavaScript engine are you using?" as this functionality is determined by that engine. Since 1995, Windows has supported a system standard scripting model originally called OLE Automation or sometimes just COM. Windows-based scripting engines like the JavaScript and VBScript engines built into the Windows Scripting Host use this engine, in addition to IE through version 8 and I think up to 11. However, the IE container implements security restrictions that prevent some of what I'm describing from working. Open-source JavaScript engines like node.js typically do not use COM as this is Windows specific functionality and so cannot do what I am describing.
Given that, to accomplish what you want, you must:
1. Implement a scriptable COM object.
2. Register that object (typically automatic during your build process).
3. In JavaScript, create an instance of that object using new ActiveX object, as mentioned above.
You can write your object in both C# and C++. In both cases, you need to base your object on IDispatch. C# will make the whole process considerably easier. Essentially, you generate a few unique GUIDs for your interface and component using guidgen, then using a few COM-specific attributes in C# to provide these. Here's a link to a great simple example (ignore the Events stuff):
https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/interop/example-com-class
The most important thing to know is that you will be limited on what data types you can take as parameters or return to the caller. Things like strings and ints are no problem. For others, you can describe them in C# and send them from C# to JavaScript, but the other way around is not going to work.
Javascript indeed does not support COM. An option is to use JScript and an ActiveX wrapper to a COM object. Also, it will only work in Internet Explorer.
Instantiating a COM class
Calling functions of a COM object in JScript
Other JScript/COM tutorials, including script callbacks