Hype GlobalBehavior (Custom Behavior Extension)


(Loves Hype) #1

This idea got triggered back in the day :face_with_monocle: when trying to explain Custom Behavior as Tweets. The idea stuck with me in a literal form…

Mostly I use Hype these days for Widgets in CMS-Projects so I thought I share the concept of a unified communication pipeline across individual widget. So I recreated LocalConnection from the Flash-days with a little Twitter-twist and named it GlobalBehavior:

Hint: The code is an extension. It enables all Hype-Widget loaded on the same page to form a broadcast network. Inside the widget are just plain Custom Behavior calls following the rules mentioned in the example. The code from the JS-files below can also just be pasted into the Head-HTML.

Demonstration:
https://playground.maxziebell.de/Hype/GlobalBehavior/

Installation:
Link the runtime below into your head … <script type="text/javascript" src="YOURPATH/HypeCustomBehavior.min.js"></script>. Please don’t hotlink from my server in production sites (for testing it is fine) rather put the code in your project or server. You can also copy and paste the code into Head-HTML in your file (full or minified) but then don’t forget to wrap in in a script-tag … <script type="text/javascript"> CODE HERE </script>. You don’t need todo both!

Runtime:
HypeGlobalBehavior.js
HypeGlobalBehavior.min.js

Updates:
1.0 Initial release #-syntax, @-syntax based on Hype Observer Pattern
1.1 Added callbacks in JS hypedocument.onGlobalBehavior
1.2 Added iFrame (onedirectional), onedirectional postMessage
1.3 Refactored code to Revealing Module Pattern, compiled against Closure-compiler, Bidirectional postMessage (Bubble Up, Bubble Down, Bubble Branching)
1.4 Refactored to new naming and interface, corrected to american english
1.5 Fixed a bug with iFrame propagation and added a “Singleton” check
1.6 Added Custom Behavior Ticker feature, code cleanup


Sending message to Hype Document from a nested (child) Hype Document
Change Scene from external javascript
Accessing variable in embedded hype file from outside html document
Wordpress plugin: Open a animation on specific scene?
Game Design Examples (two approaches)
Sending message to Hype Document from a nested (child) Hype Document
Calling Hype Function from External Library
Sending message to Hype Document from a nested (child) Hype Document
Change scene within an IFRAME
How to scroll two timelines in two file in one page?
(Loves Hype) #2

↑ look at project

/* code and version notes moved to file as it's easier to maintain */

(Loves Hype) #3

Work in progress on / note to self:

  • Trigger from anywhere outside the broadcast network (body etc.) done
  • Listener as pure JS inside the widget or in Head-HTML extension (onLocalConnection) done
  • Trigger multiple targets done done
  • Tdb.: Evaluation of passing arguments around (URL-encode, Json)
  • Tdb.: Sending multiple commands in one go (cmd1|cmd2@widget)
  • Example: Allow user to send command via textbox
  • Example: combination with startBehaviourTicker

Ideas along Widget (or Blocks) - Network / Sidenotes (tbd.)

  • Allow block to go mute
  • Evaluation of shared state storage (Update: Rather separate solution!)
  • Evaluation of persistent state store (Update: Rather separate solution!)
  • Issue commands to LocalConnection exclusively
    –> Mute, Groupsets, State
  • getHypeInstances
  • getHypeDocumentnames

#4

@MaxZieb

Thank You - what a useful (in progress) tool to offer!

It occurred to me as I was going through things that it might be valuable to post the (3) HTML Widget’s in your demo (as Hype projects) so those that like to “learn by doing” would have a complete reference to work with based on your previous posts.


(Loves Hype) #5

@JimScott For now I won’t release my Hype-file as it has my special quirks and might be more confusing then helpful (I am using a single file and extended exporter). The whole point of Hype LocalConnection is that apart of the extension (Head-HTML) and the command-structure it is independent of any given Hype-file or way you export them. That said I will release some examples based on single Hype-file per Widget in the future.


(Loves Hype) #6

↑ look at project
Updated to version 1.1


(Jonathan Deutsch) #7

Very cool!

  • There was recent question about triggering a custom behavior on a specific symbol. I haven’t thought too much about ways to do this, but at the very lease the triggering @ syntax is an interesting development.
  • Have you thought about the backbone being postMessage? In this way you could send to Hype documents in different iframes.
  • The “here” link in localConnectionTest.html is broken.

(Loves Hype) #8

Thanks.

This solution also doesn’t solve the recent question as it is ment to work across instances. The solution, you suggested, to just use hypeDocument.getSymbolInstanceById(‘id’) was the best way to go. I think targeting a single instance with a Custom Behaviour that was setup to trigger others defies the purpose. Then he should have just set up a new Custom Behaviour with only one listener.

LocalConnection on the other hand broadcasts the “hastag” version through the whole Hype-Instance-Network and all it’s internal listeners with the benefit that all Hype-Instances on the page are now potentially targeted. So the @ is to limit Hype-Instances without much hassle.

For now the callstack is direct and postMessage introduces the async aspect but why not. I’ll probably just send the trigger so that an iFrame could catch it and participate in LocalConnection (but don’t think I’ll switch over entirely to PostMessage).

Fixed and now I added a link to an online version


(Jonathan Deutsch) #9

(To clarify I was just musing that it was an interesting solution to a similar problem!)


(Loves Hype) #10

↑ look at project
Updated to version 1.2
It now supports iFrames (one directional for now)


(Loves Hype) #11

↑ look at project
Updated to version 1.3
Rewritten against Closure-Compiler and expanded on bubbling


(Loves Hype) #12

↑ look at project

Here are some thoughts I am having for this Extension and others to follow:


Features per Extension

I cleaned up the public interface (upcoming release to only two commands). Less is more and less to maintain and support. Also rather have something that just does the job then offer a million features.


Mountingpoint

I am still thinking about the mounting point. I currently have the part facing HTML in window['LB'] that allows to trigger functions specific to the extension from the page scope. This allows for a very short notation LB.triggerCustomBehaviour('RedAlert') but means if every Extension does this it rather quickly pollutes window. One could collect them in window['Extension']. For this case resulting in window['Extension']['LocalConnection'] producing the command path Extension.LocalConnetion.triggerCustomBehaviour('RedAlert'). My other thought was going into window['HYPE']. The later could mess with Hype itself so I am hesitant given Hype uses the following to init…

    if (window['HYPE'] == null) {
        window['HYPE'] = window['HYPE_584'];
        window['HYPE']['documents'] = {};
    }

… one could easyly break Hype through setting window['HYPE'] to not null to create window['HYPE']['LocalConnection']. On the other hand one could just do the following in Extensions …

    if (window['HYPE'] != null) {
        /*init in here*/
        window['HYPE']['ExtensionName'] = …
    }

That would have the downside that Extensions depend on Hype being loaded first otherwise they break and are not initialized. Also not ideal… but the command path looks neat HYPE.LocalConnection.triggerCustomBehaviour('RedAlert')

Got any thoughts on the matter?


(Jonathan Deutsch) #13

I would strongly discourage against attaching to HYPE globals/variables if possible.


(Loves Hype) #16

↑ look at project
Updated to version 1.4
Refactored to new naming and interface, renamed from Behaviour :uk: to Behavior :us:


After thinking about the naming (thanks@jonathan) and scope I decided that each functional extension has it’s own name space called like the JS-file. Therefor HypeGlobalBehaviour.js can be found at window.HypeGlobalBehaviour


(Loves Hype) #17

↑ look at project
Updated to version 1.5
Fixed a bug with iFrame propagation and added a "Singleton" check


(Loves Hype) #18

↑ look at project
Updated to version 1.6
* Added Custom Behavior Ticker feature, code cleanup


(Loves Hype) #19

↑ look at project
No updates to main code but a thread containing an code example with a single Hype file (see below):


(Hans-Gerd Claßen) #20

i had a first deeper look and have to say this extension is really great stuff!

as you’ve intitiated the whole extension thread -> this really takes hype functionality further


(Alex) #21

Hi @MaxZieb,

It looks great extension.

I am using HYPE wordpress plugin:
Tumult Hype Animations Wordpress Plugin

and I already add your JS into my project, but it does not work me, and the issue is at this post:

And here are my two Hype files(I do not know why I can not upload hype files here):
https://www.dropbox.com/s/wlvit2e1rh9m70o/product1.hype.zip?dl=0
https://www.dropbox.com/s/cbeqypfwla0vdg0/product2.hype.zip?dl=0

It would be great appreciated if you could let me know how to make them work at same time in one page.

By the way, is it possible to add your JS libraries into Hype wordpress plugin and make them work automatically? it would be much helpful and effective if it works in this way.

Have a nice day.

Alex


(Loves Hype) #22

You have to add the custom behavior script library to your WordPress header. Use a childtheme and functions.php with some actions (https://developer.wordpress.org/themes/basics/including-css-javascript/) or use a plugin that can add to the header (for example https://wordpress.org/plugins/header-and-footer-scripts/).

Another solution you can test is to use iFrames instead of divs in the Hype-WordPress-Plugin. There is a setting on each hype upload. That way your original HTML with the script in the header is used but it will load the library multiple times. But the browser will work it’s magic and fetch it from cache.

I’d personally rather use the first solution but the second option might be easier todo quickly.