Injecting Commands into Vorple from JavaScript

Authoring Inform 7
1

The Vorple API utilizes the following function in the parser module:

/** * sendSilentCommand(), but the command is placed in the primary command * queue. See also sendPrimaryCommand(). * * @public * @method * @name parser#sendSilentPrimaryCommand */ self.sendSilentPrimaryCommand = function( command ) { self.sendCommand( command, { hideCommand: true, hideOutput: true, skipFilters: true, primaryCommand: true } ); };

From within the Inform7 Interface, one can issue a similar command to trigger an Inform7 “event”.
The question is how can one use what is shown as a public method to do this from within a users JavaScript?
The hardest part is getting the running instance of the parser, so that the sendSilentPrimaryCommand can be issued.
I presume that one would use the same command syntax as if it were issued from within Inform7.
This sounds like it should be very simple to do, but I’ve learned that there isn’t much feedback if it’s not done correctly.
So, I thought I’d ask first.

2

The parser module is a member of the global vorple object, so:

vorple.parser.sendSilentPrimaryCommand( "x me" );
3

Thanks, Juhana.

Now that I’ve figured out how to interface new screen objects and javascript to Vorple, I think can proceed with my new adventure.
This promises to be “fun”…a lot of work, but fun. The new Vorple has some amazing stock capabilities.
The ability to "create’ add features through javascript/jquery/css and its public interfaces just makes it better.

4

Just a quick note to say that I’ve found that .live() works better than .on() in setting up the button click events.
That seems to be because the html code that needs to have the events handles attached to it is sometimes not present when the handler is assigned.

5

.live() is deprecated and everything it can do can be done with .on(). The api explains how to convert it: api.jquery.com/live/

6

Thanks, Dannii. I’ll have a look.
I tried .on prior to .live and it wouldn’t work for some reason.
It almost seemed as if it needed to have the target html already present.

7

I’m surprised you could even use .live(), considering that Vorple uses jQuery 1.11 and it was removed from 1.9 on.

In any case, this is the code for .live() in 1.8:

live: function( types, data, fn ) {
		jQuery( this.context ).on( types, this.selector, data, fn );
		return this;
	},

…so it’s literally nothing but an alias of .on().

The trick is that you can’t just search-and-replace .live() with .on(): if you have $( ‘#selector’ ).live( ‘click’, function() { … } ) you’d use $( document ).on( ‘click’, ‘#selector’, function() {…} ) instead. The API has a more thorough explanation.

8

Juhana;

Oddly enough; “.live” worked, but I can’t explain why.
That said; I don’t want to use “.live”, if it’s deprecated.
So; here is what I have now using “.on” and it appears to work.

[code]function insertButtonCode() {
var newA = $(‘E’);
$( “.buttonCode” ).append(newA);
$( document ).on( “click”, “a.button”, function() {
vorple.parser.sendPrimaryCommand( “react” ); // jQuery 1.7+
});

function removeButtonCode() {
$(’.buttonCode’).remove();
};
[/code]

If more than one handler is to be tied to “a.button”, how is that done?
I used to be able to use a set “{…}” of “handler:”'s, but this doesn’t seem to be possible with the new syntax.

9

Juhana;

I’ve been able to get multi-level horizontal drop-down menus working in VORPLE by just using just CSS and the stock Vorple extensions. This, however, takes just a bit of time to interpret and “inject” the HTML statements into the webpage when play begins. However; it does have the benefit of being able to use the command-link functionality built into Vorple.

If I use jQuery to inject a block of HTML code, it would be faster, but I will lose the use of the Vorple command-link functionality and have to tweak things to inject menu-generated responses into the command-line and catch/handle them in Inform7.

Am I correct that using the jQuery generate the html menu code as a block and add it into the webpage body, then inject/catch the commands per the vorple documentation would be a plausible solution to load times? Seems that injecting a prepared block of code should be faster. Would my injecting commands be likely to bog down the game-play any more than the same approach using the built-in Vorple command-link method? Seems your code uses essentially the same method in handling command-links, so it shouldn’t.

If you’ve any other suggestions, I’d love to hear them.

10

I don’t have any official recommendations. It seems that some JS commands take longer to execute than others, but I haven’t quite figured out why or when exactly that happens.

Generally it’s best to have as much of the UI logic in external files than in Inform 7, if for nothing else then for the sake of keeping UI and story logic separate.

11

Thanks, Juhana.
I’ve managed to get things working.
Wrote a new set of commands to help build the menus and went through the CSS, line by line, to optimize some of the code. Loads faster, now.
Trying to get multiple browser compatibility was somewhat difficult. Had to add a few “hacks” to satisfy IE. Not sure I can please everyone. :slight_smile:
Why can’t MS try to be more standard in their offerings. There are more hacks to please IE than for any other browser.