softlayer / sl-ember-behavior Goto Github PK

To beforeModel() in addon/mixins/route.js

"demoURL": "http://softlayer.github.io/sl-ember-behavior/"

https://github.com/softlayer/sl-ember-behavior#set-behaviors-on-behavior-service

Keys such as user.details should be in quotation marks.

Specifically, we have a gap in testing around the showContent property. Tests should be added to:

1. Test that the Ember.assert is thrown when the possible property is not a boolean
2. Test that the computed property returns the value isViewable() returns

The computing of this property can be triggered in these tests by calling .get( 'showContent' ) on the test subject.

May be impacted:

• sl-ember-behavior/tests/dummy/app/routes/application.js

  Line 17 in 5a1c26a

  Ember.keys( this.get( 'router.router.recognizer.names' ) ).forEach( ( route ) => {

• sl-ember-behavior/README.md

  Line 135 in 6d1e09c

  Ember.keys( this.get( 'router.router.recognizer.names' ) ).forEach( function( route ) { ... });

When Ember 1.13 is used by this addon

Ember.keys has been deprecated in favor of Object.keys - emberjs/ember.js@af98f59

When Ember 1.13 is used by this addon

Once ember-cli/ember-cli#4513 has been resolved and a new version of Ember CLI has been released containing this modification, any of the files affected by #69 will need to be modified.

https://github.com/simplabs/ember-simple-auth

The route restriction of this repo and the functionality provided by ember-simple-auth is what got me thinking about this. Chances are users will be using ember-simple-auth in their projects so would be nice to have integration with these two repos where appropriate to make their lives easier.

Once Ember CLI 0.2.8 is released and this repo is upgraded to Ember 1.13

"dependencies": {
"rimraf": "2.3.0"
}

..devDependencies.
"glob": "^4.5.1",

Assertions in code that check for Ember.typeOf() of object also need to check for symbol !== typeof

Will need to use jshint ignore entries like in https://github.com/softlayer/sl-ember-components/blob/688911c66d7a678fab6ff935b332d76593b5b400/addon/components/sl-chart.js#L95

I found myself in a situation where I would like to have custom behavior for individual providers.
However instead of defining a function I would like to return simple booleans. So the behavior data for an individual provider would look like this:

{
  project: true,
  project.edit: false
}

Currently I accomplish this by overriding the isAble function via an initializer. It would be nice to have this option out-of-the-box.

Changes to the isAble function to accomplish this idea:

      var behaviors = this.getWithDefault( 'behaviors', null ),
          isAble    = false,
          behaviorGroup,
          providerIsObject,
          providerBehavior;

[...]

      if ( behaviors && behaviors[behaviorGroup] && behaviors[behaviorGroup][behavior] ) {
        providerBehavior = ( providerIsObject  ) ? provider.behaviors[behavior] : true;

        isAble = ('function' === typeof providerBehavior) ? providerBehavior() : providerBehavior;
      }

• use @returns over @return
• use @return {undefined} when function does not return anything
• param types should be their most generic form - Array vs Ember.Array, Object vs Ember.Object - except for cases in which a more specific Ember.* type is warranted.
• types should be capitalized - Number, Boolean, Object, Function - all except for "undefined" which should be all lowercase.

They were added before v1.0.0 was published so think maybe they are stuck in a cache or something.

https://help.github.com/articles/closing-issues-via-commit-messages/

and replace with either throw new Ember.Error() or warn in addon/services/sl-behavior.js

http://git-scm.com/docs/gitattributes

• Align with the pattern in https://github.com/softlayer/sl-ember-components/blob/develop/tests/unit/components/sl-chart-test.js#L99
• Do not include test for Symbol

tests/unit/services/sl-behavior-test.js

addon/mixins/component.js

In README.md and CONTRIBUTING.md

tests/unit/services/sl-behavior-test.js

• "getBehaviorGroup() requires an Object to be provided"
• "getBehaviorGroup() "provider.behaviorGroup" must be a String or Function"
• "setBehaviors() requires an Object to be provided"
• "isAble() requires two arguments to be provided"
• "isAble() requires first argument to be a String"
• "isAble() requires second argument to be a String or Object"

"IE10",
"IE11",
"Firefox",
"Safari",
"Opera"

ember-cli/ember-cli#2634

README.md changes should include instructions to developer of consuming applications need to import and re-export their own service to use this one.

Through usage of a service in the sl-ember-components repo we have discovered that a component needing a service from the same library must have it exported in the fashion we were hoping to avoid due to needing it in the correct namespace and of the correct/known name. This means that instead of approaching this issue the way we did we will instead have to export a uniquely-named service to avoid any potential collisions with any other services "in the wild" used in a consuming application.

https://www.npmjs.com/package/phantomjs is a NPM wrapper around phantomjs binary. The version of phantomjs it installs is in https://github.com/Medium/phantomjs/blob/master/lib/phantomjs.js

TravisCI uses phantomjs version 1.9.8 (travis-ci/travis-ci#3225), same as npm phantomjs

There is some unnecessary complexity in the provider parameter when an object is supplied. In order to simplify this feature without sacrificing any functionality, the sl-able and sl-unable components will be revised as follows:

• The behavior parameter will be renamed resource and will otherwise remain unchanged
• The provider parameter will be renamed activity and will no longer accept an object, only a string corresponding to the Behavior Group key name used in the Behaviors structure
• An additional possible parameter will be added which accepts a boolean, computed property that evaluates to a boolean, or a function returning a boolean. This will take the place of the behaviors object passed in through the provider parameter since only one behavior (activity) is being evaluated in a component instance.
• The possible parameter will be observed to make the component responsive to changes in the value supplied.

We're not testing that the Ember injection is working correctly, but rather that we are using the correct service name within these files. A situation occurred where we renamed the service but missed the rename in these files

If the defined behaviors used by the Behavior Service were purely a true/false condition, where each behavior concept in the app is in the list then isUnable() being a pure inverse of a call to isAble() would be fine.

However, since all behaviors do not need to be pre-defined, the absence of one results in a false during a call to isAble().

Given this, is it reasonable that a call to isUnable() would return a true in such a condition, or should it return false in situations where the behavior has not been defined and then be an inverse to the remaining isAble() logic?

Ember.get( this, '_super' )( ...arguments );

and replace with either throw new Ember.Error() or warn in addon/mixins/component.js

Once softlayer/sl-ember-test-helpers#66 is resolved

Should it check that the route specified for "unableRoute" is a valid one before attempting to route there or should the responsibility for providing an accurate route value rest solely with the consuming application/developer(s)?