Comments 9
protected $_resultPageFactory;
public function __construct(
\Magento\Backend\App\Action\Context $context,
\Magento\Framework\View\Result\PageFactory $resultPageFactory
) {
parent::__construct($context);
$this->_resultPageFactory = $resultPageFactory;
}
Все контроллеры наследуют свойство $this->resultFactory в котором хранится Magento\Framework\Controller\ResultFactory, т.е. достаточно сделать
public function execute()
{
return $this->resultFactory->create(ResultFactory::TYPE_PAGE);
}
и тем самым избавиться от необходимости в некоторых случаях пустого конструктора ради 1 лишней зависимости.
Но все же как не крути получается быстрее — не на много но быстрее. Ко второй магенте стоит относится как к навороченому фреймворку на базе которого собран конечный продукт из кучи модулей.
Так же можно было б сказать и про первую (или любую другую похожую модульную систему) — но все же в м2 это поярче выражено.
И да, профит в даном случае огромный есть только тогда когда систему заведомо будут поддерживать очень долгое время и большое количество разных людей.
В других случаях, затраты на разработку с лихвой сжирают возможный профит.
М2 для девелопера с чуством перфикционизма и желанием сделать все как по книжке будет очень уютным местечком. Но проблема в том что eCommerce в большенстве случаев не нужно качество, ей нужна быстрота внедрения всего нового что может принести выгоду. К сожалению это не про вторую магенту — как не крути но времени нужно потратить больше на разработку, по сравнению с первой магентой, почти во всем.
Хотя, она все же чертовски интересная:)
К сожалению перфекционистам в M2 опасно — она еще очень сырая, неоднородная по реализации система с незавершенными архитектурными решениями (те же репозитории, все еще полностью не заменившие ресурс-модели). Любой владелец магазина на М2 — доброневольный бета-тестер. Работа над выправлением этой ситуации идет, но сможет ли команда разработчиков ее выправить — вопрос открытый. Я бы поставил на них, если бы они отказались от обратной совместимости (которой и так нет) и провели генеральную чистку и реструктуризацию кода и данных, но это стало бы уже М3. Таких маневров community может и не выдержать, а без своих расширений Magento превратится в тот же Shopify, только еще и на своем "железе". Ну а пока разработчики борются со сложностью и, судя по тому, что тесты на Travis'е у них не проходят уже около месяца, борьба идет ожесточенная.
Хотя, она все же чертовски интересная:)
А вот тут полностью согласен :) Весьма любопытный пример распределенной разработки приложений.
Богатая функциональность, получаемая "из-коробки" — это раз. Большое кол-во расширений основного функционала, созданных сторонними разработчиками — это два. Все еще значительное community (best practice & support, как отметил коллега Sergiy) — это три. И плюс куча времени и средств закопанного в нее как разработчиками (основного функционала и расширений), так и владельцами магазинов.
И да, профит в даном случае огромный есть только тогда когда систему заведомо будут поддерживать очень долгое время и большое количество разных людей.
Magento 2: Создание грида в adminhtml