--- title: Resumen de Rhino slug: Rhino/Resumen translation_of: Mozilla/Projects/Rhino/Overview ---

Introducción

La mayoría de las personas que han utilizado JavaScript antes lo han hecho añadiendo las secuencias de comandos HTML a sus páginas web. Sin embargo, Rhino es una implementación de sólo el núcleo del lenguaje y no contiene objetos o métodos para manipular documentos HTML.

Rhino incluye

Lenguaje

El lenguaje JavaScript en sí esta estandarizado por la norma Standard ECMA-262 ECMAScript: A general purpose, cross-platform programming language. Rhino 1.3 y superiores se ajustan a la Versión 3 de la Norma.

Rhino 1.6 y superiores implementan ECMA-357 ECMAScript for XML (E4X). Consulte las especificaciones para obtener más información sobre la norma, y vea Versión de Rhino 1.6R1 notas de versión para obtener mas información sobre la implementación de Rhino.

Además, Rhino ha implementado JavaAdapters, que le permite implementar JavaScript en cualquier interfaz Java o ampliar una clase Java con un objeto JavaScript. Vea el ejemplo enum.js para obtener mas información.

Numerosos libros y tutoriales de JavaScript están disponibles. JavaScript: The Definitive Guide es recomendable, y contiene un capítulo sobre Rhino.

Características del Lenguaje Obsoletas

Varias características del lenguaje introducidas en JavaScript 1.2 se consideran obsoletas. Estas características permiten la "reflexión computacional": es decir, la capacidad de un script para determinar e influir en los aspectos de la forma que se evalúa. Estas características no suelen ser útiles, sin embargo, imponen restricciones significativas en las  implementaciones que dificultan o impiden la optimización.  Las características en desuso son the __proto__ and __parent__ properties, y los constructores With, Closure, y Call. Si pretende invocar estos constructores con la versión 1.4 se producirá un error. para otras versiones, se genera una advertencia.

Internacionalización

Los mensajes reportados por el motor de JavaScript por defecto son recuperados desde el archivo de propiedad org/mozilla/javascript/resources/Messages.properties. Si existen otras propiedades de los archivos con las extensiones correspondientes a la localización actual, se van a utilizar en su lugar.

Versiones del Lenguaje JavaScript

Algunos comportamientos en el motor JavaScript depende de la versión del lenguaje. En la incorporación del navegador, la versión de idioma se selcciona mediante el atributo LANGUAGE de la etiqueta SCRIPT con los valores tales como "JavaScript1.2".

Versión 1.3 y superiores son compatibles con ECMA.

Los Operadores == and !=

La versión 1.2 sólo utiliza la igualdad estricta para los operadores == y !=. En la versión 1.3 y superiores, == y != tienen el mismo significado que ECMA. Los operadores === y !== se utiliza estrictamente en todas las versiones.

Para Booleano

Booleano(new Boolean(false)) es falsa para todas las versiones anteriores a 1.3. Es true ( y por lo tanto compatible con ECMA) para la versión 1.3 y superiores.

Array.prototype.toString y Object.prototype.toString

La versión 1.2 solo retorna array o objetos de notación literal ("{{ mediawiki.external(1,2,3) }}" ó "{a:1, b:2}" por ejemplo). En la  versión 1.3 y superiores esta funciones es compatible con ECMA.

Constructores de Array

Array(i) para un argumento de número i construye una matriz con un solo elemento igual a i solo para la versión 1.2. Lo contrario si se utiliza la versión ECMA compatible ( Una matriz se construye sin elementos pero con propiedad de longitud igual a i).

String.prototype.substring

Solo para la versión 1.2, los dos argumentos no se cambian si el primer argumento es menor que el segundo. Todas las demas verciones son compatibles con ECMA.

String.prototype.split

Solo para la versión 1.2, realiza la division de Perl4 cuando se les da un caracter de espacio como argumento (salta principalmente espacios en blanco, y se divide el espacio en blanco). Todas las demás versiones se divide en el carácter de espacio adecuado segín lo especificado por ECMA.

Seguridad

Las caracteristicas de seguridad de Rhino proporcionan la capasidad de rastrear el origen de una parte del código ( y cualquier pedazo de código que se pueda generar). Estas caracteristicas permiten la implementación de una politica de seguridad tradicional basada en URL para JavaScript como en el Navegador Netscape. Integrar esa confianza en el código JavaScript que se ejecuta puede ignorar las caracteristicas de seguridad.

Insertar código JavaScript que no es de confianza debe hacer dos cosas para habilitar las funciones de seguridad. En primer lugar, todos los contesxtos que se crean deben ser suministrados como instancia de un objeto que implementa la interfaz SecuritySupport. Esto proporcionará la funcionalidad Rhino de apoyo que necesita para realizar tareas reliacionadas con la seguridad.

Second, the value of the property security.requireSecurityDomain should be changed to true in the resource bundle org.mozilla.javascript.resources.Security. The value of this property can be determined at runtime by calling the isSecurityDomainRequired method of Context. Setting this property to true requires that any calls that compile or evaluate JavaScript must supply a security domain object of any object type that will be used to identify JavaScript code. In a typical client embedding, this object might be a string with the URL of the server that supplied the script, or an object that contains a representation of the signers of a piece of code for certificate-based security policies.

When JavaScript code attempts a restricted action, the security domain can be retrieved in the following manner. The class context should be obtained from the security manager (see java.lang.SecurityManager.getClassContext()). Then, the class of the code that called to request the restricted action can be obtained by looking an appropriate index into the class context array. If the caller is JavaScript the class obtained may be one of two types. First, it may be the class of the interpreter if interpretive mode is in effect. Second, it may be a generated class if classfile generation is supported. An embedding can distinguish the two cases by calling isInterpreterClass() in the Context class. If it is the interpreter class, call the getInterpreterSecurityDomain() method of Context to obtain the security domain of the currently executing interpreted script or function. Otherwise, it must be a generated class, and an embedding can call getSecurityDomain() in the class implementing SecuritySupport. When the class was defined and loaded, the appropriate security domain was associated with it, and can be retrieved by calling this method. Once the security domain has been determined, an embedding can perform whatever checks are appropriate to determine whether access should be allowed.

{{ languages( { "ja": "ja/Rhino_Overview" } ) }}