Pull to refresh

Comments 9

Статья понравилась. Но я заметил что все, включая М2 разработчиков, добавляют в зависимости своего класса редирект или резалт фектори вроде
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 лишней зависимости.

Спасибо, коллега. Внес изменения в код примера.

UFO just landed and posted this here
UFO just landed and posted this here
Да. Смахивает на то :)
Но все же как не крути получается быстрее — не на много но быстрее. Ко второй магенте стоит относится как к навороченому фреймворку на базе которого собран конечный продукт из кучи модулей.
Так же можно было б сказать и про первую (или любую другую похожую модульную систему) — но все же в м2 это поярче выражено.

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

М2 для девелопера с чуством перфикционизма и желанием сделать все как по книжке будет очень уютным местечком. Но проблема в том что eCommerce в большенстве случаев не нужно качество, ей нужна быстрота внедрения всего нового что может принести выгоду. К сожалению это не про вторую магенту — как не крути но времени нужно потратить больше на разработку, по сравнению с первой магентой, почти во всем.

Хотя, она все же чертовски интересная:)

К сожалению перфекционистам в M2 опасно — она еще очень сырая, неоднородная по реализации система с незавершенными архитектурными решениями (те же репозитории, все еще полностью не заменившие ресурс-модели). Любой владелец магазина на М2 — доброневольный бета-тестер. Работа над выправлением этой ситуации идет, но сможет ли команда разработчиков ее выправить — вопрос открытый. Я бы поставил на них, если бы они отказались от обратной совместимости (которой и так нет) и провели генеральную чистку и реструктуризацию кода и данных, но это стало бы уже М3. Таких маневров community может и не выдержать, а без своих расширений Magento превратится в тот же Shopify, только еще и на своем "железе". Ну а пока разработчики борются со сложностью и, судя по тому, что тесты на Travis'е у них не проходят уже около месяца, борьба идет ожесточенная.


Хотя, она все же чертовски интересная:)

А вот тут полностью согласен :) Весьма любопытный пример распределенной разработки приложений.

Богатая функциональность, получаемая "из-коробки" — это раз. Большое кол-во расширений основного функционала, созданных сторонними разработчиками — это два. Все еще значительное community (best practice & support, как отметил коллега Sergiy) — это три. И плюс куча времени и средств закопанного в нее как разработчиками (основного функционала и расширений), так и владельцами магазинов.


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

© vpodorozh

Для чего нужно заводить ACL на грид, когда там вся admin-area по-умолчанию защищена?

Для разграничения доступа к информации внутри этой самой защищённой области. Т.е., можно определённой группе пользователей админки дать доступ к конкретному гриду, а остальным нет (см. System / Permissions / User Roles в админке).

Sign up to leave a comment.

Articles