ghost/core/client/templates/application.hbs

{{#if isSignedIn}}
    {{partial "navbar"}}
{{/if}}

<main role="main" id="main">
    {{ghost-notifications}}
    
    {{outlet}}
</main>
{{outlet modal}}
Improve signin Ref #2413 - Remove fixture and use actual API - Store and send down actual logged in user data - Refactor isLoggedIn to use computed property on application - After signin, update user data in dependency container - Add CSRF to all routes and controllers via initializer - Update authenticated route to check for user.isLoggedIn - Add notifications for signin error - Add notifications.showAPIError helper - Add plumbing for refreshless signup to doSignUp in admin controller 2014-05-14 18:36:13 -05:00			`{{#if isSignedIn}}`
Ember.js: User fixtures + injection + login * Adding user fixtures for signin * Adds an initializer for the current logged in user. The created singleton object is injected into all controllers + routes. It can be used inside routes + controllers with this.get('user'). For simple development the object is instanciated with a userFixture. Once a proper login and api mock is in place, the fixture needs to be removed. * Added route 'login' on url '/ghost/ember/signin' * Added authenticated route with an error hook that redirects to the login route, if status 401 (unauthorized) is returned from REST API. * All "secure" routes now extend from authenticated route * Add /ghost/ember to noAuthNeeded routes in middleware 2014-03-11 17:23:32 +01:00			`{{partial "navbar"}}`
Improve signin Ref #2413 - Remove fixture and use actual API - Store and send down actual logged in user data - Refactor isLoggedIn to use computed property on application - After signin, update user data in dependency container - Add CSRF to all routes and controllers via initializer - Update authenticated route to check for user.isLoggedIn - Add notifications for signin error - Add notifications.showAPIError helper - Add plumbing for refreshless signup to doSignUp in admin controller 2014-05-14 18:36:13 -05:00			`{{/if}}`
Add basic template for Ghost admin in Ember Inspired and derived from: https://github.com/taras/Ghost/compare/ember-admin https://github.com/manuelmitasch/ghost-admin-ember-demo https://github.com/stefanpenner/ember-app-kit 2014-02-25 23:58:00 -05:00
Add admin prototype issue #2270 - from https://github.com/manuelmitasch/ghost-admin-ember-demo - Not working properly: added ic-ajax mock in app.js but promise not resolving => loading route always active 2014-03-02 15:30:35 +01:00			`<main role="main" id="main">`
Implement Notifications for Ember closes #2417 - Adds Notification(s)Component - Render notifications in application.hbs - Adds handleError in application route 2014-03-22 12:08:15 +00:00			`{{ghost-notifications}}`

Add admin prototype issue #2270 - from https://github.com/manuelmitasch/ghost-admin-ember-demo - Not working properly: added ic-ajax mock in app.js but promise not resolving => loading route always active 2014-03-02 15:30:35 +01:00			`{{outlet}}`
Creates Ember Modal infastructure resolves #2416 This is a pretty large commit but what it's adding are pretty fundamental to the admin app. - Creates top level actions on the ApplicationRoute for opening and closing modals. This allows sending the 'openModal' action from any template to open a modal. - Every modal template lives in 'templates/modals/{{modalName}}' - Each modal can have a backing controller of the same name that can provide additional control for that modal. Those controllers reside in 'controllers/modals/{{modalName}}' - Created the ModalDialog component which is where all the logic for the component resides. It's not at 100% parity with the existing Ghost modal system but it has the foundation for further fleshing out. It currently accepts parameters for styling how the modal should appear, which previously was defined in JS files in the Backbone admin. - This creates the 'delete all posts', 'delete this post', 'markdown', and 'upload' modal. Some are in more stages of completion than others, but I wanted to just get the foundation in place as fast as possible. - This also creates the UploadModal component which is a subclass of the ModalDialog component. The reason for this subclassing is that the UploadModal component directly accesses the DOM and when that occurs in Ember it should remain in a component definition. It's ready for extending to reach parity. Note: depending on needs the base ModalDialog class may need to be modified. 2014-03-31 00:07:05 -04:00			`</main>`
			`{{outlet modal}}`