2013-11-12 4 views
1

В нотах this commit команда Ember ясно указала, что App.__container__.lookup() не может попасть на контроллеры. Вместо этого мы должны использовать свойство needs.Идиоматический способ использования __контейнер __. LookupFactory в Ember.js

Я понимаю обоснование этого и идиоматический способ доступа к одноточечным контроллерам.

Однако в моем приложении у меня есть некоторые случаи, когда мне нужны контроллеры экземпляров. В этом случае я использую App.__container__.lookupFactory() получить в прототипе, который я могу тогда create() или extend()

Есть ли лучший способ сделать это (без использования __container__

Edit:

Вот пример использования.

App.MyContainerView = Ember.ContainerView.extend 

    ... 

    addChildView: -> 
    @get("content").pushObject(App.MyChildView.create(...)) 

Приведенный выше пример будет толкать новый взгляд на стек (с учетом мнений, которые будут создаваться динамически)

Однако эти представления могут (могут?) Не иметь подходящего контейнера (и других свойств?), Установленного за счет создания с помощью App.MyChildView.create(). Это особенно верно в тех случаях, когда мы делаем частичную интеграцию Ember в существующее приложение.

Способ создания этих взглядов, а не будет:

App.__container__.lookupFactory("view:my_child").create() 

В этом случае все было бы нормально.

Существуют дополнительные прецеденты для создания контроллеров экземпляров вне контекста маршрутизатора .. но идея такая же.

+1

Можете ли вы предоставить код, чтобы понять ваш случай использования – Edu

+0

Если вы используете фабрику поиска, чтобы получить класс, почему бы вам просто не использовать имя класса в первую очередь? App.FooController так же хорош, как App .__ container __. LookupFactory ('controller: foo') и кажется гораздо более идиоматичным. – Kingpin2k

ответ

1

Я не знаю, если вы все еще ищете ответ. Я также борюсь с тем, как делать вещи «Углубленный путь».

Этот ответ поставил меня на правильном пути, и должны иметь отношение к вашему вопросу: "Please ensure this controller was instantiated with a container"

Что касается меня, я была такая же проблема, как и в приведенном выше вопрос: когда я вручную экземпляр моего App.AnyOtherController с App.AnyOtherController.create(...) , то внутри этого контроллера я не смог получить доступ к инъекциям зависимостей (например, к объекту сеанса, который я предоставляю всем моим контроллерам и маршрутам).

Инстанцирование тот же контроллер таким образом решает проблему, давая контроллер контейнера: this.container.lookupFactory('controller:any_other').create(...)

Вы должны быть в состоянии получить доступ this.container с любого зрения, и я думаю, любой контроллер, до тех пор, как они были с учетом контейнера.

Вы можете Ember.String.decamelize('AnyOther') преобразовать имя контроллера CamelCase в подходящую строку.

Больше на контейнерах здесь: http://ember.zone/beginning-to-understand-the-ember-js-container/

Если это не поможет вам , я все еще надеюсь, что это помогает кто-то там, в этом контейнере материал немного сложен в первом ...

+0

OMG 'этот.контейнер' конечно! Человек, я не могу поверить, что даже не думал об этом. –

+0

Зачем вам нужно было делать App.AnyOtherController.create (...)? вы не должны вручную создавать какой-либо контроллер – wallop

+0

Я помню, что мне приходилось создавать контроллер вручную по уважительной причине (или то, что казалось одним!). Имейте в виду, что этот ответ был основан на коде, который я написал для Ember 1.x, где мнения еще не были заменены компонентами, и многие другие вещи были разными. – Benito

Смежные вопросы