# Should discourse have so much logic in their modal views? **URL:** \ **Category:** Uncategorized\ **Created:** [March 12, 2013, 1:07pm UTC](https://discuss.emberjs.com/t/should-discourse-have-so-much-logic-in-their-modal-views/344 "2013-03-12T13:07:32Z")\ **Posts on this page:** 1\ **Showing post:** 9
**Author:** ![ashaegupta](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/ashaegupta/32/3868_2.png) [@ashaegupta](https://discuss.emberjs.com/u/ashaegupta)\ **Post date:** [March 19, 2013, 6:11pm UTC](https://discuss.emberjs.com/t/should-discourse-have-so-much-logic-in-their-modal-views/344/9 "2013-03-19T18:11:42Z")
I think a good, clean approach (especially with complex modals) is to have a stateManager control when a modal is shown or hidden, and more precisely, when a modal is inserted or removed from the DOM. My basic architecture for this in pseudocode is: - create a modalStateManager object and an instance that is globally accessible - put an outlet (e.g., {{outlet modal}} for the modal in your main template (i.e., the template where the user will click to open the modal) - when user clicks to open modal, call an open function on your modalStateManager instance - open function renders the modalView, modalTemplate and modalController into the modal outlet. (in old ember, you could do this with connectOutlets, I believe the new way is with renderTemplate) you’d then also have some function that closes modal (and can destroy the modal). I actually did a presentation on this topic at the Ember.js meetup: it’s old ember, but the architecture should still be valuable. [https://speakerdeck.com/ashaegupta/managing-modals-and-other-non-url-based-views-in-ember-dot-js](https://speakerdeck.com/ashaegupta/managing-modals-and-other-non-url-based-views-in-ember-dot-js) --- _[View the full topic](https://discuss.emberjs.com/t/should-discourse-have-so-much-logic-in-their-modal-views/344)._