[x3d-public] inputOutput in scripts [was: ScalarSequencer proto [was internal script state]]

[Andreas Plesch]

Responding to myself:

On Sat, Nov 4, 2017 at 9:13 AM, Andreas Plesch <andreasplesch at gmail.com> wrote:
>...
> In theory, inputOutput type in a script should enable set_ and
> _changed events, so I am not sure why this splitting is necessary.
>
> For example, is it sufficient for an inputOutput key field to write
>
> function set_key(val) { key = val; }
>
> to achieve both assigning the new value to the field, and also
> outputting of a key_changed event ?
>
> I think in x_ite it is sufficient but I will need to test.

The question might have been not very accessible, so I added a simple
test to http://ripe-taxi.glitch.me/ScalarSequencerAsProto.x3d which
routes a MFFloat value to the key field of the ScalarSequencer proto,
and then routes from the this key field to the keyValue field to see
if a key_changed event is generated. All stages are logged.

Sofar I tested only x_ite and Octaga and both do what was expected,
eg. generate the proper output event for inputOutput fields. So sofar
no need to make the proto more explicit.

freeWrl actually crashes with that test scene.

Will check InstantPlayer and BSContact as well, and perhaps
view3dscene after translating to castlescript.

> -Andreas
>
> On Sat, Nov 4, 2017 at 12:39 AM, Andreas Plesch <andreasplesch at gmail.com> wrote:
>> Working on a ScalarSequencer proto ,I developed the script which
>> provides the functionality:
>>
>> https://ripe-taxi.glitch.me/
>>
>> It seems to work ok using x_ite. In order to maintain internal,
>> persisting state, the script uses an initializeOnly field:
>>
>> https://glitch.com/edit/#!/ripe-taxi?path=index.html:161:21
>>
>> Perhaps this is the intended use of such a field but I was wondering
>> if there are other standard ways to have such internal state storage.
>> For example, it may be convenient to use a javascript object for state
>> which could not be a field value.
>>
>> It is possible to just use a global variable, initialized in the
>> initialize() function. However, in an environment such as web page
>> this would intrude other script sharing the global context. One could
>> use a namespace then, say script1.globalA
>>
>> With x_ite it is possible declare a scoped variable in the script but
>> outside the functions which then persists and is in the scope of all
>> script functions but out of scope anywhere outside the script. A good
>> solution but likely this is not guaranteed to work in other browsers
>> since the spec. does not cover code execution outside the script
>> functions.
>>
>> Perhaps the namespaced global variable would be the most standard way
>> but it would be great if global variables could be avoided.
>>
>> -Andreas
>>
>> --
>> Andreas Plesch
>> Waltham, MA 02453
>
> --
> Andreas Plesch
> Waltham, MA 02453



-- 
Andreas Plesch
Waltham, MA 02453