technisode

Gravatar is an service that allows users to specify a public avatar image linked to an email address. I recently decided to allow users to use their Gravatar avatar with my Parse-backed app rather than build in my own avatar system. To simplify things, I've hooked beforeSave for the User object to hash the email address and add it to the object. That ensures that any email address change is automatically hashed on the server and allows me to send the hash down to clients rather than the email address to protect privacy.

Obviously you can add appCache to existing apps but there are a couple things I think the framework could add here. First, let's get the appcache events wired into enyo's event model.

if(window.applicationCache) { enyo.dispatcher.listen(window.application, "updateReady"); // there are other cache states. updateReady seems to be the most useful one }

Second, let's enhance bootplate to include an appcache manifest in the index.html. Open to naming preferences. Also, provide the default manifest file. Here's a first cut

CACHE MANIFEST # these will be cached CACHE: index.html build/enyo.js build/app.js build/enyo.css build/app.css assets/* # these resources will always be pulled from the network NETWORK: # /api # these resources will be loaded if the requested fails FALLBACK: # tryFirst.html useOnFail.html

I've been playing around with the Cloud9 IDE a bit recently to do some remote development. It's come a long way from when I first used it and is quite functional. A great addition is an interactive command line with a git client. So I thought, "It'd be nice to get the EnyoJS bootplate up and running here." Following the general instructions from the wiki, I put together a set of commands that gets everything set up.

TL; DR

Pull in bootplate, update the submodules, and "disconnect" the master branch from the bootplate repo.

git clone https://github.com/enyojs/bootplate.git; rm -rf .git; shopt -s dotglob; mv bootplate/* .; git remote rename origin bootplate; git submodule update --init; printf "\n.c9*" >> .gitignore; git add .gitignore; git config --unset branch.master.remote; git config --unset branch.master.merge;

Assuming your pushing this to a new git repo (on Github or Bitbucket for example), add the remote repo and set the master branch to track it.

git remote add origin git fetch origin; git branch --set-upstream master origin/master

Here's the first command broken up for readability:

Wanted to share a preview of a new kind I've been working on. The idea stemmed from a recent patch I submitted to fix remote loading of js into enyo. A prime use case for that capbility is to deliver a mobile website in which the entire site could be integrated into a single enyo app without loading the entire source on load. Each view could be managed by a parent enyo.Panels and loaded as requested. To support this idea, I created a new kind called enyo.RemoteControl. In short, it has a load() method that retrieves a remote JS file and attempts to instantiate the specified kind as a child component. To configure what to load, the kind has 2 design-time parameters: href to specify the URL and remoteKind to specify the "kind" to create. It also supports fit which tells the RemoteControl to apply the enyo-fit class to the new child. Finally, it provides a scrim and spinner which displays while the script is fetched and the kind is rendered. This can be overriden through the scrimKind member.

enyo.kind({ name:"enyo.RemoteControlScrim", kind:"onyx.Scrim", classes:"onyx-scrim-translucent", style:"text-align:center", showing:false, components:[ {kind:"onyx.Spinner", style:"position:absolute;top:50%;margin-top:-30px;display:inline-block"} ] }); enyo.kind({ name: "enyo.RemoteControl", kind: "Control", loadState: 0, scrimKind:"enyo.RemoteControlScrim", published:{ animate:true }, events:{ onLoad:"", onLoadFailed:"" }, components:[ {name:"ani", kind:"Animator", startValue:65, endValue:1, onStep:"aniStep", onStop:"aniStop", onEnd:"aniStop"} ], getScrim:function() { // defer scrim creation ... return this.$.scrim || this.createComponent({name:"scrim", kind:this.scrimKind || "Control", owner:this}).render(); }, refresh: function() { this.setLoadState(0); this.load(); }, setLoadState:function(state) { this.loadState = state; if(this.loadState == 1) { this.getScrim().show(); } else if(this.loadState == 2) { // what about errors? if(this.animate) { this.$.ani.play(); } else { this.aniStop(); } } }, load: function() { if(this.href && this.loadState == 0) { this.setLoadState(1); //enyo.job(this.id+"_load", enyo.bind(this, function() { enyo.load([this.href], enyo.bind(this, "loaded")); //}), 2000); } }, loaded: function(block) { // should be null unless my pull is changed to always created the failed member if(!block.failed || block.failed.length === 0) { this.setLoadState(2); this.remote = this.createComponent({kind:this.remoteKind, classes:(this.fit) ? "enyo-fit" : ""}).render(); this.doLoad({remote:this.remote}); } else { this.setLoadState(-1); this.doLoadFailed({failed:block.failed}); } }, aniStep:function(source) { this.getScrim().applyStyle("opacity", source.value/100) }, aniStop:function(source) { this.getScrim().hide(); } });

Update: Latest code available on github

The view state framework is a relatively simple but extensible mechanism to manage the state of view controls. The definition of view control is loose but is intended to represent any control on which a user might expect to be able to "go back" to a previous state. The framework is not a view controller in MVC fashion but can be adapted to that purpose. I've done just that by extending the enyo.Panels control.

The view state framework has 3 components: enyo.ViewState, an implementation of ViewStateStrategy, and the consumer control.

ViewState is the consumer API for the framework and consists of a single property, path, and two events, onSaveState and onRestoreState. Each instance of ViewState must declare a unique path (in the traditional /path/to/me format) but all paths need not be at the same depth. The intent is that you could have a view (path:"/home") that contains additional views (path:"/home/items") and their paths would represent that heirarchy. In addition to the semantic value, this also allows the framework to persist and restore states of any parent paths of the saved path. So, if you tell ViewState to save the state of /home/items, it will also trigger a save of /home via the onSaveState. Similarly, if the state of /home/items is restored, the state of /home is also restored (via onRestoreState).

The management of view states is done through ViewStateStrategy instances. The ViewStateStrategy kind is basically an abstract base kind. It implements the API for strategies and provides some useful boilerplate code but doesn't store the state anywhere. The base API has three methods: push, pop, and register. As you might guess, push and pop are responsible for saving and restoring state, respectively. The register method associates a path with an instance of ViewState. This registration enables the magic of cascading save and restore described above.

To get things started, I implemented a couple ViewStateStrategy instances that work well in the browser: HashViewStateStrategy and HistoryViewStateStrategy. HashViewStateStrategy leverages the window.location.hash to store state and window.onhashchange to trigger state restoration. To accomplish this, it includes a portion of the state data (the key member) in the hash following the path. It then parses the key out onhashchange and passes it back to the ViewState owner in the onRestoreState event.

HistoryViewStateStrategy extends HashViewStateStrategy but uses the history API to store the state. This allows for more state data to be saved but still falls back to the key in the hash in absence of that state. This ensures that bookmarking the URL could still restore the application correctly.

N.B. I tried a couple alteratives that leveraged the component heirarchy before landing on the register method approach. Event bubbling seemed to be the most promising but introduced a couple problems. One, events would bubble up from a ViewState to ancestor controls but couldn't waterfall down to aunt/uncle (to continue the metaphor) controls. It's easier to explain with a picture but, since it didn't work out, I won't bother. Second, it forced the path heirachy to match the control heirarchy. That's probably safe normally but didn't seem like a necessary constraint.

The consumer of ViewState has very little work. It must:

create an instance of ViewState and provide it a unique path,

call enyo.ViewState.save when it wishes to save the state,

provide a handler for onRestoreState to update the control with the saved state, and

optionally, provide a handler for onSaveState if other ViewState instances have a child path defined

That's it!

More documentation to come but check out the example to see it in action.

By default, tapping a row in an Enyo list will "select" it. Sometime you might want finer-grained control over when selection happens and this post will offer a means to accomplish just that.

Selection is managed by an instance of enyo.Selection which is owned by the List control. You can control how selection behaves via two passthrough properties on the List control: toggleSelected and multiSelect.

toggleSelected is false by default which means tapping the row will always select it. By setting toggleSelected to false, tapping the row will toggle the selection back and forth. multiSelect is also false by default which means only one row will be selected at a time. By setting it to true, you can select multiple row (surprising, I know).

When a row is selected or deselected, it is rerendered by the List and your onSetupItem handler is called. In addition to an index property, the event will also have a selected property that reflects the current selection state of the row. Alternatively, if you need to retrieve the selection state of the entire list, you can call getSelection() on the List to get a handle on its underlying Selection instance.

Perhaps you've decided to include interactive controls in your list item such as a checkbox or button and have decided that tapping those shouldn't trigger row selection. Preventing the selection can use the same technique as triggering the selection: the tap method.

FlyweightRepeater does all the work for rendering list items using the flyweight pattern. It also implements a tap() method to catch any taps on child nodes to trigger selection. So, if you want to prevent selection, all you have to do is return true in your ontap handler to cancel bubbling thereby preventing the selection trigger.

What if you had several buttons and only wanted one control (like a checkbox) to control selection? Turns out that any subkind of Control can override tap() to handle ontap events (even without specifying an entry in your handlers hash!) because Control already declares the handler. So, if you create a custom kind which implements tap() to return true, selection will never be triggered. By adding a little exception logical to tap(), you can decide when selection occurs rather than on every tap.

Here's a working example:

Here's a quick and easy way to make a scrollable multi-line input field.

{kind: "extras.InputDecorator", alwaysLooksFocused:true, style:"width:100%;height:400px", components: [ {kind:"Scroller", style:"height:100%;width:100%", components:[ {name:"content", kind: "onyx.RichText", richContent:false, onchange: "inputChange", style:"min-height:100%"} ]} ]} ​

You have to set the height of the input decorator (either explicitly or as a fit:true child of a FittableRows instance) as well as the width (either by setting the width or changing it to display:block). By setting the min-height of the RichText control, you ensure that anywhere the user clicks in the area, the control will get focus but it will still expand if the user adds more content than the screen holds.

Live example on jsfiddle.net

Here's a quick way to adapt the Panels CarouselArranger to peek the previous panel.  By setting peekWidth on the Panels instance, this modified arranger will offset the left by that amount.  It isn't a perfect implementation (e.g. you can see the prior panel in the background when you slide the current panel away) but it would probably work in many cases.

For simplicity, the kind inherits from CarouselArranger.  I've only modified the arrangeNoWrap method so the contents are virtually copied verbatim.  Look for peek to find the customizations.

This is very much beta code but wanted to share how to add history to the Enyo2 Panels control.  For flavor, I even added html5 history support so if you're using a Panels controls as the main view controller (like Pane in Enyo1), you get quick back button support.

Here's the code as well as a quick example (full screen and in jsfiddle):

enyo.kind({ name:"extras.Panels", kind:"enyo.Panels", published:{ history:"" }, create:function() { this.historyChanged(); this.inherited(arguments); this.createComponent({kind:"Signals", onBack:"back", onpopstate:"statePopped"}); enyo.dispatcher.listen(window, "popstate"); }, historyChanged:function() { this.history = this.history || []; }, back:function() { this.history.pop(); // current if(this.history.length > 0) { var last = this.history.pop(); this.setIndex(last); } }, indexChanged:function() { this.inherited(arguments); if(this.history[this.history.length-1] !== this.index) { this.pushState(); } }, pushState:function() { if(window.history.pushState) { var c = this.getControls(); window.history.pushState({index:this.index}, "", "#"+c[this.index].name); } this.history.push(this.index); }, statePopped:function(source, event) { if(event.state) { this.back(); } } });

In enyo v1, making an input control appear focused was easy: simply set alwaysLooksFocused to true.  In enyo v2, the styling is delegated to an InputDecorator but it doesn't provide this same property.  Fortunately, it's easy to add to a custom subkind.

Had a random idea to implement a <style> tag in Enyo for global runtime CSS manipulation.  I'm thinking it might be handy to resize a bunch of elements as a result of window resize, for example.  I wrote a quick example in enyo v1 and ported the couple differences for v2.

You can either set the entire CSS via its published css property or set individual blocks via the set(classSpec, styleObject) method.

Thoughts?

Edit: Make a quick update to enable removing CSS from a selector by passing a null.  See the example below for removing the border from the children of .app.

To accomplish this, I'm scaling the background image differently for smaller screens than larger.

.animate { -webkit-transition:all 500ms ease-out; } /* portrait */ .app { background:#3e140c url(../image/bg.png) no-repeat 50% 100%; -webkit-background-size:auto 100%; } .app.new-game { -webkit-background-size:auto 200%; } /* landscape */ .app { -webkit-background-size:100% auto; } .app.new-game { -webkit-background-size:200% auto; }

The consequence of this was that changing orientations of the phone would cause WebKit to animate the width from 100% to auto along with the height from auto to 100%.  This turns out to be a rather jarring experience.  To avoid this, I added a sprinkle of script to the resize handler that removes the animate class when resize starts and readds it once its complete.  enyo.job does the work of ensuring reanimate only runs once.  In other words, it won't be constantly added and readded as the window is resized such as on a desktop browser.

There are two ways to create a scrim in enyo: globally through enyo.scrim or through the enyo.Scrim kind.  In either case, the scrim "fades" the entire view (usually in order to show a modal dialog or a spinner).  Another use case I'm currently experimenting with in Pirate's Dice is a local scrim -- one that only fades a particular portion of the app.

In my case, I'm using a scrim to disable the bid controls while other players are active.  I've tried a few different approaches (including drawers, dialogs, and hiding the controls) but a scrim seems to be a nice and simple way to handle it.

Making a scrim local is quite easy and mostly relies on a quick CSS customization.  First, create an instance of enyo.Scrim as a child of the control you wish to fade.

enyo.kind({ name:"ex.Hideable", kind:"Control", className:"extras-hideable", components:[ {name:"count", content:"Click Count: 0"}, {kind:"Button", onclick:"clicked"}, {name:"scrim", kind:"Scrim"} ], });

Notice I declared a className for the Control.  Next, I'll use that class name in css to limit the scrim to the bounds of my Hideable control.  By default, a scrim covers the screen by settings its position attribute to fixed.  To make it local, simply set the position of the parent control to relative and the scrim to absolute and you're set!

.extras-hideable { position:relative; } .extras-hideable .enyo-scrim { position:absolute; }

Finally, to show or hide the scrim, call the appropriate method on the scrim instance.  To illustrate, here's a silly example but it get's the point across.  Clicking on the button increments the count and changes the label.  Once the scrim is active (by clicking anywhere else in the control), clicking the button is blocked by the scrim.

enyo.kind({ name:"ex.Hideable", kind:"Control", className:"extras-hideable", components:[ {name:"count", content:"Click Count: 0"}, {kind:"Button", onclick:"clicked"}, {name:"scrim", kind:"Scrim"} ], create:function() { this.inherited(arguments); this.showing = false; this.count = 0; }, toggle:function() { this.$.scrim[this.showing ? "hide" : "show"](); this.showing = !this.showing; }, clicked:function(source, event) { this.count++; this.$.count.setContent("Click Count: " + this.count); event.stopPropagation();

Created a new Accordion control this evening in my enyo-extras repository.  If you're not familiar with this style control, jQuery has a similar example.  Take a look and feel free to fork and make improvements!