Skip to content

Commit

Permalink
Clean trailing whitespaces and fix new line at eof
Browse files Browse the repository at this point in the history
  • Loading branch information
@dmytroyarmak @samccone
dmytroyarmak authored and samccone committed Apr 12, 2014
1 parent 26ad368 commit fbeddb6
Show file tree
Hide file tree
Showing 26 changed files with 170 additions and 185 deletions.
140 changes: 70 additions & 70 deletions CONTRIBUTING.md
View file
Original file line number Diff line number Diff line change
@@ -1,35 +1,35 @@
Marionette has a few very specific guidelines in addition
to some of the standard guidelines that Github and open
source projects in general recommend. These guidelines
are here to facilitate your contribution and streamline
Marionette has a few very specific guidelines in addition
to some of the standard guidelines that Github and open
source projects in general recommend. These guidelines
are here to facilitate your contribution and streamline
the process of getting the changes merged in and released.

If you don't follow these guidelines, we'll still work
with you to get the changes in. Any contribution you can
make will help tremendously. Following these guidelines
will help to streamline the pull request and change
If you don't follow these guidelines, we'll still work
with you to get the changes in. Any contribution you can
make will help tremendously. Following these guidelines
will help to streamline the pull request and change
submission process.

## Documentation Fixes

If you notice any problems with any documentation, please
fix it and we'll get it merged as soon as we can. For
small things like typos and grammar (which we know I'm
terrible with), just click the "Edit this file" button
and send in the pull request for the fix. For larger
changes and big swaths of documentation changes, a regular
If you notice any problems with any documentation, please
fix it and we'll get it merged as soon as we can. For
small things like typos and grammar (which we know I'm
terrible with), just click the "Edit this file" button
and send in the pull request for the fix. For larger
changes and big swaths of documentation changes, a regular
pull request as outlined below is more appropriate.

## Pull Requests

See [Github's documentation for pull requests](https://help.github.com/articles/using-pull-requests).

Pull requests are by far the best way to contribute to
Marionette. Any time you can send us a pull request with
the changes that you want, we will have an easier time
seeing what you are trying to do. But a pull request in
itself is not usually sufficient. There needs to be some
context and purpose with it, and it should be done
Pull requests are by far the best way to contribute to
Marionette. Any time you can send us a pull request with
the changes that you want, we will have an easier time
seeing what you are trying to do. But a pull request in
itself is not usually sufficient. There needs to be some
context and purpose with it, and it should be done
against specific branch.

Try and stick to Marionette's existing coding conventions
Expand All @@ -39,7 +39,7 @@ for your code editor will help with this.

## General Submission Guidelines

These guidelines are generally applicable whether or not
These guidelines are generally applicable whether or not
you are submitting a bug or a pull request. Please try to
include as much of this information as possible with any
submission.
Expand All @@ -63,29 +63,29 @@ that you are having issues with.

### Provide A Meaningful Description

It doesn't matter how beautiful and "obvious" your fix is.
It doesn't matter how beautiful and "obvious" your fix is.
We have 10,000,000,000 things floating around the project
at any given moment and we will not immediately understand
at any given moment and we will not immediately understand
why you are making changes.

Given that, it is very important to provide a meaningful
description with your pull requests that alter any code.
Given that, it is very important to provide a meaningful
description with your pull requests that alter any code.
A good format for these descriptions will include three things:

1. Why: The problem you are facing (in as much detail as is
necessary to describe the problem to someone who doesn't
1. Why: The problem you are facing (in as much detail as is
necessary to describe the problem to someone who doesn't
know anything about the system you're building)

2. What: A summary of the proposed solution

3. How: A description of how this solution solves the problem,
3. How: A description of how this solution solves the problem,
in more detail than item #2

4. Any additional discussion on possible problems this might
4. Any additional discussion on possible problems this might
introduce, questions that you have related to the changes, etc.

Without at least the first 2 items in this list, we won't
have any clue why you're changing the code. The first thing
Without at least the first 2 items in this list, we won't
have any clue why you're changing the code. The first thing
we'll ask, then, is that you add that information.

Please refrain from giving code examples in altJS langauges like
Expand All @@ -94,23 +94,23 @@ and is generally easier all members in the community to read.

### Create A Topic Branch For Your Work

The work you are doing for your pull request should not be
done in the master branch of your forked repository. Create
a topic branch for your work. This allows you to isolate
The work you are doing for your pull request should not be
done in the master branch of your forked repository. Create
a topic branch for your work. This allows you to isolate
the work you are doing from other changes that may be happening.

Github is a smart system, too. If you submit a pull request
from a topic branch and we ask you to fix something, pushing
a change to your topic branch will automatically update the
pull request.
Github is a smart system, too. If you submit a pull request
from a topic branch and we ask you to fix something, pushing
a change to your topic branch will automatically update the
pull request.

### Isolate Your Changes For The Pull Request

See the previous item on creating a topic branch.

If you don't use a topic branch, we may ask you to re-do your
pull request on a topic branch. If your pull request contains
commits or other changes that are not related to the pull
If you don't use a topic branch, we may ask you to re-do your
pull request on a topic branch. If your pull request contains
commits or other changes that are not related to the pull
request, we will ask you to re-do your pull request.

### Branch from "dev" not "master"
Expand All @@ -124,51 +124,51 @@ work that is done in the dev branch.

### Submit Specs With Your Pull Request

Whenever possible, submit the specs (unit tests) that
correspond to your pull request.
Whenever possible, submit the specs (unit tests) that
correspond to your pull request.

I would rather see a pull request that is nothing but a
failing spec, than see a large change made to the real
I would rather see a pull request that is nothing but a
failing spec, than see a large change made to the real
code with no test to support the change.

In fact...

## Submit A Failing Spec If You Don't Know How To Fix The Problem

If you are stuck in a scenario that fails in your app,
but you don't know how to fix it, submit a failing spec
to show the failing scenario. Follow the guidelines for
pull request submission, but don't worry about fixing the
problem. A failing spec to show that a problem exists is
If you are stuck in a scenario that fails in your app,
but you don't know how to fix it, submit a failing spec
to show the failing scenario. Follow the guidelines for
pull request submission, but don't worry about fixing the
problem. A failing spec to show that a problem exists is
a very very very helpful pull request for us.

We'll even accept a failing test pasted in to the ticket
description instead of a pull request. That would at
We'll even accept a failing test pasted in to the ticket
description instead of a pull request. That would at
least get us started on creating the failing test in the code.

## Don't Be A Troll

It is very sad that we need to include this section of
It is very sad that we need to include this section of
the contribution guidelines...

If you are running in to a scenario with a problem, don't
be a troll. Comment like "does marionette even have tests?"
are not useful, funny or constructive. In fact, it may get
you blocked and reported for abuse to Github.
If you are running in to a scenario with a problem, don't
be a troll. Comment like "does marionette even have tests?"
are not useful, funny or constructive. In fact, it may get
you blocked and reported for abuse to Github.

Submit a useful comment describing the scenario that is
having an issue. Show us a failing test. Show us some
code that is not behaving the way the documentation says
Submit a useful comment describing the scenario that is
having an issue. Show us a failing test. Show us some
code that is not behaving the way the documentation says
it should. Be useful and work with us to fix the problem.

We're all for criticism and tearing apart Marionette for
the problems it has. Do it in a constructive and helpful
manner: "There isn't a test for this scenario. Here's a
rough idea for one that shows the problem." Tell us why
you don't like Marionette. Tell us that someone else is
building something better and why that other thing fits
your scenario and needs better than Marionette does. Just
do it in a manner that allows us to learn from your
experiences, instead of reacting to you being a troll
(likely causing us to get defensive and miss an opportunity
We're all for criticism and tearing apart Marionette for
the problems it has. Do it in a constructive and helpful
manner: "There isn't a test for this scenario. Here's a
rough idea for one that shows the problem." Tell us why
you don't like Marionette. Tell us that someone else is
building something better and why that other thing fits
your scenario and needs better than Marionette does. Just
do it in a manner that allows us to learn from your
experiences, instead of reacting to you being a troll
(likely causing us to get defensive and miss an opportunity
to learn something).
14 changes: 7 additions & 7 deletions docs/marionette.application.md
View file
Original file line number Diff line number Diff line change
@@ -1,9 +1,9 @@
# Marionette.Application

The `Backbone.Marionette.Application` object is the hub of your composite
The `Backbone.Marionette.Application` object is the hub of your composite
application. It organizes, initializes and coordinates the various pieces of your
app. It also provides a starting point for you to call into, from your HTML
script block or from your JavaScript files directly if you prefer to go that
app. It also provides a starting point for you to call into, from your HTML
script block or from your JavaScript files directly if you prefer to go that
route.

The `Application` is meant to be instantiated directly, although you can extend
Expand Down Expand Up @@ -95,7 +95,7 @@ object (see below).

## Starting An Application

Once you have your application configured, you can kick everything off by
Once you have your application configured, you can kick everything off by
calling: `MyApp.start(options)`.

This function takes a single optional parameter. This parameter will be passed
Expand Down Expand Up @@ -139,7 +139,7 @@ window.setInterval(function() {

### Request Response

Request Response is a means for any component to request information from another component without being tightly coupled. An instance of Request Response is available on the Application as the `reqres` property.
Request Response is a means for any component to request information from another component without being tightly coupled. An instance of Request Response is available on the Application as the `reqres` property.

```js
MyApp = new Backbone.Marionette.Application();
Expand Down Expand Up @@ -251,11 +251,11 @@ var r1Again = app.r1;
```

Accessing a region by named attribute is equivalent to accessing
it from the `getRegion` method.
it from the `getRegion` method.

### Removing Regions

Regions can also be removed with the `removeRegion` method, passing in
Regions can also be removed with the `removeRegion` method, passing in
the name of the region to remove as a string value:

```js
Expand Down
20 changes: 10 additions & 10 deletions docs/marionette.application.module.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -61,7 +61,7 @@ Definitions can either be a callback function or an object literal.
### Callback Function Definition

The callback function definition will be invoked immediately on calling
the `module` method.
the `module` method.

It will receive 6 parameters, in this order:

Expand All @@ -86,7 +86,7 @@ MyApp.module("MyModule", function(MyModule, MyApp, Backbone, Marionette, $, _){
// --------------------------

var myData = "this is private data";

var myFunction = function(){
console.log(myData);
}
Expand Down Expand Up @@ -268,7 +268,7 @@ MyApp.Parent.Child; // => a valid module object
MyApp.Parent.Child.GrandChild; // => a valid module object
```

When defining sub-modules using the dot-notation, the
When defining sub-modules using the dot-notation, the
parent modules do not need to exist; they'll be created for you. If a parent
has already been instantiated then that instance will be used.

Expand Down Expand Up @@ -307,7 +307,7 @@ immediately started.

Modules, like `Application` objects, can be configured to have initializers. And just like
an Application's initializers, module's initializers are run anytime that
the module is started. Further, there is no limit to the number of initializers it can have.
the module is started. Further, there is no limit to the number of initializers it can have.

Initializers can be added in the module's definition function.

Expand All @@ -328,7 +328,7 @@ MyApp.module("Foo", function(Foo){
### Start Events

When starting a module, a "before:start" event will be triggered prior
to any of the initializers being run. A "start" event will then be
to any of the initializers being run. A "start" event will then be
triggered after they have been run.

```js
Expand All @@ -345,7 +345,7 @@ mod.on("start", function(){

#### Passing Data to Start Events

`.start` takes a single `options` parameter that will be passed to start events and their equivalent methods (`onStart` and `onBeforeStart`.)
`.start` takes a single `options` parameter that will be passed to start events and their equivalent methods (`onStart` and `onBeforeStart`.)

```js
var mod = MyApp.module("MyMod");
Expand Down Expand Up @@ -399,8 +399,8 @@ When splitting a module across multiple files, it is recommended that you set

### Starting Sub-Modules With Parent

As you might expect, submodules default to starting with their parent module.
The starting of sub-modules is done in a depth-first hierarchy traversal.
As you might expect, submodules default to starting with their parent module.
The starting of sub-modules is done in a depth-first hierarchy traversal.
That is, a hierarchy of `Foo.Bar.Baz` will start `Baz` first, then `Bar`,
and finally `Foo`.

Expand All @@ -425,7 +425,7 @@ MyApp.module("Foo.Bar", function(){
this.startWithParent = false;
})

MyApp.start();
MyApp.start();
```

Now the module "Foo" will be started, but the sub-module "Foo.Bar" will
Expand All @@ -450,7 +450,7 @@ To stop a module and its children, call the `stop` method of a module.
MyApp.module("Foo").stop();
```

Modules are not automatically stopped by the application. If you wish to
Modules are not automatically stopped by the application. If you wish to
stop one you must call the `stop` method on it, or stop its parent module.
When you stop any parent module, all of its children will be stopped as well.

Expand Down
10 changes: 5 additions & 5 deletions docs/marionette.behaviors.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -4,11 +4,11 @@
The most important part of this class is that you **MUST** override the class level `behaviorsLookup` method for things to work properly.

## Documentation Index
* [API](#api)
* [API](#api)
* [Behaviors Lookup](#behaviorsLookup)
* [getBehaviorClass](#getBehaviorClass)
* [behaviorClass](#behaviorClass)

## API

There are two class level methods that you can override on the `Behaviors` class. The rest of the class is tied to under the hood implementation details of views.
Expand All @@ -18,8 +18,8 @@ There are two class level methods that you can override on the `Behaviors` class
This method defines where your behavior classes are stored. A simple implementation might look something like this.

```js
Marionette.Behaviors.behaviorsLookup = function() {
return window.Behaviors;
Marionette.Behaviors.behaviorsLookup = function() {
return window.Behaviors;
}
```

Expand Down Expand Up @@ -69,4 +69,4 @@ define(['lib/tooltip'], function(Tooltip) {
}
});
});
```
```
Loading

0 comments on commit fbeddb6

Please sign in to comment.