[x3d-public] ScalarSequencer proto [was internal script state]

[Andreas Plesch]

I developed a first ScalarSequence proto here:

https://glitch.com/edit/#!/ripe-taxi?path=index.html:65:12
https://ripe-taxi.glitch.me/

and it works with x_ite. I will test it in other browsers as well.

Looking through the examples, I see that persisting state is mostly
managed by initializeOnly fields.

Interestingly, the BooleanSequencerPrototype example

http://www.web3d.org/x3d/content/examples/Basic/development/BooleanSequencerPrototypeIndex.html

declares local variables outside of the functions:

var key, keyValue;

But this is rarely done, and I am not sure if this is covered by the spec.

I also noticed that fields of accessType inputOutput are often
substituted by the corresponding inputOnly/outputOnly fields.
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.

-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