New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Docs fixes #3200
Docs fixes #3200
Conversation
I should also note that I've been updating the live examples as I've gone.. soo... if there's something wrong with an update we'll have to revert.. but I'm not currently sure of a better way to do this. |
7febe1d
to
744bf5c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like it could be merged as it stands to me.
@@ -231,6 +229,39 @@ var ToolTip = Mn.Behavior.extend({ | |||
}); | |||
``` | |||
|
|||
#### Behavior Defaults | |||
`defaults` can be a `hash` or `function` to define the default options for your `Behavior`. The default options will be overridden depending on what you set as the options per `Behavior`. (This works just like a `Backbone.Model`.) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For this, I've been referencing ./basics.md#functions-returning-values
Marionette.Behavior.extend({ | ||
handleDestroyClick: function() { | ||
this.view.destroy(); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing indent
|
||
## Destroying A Object | ||
|
||
Objects have a `destroy` method that unbind the events that are directly attached to the | ||
instance. | ||
|
||
Invoking the `destroy` method will trigger a "before:destroy" event and corresponding | ||
Invoking the `destroy` method will trigger a `before:destroy` event and corresponding | ||
`onBeforeDestroy` method call. These calls will be passed any arguments `destroy` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd be tempted to chop this bit out and just link through to the trigger binding docs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah.. I think the oddity here worth documenting is anything you pass as arguments to destroy get passed to the destroy events which is unique to destroy
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair enough - we should still maintain the link and perhaps add a **Note**
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cool on the link.. I'll get that added.. what'd be in the **Note**
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant using the **Note**
to tell readers that destroy
will pass its arguments into its events and this is different to other event handling stuff.
4dbd45c
to
f199d80
Compare
Just a progress note.. I'm still looking to review Region, ChildViewContainer, and CollectionView docs, but I feel ok about the rest. I'm not really taking into account too many open issues at the moment.. just going through the docs and fixing issues that stand out to me. |
7c41e12
to
19ccbe9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The fiddles need updating to reflect the changes. That can be done afterwards (update without "Set as Base" is done) but before the docs are live.
Aside from that, 👍
|
||
var myView = new MyView(); | ||
myView.do('action:one'); | ||
myView.do('action:two'); | ||
``` | ||
|
||
[Live example](https://jsfiddle.net/marionettejs/zzjhm4p1/) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am guessing the fiddle will get updated later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just hadn't saved the fiddle on accident.. I think I've updated most of them already.
10faef0
to
b10578a
Compare
Ok mainly down to regions now.. |
I believe #3172 is resolved here |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome stuff. It's getting late so I'll have a proper look at the latter files in the docs later.
childViewEvents: function() { | ||
return { | ||
render: this.onChildRendered | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this necessary or can we just link through to the relevant documentation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good catch.. just copy-pasta'd didn't notice the 2nd part
|
||
// Events hash defines local event handlers that in turn may call `triggerMethod`. | ||
events: { | ||
'click .button': 'onClickButton' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be better to use an explicit name such as showMessages
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just moved this from elsewhere.. although I typically follow naming my function names after the event in this way. Then inside those functions it will procedurally call whatever needs to happen even if it is only showMessages
. Typically I follow this because when in the future the button needs to show message and then do something else do you rename the function? This is also the functionality behind triggerMethod
so I find it consistent. Right now, I suppose, my naming structure can be dangerous because of auto-proxying, but hopefully that can be disabled soon.
|
||
childViewTriggers: { | ||
'show:message': 'child:show:message', | ||
'submit:form': 'child:submit:form' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could be a bit confusing as it's close enough to the default childview:show:message
events. I find a totally different convention is usually more helpful for new developers to separate the concepts when building applications.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I'm all for that. for event names I pretty much follow https://github.com/jmeas/backbone.class-event-spec
However perhaps we can make a second pass on this stuff? I didn't really change anything style-wise I don't think.. most of this was changing incorrect or misleading things.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah no worries, I might have time over the next week or two to run through it all.
|
||
Behaviors, like views, have a `ui` attribute that can reference and cache DOM | ||
elements, just as in the `View`. For more detail, see the | ||
[`ui` documentation for views](./marionette.view.md#organising-your-view). | ||
[`ui` documentation for views](./marionette.view.md#organizing-your-view). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good spot, my Britishness must have slipped in :P
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
:-) This was changed elsewhere by somebody, but this link got left out
|
||
var MyObject = Mn.Object.extend({ | ||
initialize: function(){ | ||
this.triggerMethod('baz'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this supposed to be this.triggerMethod('foo', 'baz');
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ayep.. :-(
|
||
### Setting a `template` to `false` | ||
|
||
Setting the `template` to `false` allows for the view to create all of the bindings and trigger all view events without re-rendering the el of the view. Any other falsy value will throw an exception. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd be tempted to wrap the last sentence in italics: *Any other falsy value will throw an exception.*
One more todo: need to look at the view add:region remove:region events and API. |
Ok I think everything is on here @marionettejs/marionette-core I'm sure there's still more to do such as add more fiddles or additional adjustments.. but aside from errors, I'd recommend getting this in and making adjustments on subsequent PRs. |
Added a common file linking shared instance functions to the global documentation
Link to function returning values and fix the js example formatting
Also swapped some “ for ‘ for consistency.
6c9230c
to
cb3f706
Compare
@paulfalgout thanks) |
* Update basics getOptions * Fix Application doc menu * Fix approuter doc menu * Update behavior docs * Fix templating doc menu * Fix common Mn functions Added a common file linking shared instance functions to the global documentation * Fix application docs view lifecycle link * Fix Object docs * Fix viewlifecycle docs * Add lifecycle state methods and prerendered view documentation Partially resolves marionettejs#3162 * behaviors doc fixes Link to function returning values and fix the js example formatting * Fix destroying an object docs * Update view and templating docs * Fix advanced collectionview doc * CollectionView doc fixes * Revision fixes Also swapped some “ for ‘ for consistency. * Add undocumented view function * Updating Region documentation * Add missing API to region docs # Conflicts: # docs/marionette.region.md # docs/marionette.view.md
So far I've done three things:
I'm going to keep going on this PR, but at any point in the commits, if this is ready to merge, I can pull out the later commits or whatever to get it in and continue on another PR.