enyojs / enyo

A JavaScript application framework emphasizing modularity and encapsulation

Looking for the issue tracker?

It's moved to https://enyojs.atlassian.net.

---

Quick Info

Core

This repository contains Enyo core. We've pared it down to the essentials, so folks can work at the metal. Widget sets, localization code, and other fancy bits are in separate repos.

Warning about file://

Note: In Chrome, various samples will not work from file:// URLs because of Chrome's security policy. To work around this, run your app from a local http server, use the --allow-file-access-from-files flag when starting Chrome, or use the online samples at http://enyojs.com.

What Is Enyo?

Enyo is an object-oriented JavaScript application framework emphasizing modularity and encapsulation. Enyo is suitable for both small- and large-scale applications.

Enyo 1.x was the underlying framework used to develop applications for HP's TouchPad tablet. Enyo as shipped on the TouchPad included an complete set of user interface components and service wrappers. What you will find here is Enyo 2, what we informally call core: the primary infrastructure needed to support any number of Enyo-based libraries. Enyo 1.x is now available under an open-source license.

Enyo was designed from the beginning to be highly extensible. This repository reflects a small working set of code that may be expanded with any number of libraries or plugins.

Enyo 2 is lightweight, easy to digest, and powerful.

What Do I Get?

The core code includes the Enyo kernel, the DOM extensions, some Ajax (XHR) tools, and basic wrapper kinds for a lot of DOM form elements. We believe this is a useful working set of tools.

Enyo 2 provides a modularity concept (Component) and a view concept (UiComponent). The DOM aspect includes a widget concept (Control) and an extensible event system (Dispatcher). Ajax resources include basic XHR functionality and an implementation of XHR as a Component (Ajax). In the UI arena, Enyo offers base kinds for common controls like buttons and popups, along with layout-oriented kinds, such as platform-optimized scrollers.

By themselves, these pieces are sufficient to create large applications using the Enyo encapsulation model. Developers who only want this low-level code are encouraged to roll-their-own application and UI layers. For those who want a richer set of tools, we have several pre-built libraries available.

Why Do I Care?

First is our emphasis on cross-platform compatibility: Enyo core works on both desktop and mobile browsers.

Second is Enyo's building block approach to applications. Each piece of an application is a Component, and Components are constructed out of other Components.

For example, it's easy to define the combination of an <input> tag and a <label> tag in one LabeledInput Component.

Now I can use (and re-use) LabeledInput as one atomic piece.

But that's just the beginning. Ultimately, large pieces of functionality may be exposed as single Components--for example, a fancy report generator, or a color picker, or an entire painting application.

Use the Enyo encapsulation model to divide and conquer large projects. No particular piece of an application need be especially complex. Because the combining of pieces is central, factoring complex functionality into smaller pieces comes naturally. Moreover, because of the modularity, all these pieces tend to be reusable--in the same project, in other projects, or even by the public at large.

This is all part of our strategy to allow developers to focus on creativity and Avoid Repeating Themselves.

That's a Lot of Talk

The core Enyo design was proven out by the complex applications HP developed for the TouchPad platform. We don't claim that this was particularly easy; there were a lot of hardworking developers on the apps teams, but we are confident in the efficacy of Enyo's guiding principles on a large scale.

But don't take our word for it; see for yourself.

Samples

All samples reside in a consolidated sample app for Enyo and its libraries: enyo-strawman.

Copyright and License Information

Unless otherwise specified, all content, including all source code files and documentation files in this repository are:

Copyright (c) 2012-2015 LG Electronics

Unless otherwise specified or set forth in the NOTICE file, all content, including all source code files and documentation files in this repository are: Licensed under the Apache License, Version 2.0 (the "License"); you may not use this content except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

enyo's Issues

UiComponent - destroyClientControls or destroyClient?

I'm a little confused by how UiComponent deals with chrome. It seems to me that if a user calls destroy on an instance that has chrome, surely the contents of the client should be destroyed and not the entirety including chrome - at least this is the behaviour I would expect.

So instead of having destroyClientControls, destroy should perform that functionality and a new function, destroyClient should be introduced for special cases where the user intends to destroy the chrome (which most of the time they won't be intending to, but may accidentally do so with the current implementation).

I understand if you put this down to personal preference but I do wonder how many others found the interface a little unintuitive.

enyo.json.parse() missing reviver support

The following...

parse: function(inJson) {
  return inJson ? JSON.parse(inJson) : null;
}

Does not allow for the optional reviver function argument to JSON.parse( object [, reviver ]).

enyo.js script loader breaks on IE9

http://forums.enyojs.com/discussion/351/enyo-samples-and-ie8#Item_0

The code in both copies of enyo.js uses node.attributes.item without range checking. This causes an exception instead of a null return on IE9.

Propose: enyo.now()

There are many uses of new Date().getTime(), I suggest creating an API to reduce bytes, something simple like:

enyo.now = function() {
  return new Date().getTime();
};

enyo.RichText does not fire onchange events

Tested on Google Chrome.

Flick event should have origination pixels

The flick event in gesture.js should also save/emit the pixel information of the original touch/mousedown location.

Need Coding Style Guide (was: code style is mixed bag of inconsistency)

• Mixed variable initialization lists: single var-single line comma separated, single var-multiline comma separated, multi var-multiline... reading the code is as convoluted as reading this sentence.
• Mixed quotes... sometimes single, sometimes double. Pick one?
• Mixed use of == and === (beyond acceptable null/undef checks)
• Mixed, inconsistent use of syntactic whitespace

I'm up to the challenge of cleaning all this up in one fell swoop - let me know

It's impossible to prevent change of url in ontap handler

Not sure if that's a bug, but docs encourage usage of ontap instead of onclick to wrap both mouse and touch events.

I would like to handle my links without having them change my url, which I usually can do with e.preventDefault(). But in case of ontap doing inEvent.preventNativeDefault() does nothing, since ontap is fired on mouseup event. So I ended up with binding onclick and preventing change on url there. Any thoughts?

enyo.Scroller programmatic touch scrolling does not adjust position

I'm using this code to implement an enyo.Scroller (currently using the latest bleeding edge; thanks for fixing the entire-page-scroll problem before I even had a chance to post about it Steve Orvell!):

Javascript

components: [
    {name: "listScroller", kind: "enyo.Scroller", nofit: true, classes: "recent-items-scroller", components: [
        // A couple of controls here: empty message (which gets hidden if there's content),
        // and a generic compoment that is populated via DOM methods
    ]}
]

CSS

.recent-items-scroller {
    position: absolute;
    top: 94px;
    left: 24px;
    right: 24px;
    bottom: 108px;
    padding: 24px 2px 0;
    overflow: hidden;
    -webkit-overflow-scrolling: touch;
}

.enyo-touch-scroller {
    overflow: hidden;
}

This works great in iOS 5 and desktop browsers (because scrolling behavior falls back on the native scrolling, and -webkit-overflow-scrolling: touch ensures that iOS 5 provides things like flicking). However, on iOS 4.3 in the simulator (since I don't have a device handy), I am able to tap and drag to move the content around, but when I release the content animates back to the top scroll position. I have not been able to locate where exactly in the Enyo source code this problem is being generated, but I assume it's a shortcoming of TouchScrollStrategy. It is also possible that I'm misunderstanding what I need to do in my code to get styling running, though, so if you are able to get scrolling to work on iOS 4.3 and other places where Enyo needs to provide its own touch-based scrolling solution, let me know what JS and styling you're using and I'll test it out in my own app.

calling render() before parent is ready creates a bogus node

Portions of an Email from Ben Combee:

As an optimization, createComponent doesn't cause a rerendering so you can make a mess of them. What was happening is that after my loop of createComponents, I'd call render() on the container control. This would cause it to generate all the HTML and store it in a DOM node. However, since this was before my app object had been rendered info the document.body, the DOM node created here would never actually end up on the page, as it was bypassed in the renderInto call since that generates new HTML.

The effect of this was that .. it would render into the original orphaned DOM node instead of the one visible in the document.

Steve Orvell ... suggested that I check hasNode before calling render so I don't try to render before the original node is created. That solved my problem, but it makes me wonder if render() is ever useful when there's no existing node for a control. I'd suggest that render just no-op in the case that a control has a parent but that parent hasn't been rendered to a node already. If we didn't want to make that change, we should at least document this limitation.

FittableLayout can throw an exception in _reflow

In FittableLayout.js, around line 40:

        var n = this.container.hasNode();
        // calculate available space
        if (n) {
            // measure 1
            p = enyo.FittableLayout.calcPaddingExtents(n);
            // measure 2
            s = n[cMeasure] - (p[mAttr] + p[nAttr]);
            //console.log("overall size", s);
        }
        //
        // calculate space above fitting control
        // measure 3
        var fb = f.getBounds();
        // offset - container padding.
        a = fb[mAttr] - ((p && p[mAttr]) || 0);

the variable p is undefined if n is undefined. Not sure what the right behavior is here - if the container doesn't have a node (yet), should _reflow just exit?

I only saw this hit once, when I was having other initialization problems, so it's probably not a common problem.

minify.sh doesn't work in a clean repo

Even in a clean pull of the repo, running "./tools/minify.sh" throws this error:

node.js:134
throw e; // process.nextTick error, or 'error' event on first tick
^
TypeError: Cannot call method 'replace' of undefined
at Object.rewrite (eval at (/home/fahhem/projects/webvnc/frontend/enyo_clean/tools/minifier/node_modules/walker.js:11:10))
at Object.walk (/home/fahhem/projects/webvnc/frontend/enyo_clean/tools/minifier/node_modules/walker.js:38:20)
at Object. (/home/fahhem/projects/webvnc/frontend/enyo_clean/tools/minifier/minify.js:170:8)
at Module._compile (module.js:411:26)
at Object..js (module.js:417:10)
at Module.load (module.js:343:31)
at Function._load (module.js:302:12)
at Array. (module.js:430:10)
at EventEmitter._tickCallback (node.js:126:26)

This is running nodejs v0.4.12.

It seems to want an argument, but no matter what I put (enyo.js, source/package.js, package.json) it fails with a variety of errors and there's nothing that explains how to use it. The Readme just says you need nodejs, and the help just shows flags, not arguments.

create test suite for Ajax lib including back-ends for CORS and JSONP

We need test modules to for enyo.xhr, enyo.Ajax, and enyo.Jsonp.

It may need to be separate from the standard enyo/tools/test suite, because it will require back-end infrastructure to test against.

I believe the preferred back-end is node, but we can use PHP at first if it's faster.

Primary use is for core team smoke-testing and QA, not necessarily for end users.

Using 'br' as tag for Control causes 2 <br> to be output

enyo.Control.prepareTags checks enyo.Control.selfClosing for an entry matching the tag of the Control. If it finds it, it won't render a closing tag; if not, it does. selfClosing is missing "br" (only contains "img" at the moment) so it renders both an opening and closing BR which gets interpreted (in Chrome at least) as 2 BRs.

seems to be the only one that causes a rendering issue so may not be significant to worry about the others (e.g. hr, link , meta)

enyo.map = enyo.forEach is a semantics mis-match

In JavaScript, map and forEach have specified semantics that are not the same.

Review enyo.Input and enyo.Checkbox api

enyo.Input publishes 'onInputChange', presumably to fire real-time change events on an input. Input also supports the standard DOM event 'onchange', which fires only when an input loses focus (or in other cases?).

Afaict, Checkbox doesn't ever fire 'onInputChange' and only supports 'onchange'.

Suggest we add some docs to Input to describe the different events and which to use in what scenario. Possibly 'onInputChange' should be 'onRealtimeChange' or something, else I've misunderstood it's purpose. Also, Checkbox should probably fire 'onInputChange' along with 'change'.

The overall goal is for form-type inputs to have consistent API as much as possible (e.g. 'value').

enyo.isString use of instanceof operator is unnecessary

The use of instanceof String in enyo.isString is completely unnecessary. Additionally, there are no tests to support its inclusion.

Can provide patch

Hold Events on webOS/Tablets

I have been having issues with onhold events on my TouchPad.

Looking at the code, I think one problem is that a touch event isn't necessarily as steady as a mouse click. Therefore, I might add a minPixelDrift and original pixel location variables to enyo.gesture. Then, for every move(), if the event has drifted beyond the minPixelDrift distance from the original pixels, only then would it call cancelHold().

The event still isn't working perfectly, but I'll add more here if I improve it more.

Chrome components in v2

Noticed that controls with chrome do not work the same in v2 as in v1. In v1, you used the special chrome member to declare those components. In v2, any components declared in a kind are treated as chrome if one of them is named "client" (or whatever controlParentName is).

The consequence of this is when you declare a kind (Kind A) that inherits from another kind (Kind B), any components declared in Kind A override those declared in Kind B rather than placed within Kind B's "client" control. I tried to illustrate this in a jsfiddle example. Hopefully the example is more clear than my explanation.

http://jsfiddle.net/8WgBY/4/

Occasional Segmentation Fault when using destroy (iOS 5.1.1)

I'm getting an occasional segmentation fault (around 5-10% of the time) when trying to use destroy to clear out controls in iOS 5.1.1. In my app I'm using an enyo.Animator to fade the control to transparent, then calling destroy to remove it. It's working fine in Chrome.

Things I've tried:

1. this.destroy - I initially thought that this might be causing it because I was destroying the control which I was still bound to it's context
2. enyo.asyncMethod with this.parent as the context - tried this because I thought that if I executed it asynchronously with the parent as the context it would fix this issue but no dice.
3. tried using enyo.bubble with a handler in the parent to remove the control but once again no dice.

This is running on Enyo 2.0 beta 4 with iOS 5.1.1 and Phonegap 1.7.0 built using Phonegap Build. It seems to happen most frequently right after app launch, and when there's a long delay between destroying controls. If I destroy a whole bunch all at once I don't often see the segmentation fault.

createComponents has no return value.

Having it return the created components was very useful in enyo 1.0 when trying to track new components and ignore their existing siblings. Is there a technical reason this has been changed? I noticed that documentation now explicitly states that it has no return value.

DragStart Event produces a Release Event before it.

It seems to me that the order of events for dragging might have a bug. When listening to them I get this order:

down
hold
release
dragstart

It does not seem right to get a "release" event when you start dragging because the user has not released the button yet.

API docs should support an all-in-one view suitable for offline use

Would love a way to make the doc viewer just build one large document with internal links that could be saved as HTML and used to prepare PDF, ePUB, or other offline formats.

enyo.isArray should delegate to native Array.isArray

enyo.isArray should delegate to native Array.isArray, whenever possible.

enyo.bind should delegate to Function.prototype.bind

enyo.bind should delegate to Function.prototype.bind, whenever possible.

enyo.xhr has no option for customizing fields on the generated xhr object before sending

As the XHR spec evolves, fields have been added to the xhr object. In particular, the 'withCredentials' is an important new field to support CORS requests. Currently there is no way to access this field in enyo.xhr.

Make it so that a list is sortable

Right now they can only be in the order added. I believe Tomomi mentioned that this was because Enyo did not have support for sortable lists.

A good example of this would be the bookmark list on the Touchpad browser. It is not sortable and only usable in the order the bookmarks were added. This is a net loss of functionality from pre-3.0.x webOS where the Mojo based browsers could reorder with no issue.

Cross reference issue link:
https://github.com/isis-project/isis-browser/issues/4

enyo.forEach should delegate to Array.prototype.forEach

enyo.forEach should delegate to Array.prototype.forEach, whenever possible.

The shim should also match the spec, currently it does not:

• forEach should return undefined. map and filter are the return methods - not forEach
• Is actually an implementation of filter, except that it compares with undefined instead of false... wtf?
• missing sparse array handling

Can provide patch

Bug in code on enyojs.com

Sample code on the front page of enyojs.com has a bug.

Missing a closing brace in the following, which produces a syntax error.

new enyo.Control({content: "Hello From Enyo", classes: "foo", 
    style: "color: red", attributes: {tabIndex: 0}).write();

This probably isn't the right place for this, but I didn't want to pollute your forum.

args.callee in enyo.kind.inherited is arguments.callee

args.callee in enyo.kind.inherited is arguments.callee (as far as I can tell). arguments.callee is deprecated and disallowed in strict mode

https://developer.mozilla.org/en/JavaScript/Reference/Functions_and_function_scope/arguments/callee

Awkward Repeater API

Because each component in a Repeater needs to be name-spaced, the Repeater creates a unique owner for each iteration. This gambit makes it difficult to capture events from row items without creating a custom item kind.

Explore variations on this solution.

use getAttribute(..).value instead of getAttribute(..).nodeValue

Ben Combee said

"Saw a warning in Firefox from the loader code, traced it to this DOM v4 change

https://developer.mozilla.org/En/DOM/Attr

Attr is no longer being based on Node, so you use value instead of nodeValue to get the value out of an attribute. This affects the code in enyo.js that pulls arguments out of the enyo script tag. .value is specified for attributes all the way to DOM level 1, so it should be safe to change it, although I've not tested anywhere but FF and Chrome."

No way to actually catch a key event

Currently the enyo.dispatcher code just checks from the event's target and up for an enyo object with that id, which means that most key events that occur with target=document.body nobody can catch it through the normal method.

I spent a half-day trying to catch the key* events in enyo, and it was fixed with this code at the top of enyo.dispatchers.findDispatchTarget (in source/dom/dispatcher.js)::

if(n == document.body) n = n.firstChild;

waterfall events in Control are not sent to non-Control Components

mod_pagespeed can break enyo script detection

mod_pagespeed can inline scripts which removes the meta information we look for in enyo.locateScript

enyo.requestAnimationFrame() not documented in the API docs

enyo.cancelRequestAnimationFrame() is, but there is no description.

Google Map unintentional failure in 2.0.2b

I know google maps is not officially supported but from 2.0.1b to 2.0.2b I can no longer properly attach a google map to this.$.map.node in my kind.

I am new to Enyo, so I'm probably not doing it entirely correct. but I also tried the link above: https://github.com/morethanreal/enyo-googlemap

Using just that example also causes the content to load just a gray panel, It looks like Google's JavaScript and map are running but none of the image tiles ever load.

enyo.kind({
  name: "mapTest",
  kind: enyo.Control,
  components: [
    {name: 'map', classes: 'map_canvas'}
  ],
  create: function () {
    this.inherited(arguments);
  },
  rendered: function () {
    if (this.hasNode()) {
      this.createMap();
    }
  },
  createMap: function () {
    if (this.$.map.hasNode()) {
      new googlemaps.Map(this.$.map.node, {<MAP_CONFIG_OPTS>});
    }
  }
};

I can change back and forth between 2.0.1b and 2.0.2b, without changing any of my Enyo components and 2.0.2b somehow no longer works with Google Maps correctly.

Thank you for any help.

p.s.
originaly posted and reqested to be moved here via:
http://forums.enyojs.com/discussion/comment/974#Comment_974

enyo.indexOf should delegate to Array.prototype.indexOf

enyo.indexOf should delegate to Array.prototype.indexOf, whenever possible.

The shim should also match the spec, currently it does not:

• missing fromIndex argument
• missing sparse array handling
• Will match Abstract Equality Comparison , should match as Strict Equality Comparison

Can provide patch

[Documentation -> Creating Controls] source code need fix.

Documentation -> Creating Controls
-> The Basics

handlers: {
down: "downHandler", --> ondown: "downHandler",
up: "upHandler" --> onup: "upHandler"
},

---

-> Controls in Controls: It’s Those Turtles Again

circleTap: function(inSender, inEvent) {
var lights = {red: "tomato", yellow: "#FFFF80", green: "lightgreen"};
if (this.lastCircle) {
this.lastCircle.setBgColor("black");
}
this.lastCircle.setBgColor(lights[inSender.color]); -> this.lastCircle = inSender;
this.lastCircle = inSender; -> this.lastCircle.setBgColor(lights[inSender.color]);
}

enyo.Ajax should save the XHR object from the enyo.xhr.request call

Devs need to be able to inspect that XmlHttpRequest object to use platform features or modify requests. Currently, we don't save the enyo.xhr.request result into a property of the enyo.Ajax object, so you can't get at it after the request has been made.

Enyo2 lists do not scroll in the Pre3 web browser

The list example at http://enyojs.com/samples/list/ does not scroll in the Pre3 web browser.

enyo.call docs aren't realistic

/**
  Calls named method _inMethod_ (String) on _inObject_ with optional arguments _inArguments_ (Array), if the object and method exist.

    enyo.call(window.Worker, "doWork", [3, "foo"]);
*/

Perhaps you're unaware, but there is an api for Web Workers whose constructor is named Worker that exists as a property of the global object (window). This example is misleading and confusing.

Modify enyo.JsonpRequest to use onerror with script tag

We should do some basic error handling with the JSONP processing by setting onerror on the added script tag and handling code to fire the async's error method.

(Moved from extra library repo to enyo due to code movement)

Style property on a kind ignored if trailing ; is missing.

As of beta 4 the style property does not appear to be properly applied if the final ; is missing. For example:

{ kind: enyo.Control, content: "foo", style: "font-size: 30px; color: red" }

In this case the color style will not be applied, unless it is changed to:

{ kind: enyo.Control, content: "foo", style: "font-size: 30px; color: red;" }

I suspect the problem is in the "stylesToNode" function in dom/Control.js which sets the node's style.cssText to this.style + this.domCssText. Depending on the value of domCssText this could cause the problem I'm seeing.

enyo.Select .render() method in IE 9

When Creating enyo.Select drop downs if I call a .render() on the enyo.Select Kind in IE all the options are gone, looking at markup it mashes all the components into a single string of text (as show below).

enyo.kind({
    name:  'stateSelection',

    components: [
        {name: 'stateSelectWrapper', components: [
            {name: 'statesDropDown', kind: enyo.Select, onchange: "selectedChanged"}
        ]}
    ],

    rendered: function () {
        this.setAvalableStates();
    },

    setAvalableStates: function () {
        var statesList = {"AL":"Alabama","AK":"Alaska","AZ":"Arizona"};
        for (var id in statesList) {
          this.$.statesDropDown.createComponent({
            content: statesList[id],
            value: id
          });
        }

        // This breaks in IE
        this.$.statesDropDown.render();

        //This Works in IE
        //this.$.stateSelectWrapper.render();
    },

    selectedChanged: function () {}
});

If I use .render() on the containing element stateSelectWrapper all options render properly into the DOM.

Not sure if its intended/I'm missing something, but thought I would give a heads up.

gesture.js uses addEventListener without guard, breaks in IE

there's an unguarded call to document.addEventListener in gesture.js to hook up scroll wheel events

enyo.Component::getComponents only returns owned components

Which by default does not include components passed to the constructor. Hence in this example

components: [
    {name: "someComponent",  components: [
        {content: "one"}, {content: "two"}
    ]}
],
getSomeComponents: function() {
    // returns an empty list
    this.$.someComponent.getComponents();
    this.$.someComponent.destroyComponents();
}

getComponents does not work as I'd expect. Neither does destroyComponents. Is this behavior intended?

document load-time optimizations and patterns

We need documentation and examples to demonstrate:

• load order issues
• pacification ('loading') screens
• minification, debug vs build
• lazy-creation application design
• performance pitfalls

Samples does not escapeHtml content property

Control(DomNodeBuilder) kind had allowHtml property on Enyo1, It is disappeared on Enyo 2.
However, every samples(tutorial) of Enyo2 dose not escapeHtml Content property.

For example, Flickr Search sample dose not escape search results, I can insert Html tag to search results.

The below is the steps to reproduce this issue.

1. Open "http://enyojs.com/samples/flickr/" on Web Browser.
2. Search 'blockquote'.
3. Scroll results list.

Uploaded screenshot to the address below.
http://zawakei.web.fc2.com/testcode/work/20120128_01/index.html

context of _createComponent gets to adjustComponentProps instead of the target container

The various methods of creating components via another Component ultimately funnel into _createComponent. Whatever is "this" at that point currently performs "adjustComponentProps", and does things like select the defaultKind.

For Controls, it would be more convenient if the ultimate container was able to "adjustComponentProps" instead. That way defaults like defaultKind would be localized, and there is no longer semantic difference between

this.createComponent({...container: foo}

and

foo.createComponent({...owner: this}