svetkaPublic Space

Good News

You don’t have to read the following boring paragraphs carefully unless you’re going to join the development of Svetka :-)

Here It Goes…

Every Flash movie on the page can contain a number of Evaluator instances generated by EvaluatorPool movie-scope singleton instance. Every evaluator contains one separate EvaluatorContext instance where it stores exposed variables (along with their aliases) and references to the unnamed objects generated during the evaluation. Latter are automatically (by the evaluator’s order) removed after the evaluation ends.

Since stub objects are generated on the JS-side they are similarly kept in the JS-side context. The difference between JS-side and AS-side context is that JS-side context has global (i.e. one per HTML document – not one per evaluator) scope. However it is also rather dumb and managed by the evaluators.

As we’ve already mentioned, the main idea is to create objects on-the-fly on the JS-side with stub methods calling corresponding methods on the AS-side.

A stub method on the JS-side calls Evaluator#invokeMethod(...) via ExternalInterface and passes corresponding object and method identity along with parameters having been passed to the stub. invokeMethod(...) calls specified method on the AS-side applying specified parameters, prepares the result of the invocation for AS/JS transfer and passes it back to the JS-side.

Preparation for the AS/JS transfer doesn’t mean a serialization – the serialization (or whatever) is done by ExternalInterface implicitly. E.g. in case when the returning value is an object, evaluator watches whether the returning object has been already transferred to the JS. If it has been, the evaluator substitutes the object with a referential one which is substituted on the JS-side with an instance already being kept in JS-side context. Without doing this we would waste a lot of memory during the computation on the JS-side and wouldn’t be able to compare the objects returning by AS-methods with == operator even if the returning objects are really the same.

Also when firstly passing given AS-object to the JS-side evaluator substitutes it with a descriptor object containing the names of original methods (except toString()). It doesn’t keep any information on the object’s properties (fields) because there is no way to synchronize property values of real AS-objects and their JS-side clones. To deal with objects’ properties use setters and getters.

When JS-side stub method receives a descriptor object as a result, it creates an object with specified methods which will call Evaluator#invokeMethod(...) and puts it to JS-side context.

Evaluator#evaluate(expression : String) initializes exposed variables, that should be locally available when computing the expression, simply adding necessary variable definitions to the beginning of the expression. Then it passes the expression to the JS-side eval function via ExternalInterface. Finally it postprocesses the result of eval substituting referential objects (we also can get them as a result of the evaluation) with real ones. That’s it.

Strictly speaking Evaluator#evaluate and JS-side stub methods do a bit more stuff relating to error handling. This is discussed on Error Handling page.

Next

The next chapter contains detailed API overview. It’s strongly recommended to read it carefully even if you are not a developer of Svetka engine – only a user.