Comments 10
Обожаю мадженту, что бы сделать какую-то простую фигню, обязательно надо извратится и написать кучу кода.
Если немного разобраться, и попрактиковаться, это всё выглядит достаточно очевидно, просто, понятно. Сейчас, например, создать модуль — пол минуты, раньше — пол дня :)
Плюс её в том, что её можно расширять в самых неожиданных местах :) Вот можно разве где-то ещё так просто, и без модификации ядрёных файлов, добавить новую галку в процесс чекаута, весьма «интимный» для интернет-магазина? Это же прелестно! :)
Раньше работал с ZenCart, вот это жесть, хорошо что больше не надо с ней сталкиваться. Там сама архитектура по-моему гораздо хуже чем Маджентовская.
Плюс её в том, что её можно расширять в самых неожиданных местах :) Вот можно разве где-то ещё так просто, и без модификации ядрёных файлов, добавить новую галку в процесс чекаута, весьма «интимный» для интернет-магазина? Это же прелестно! :)
Раньше работал с ZenCart, вот это жесть, хорошо что больше не надо с ней сталкиваться. Там сама архитектура по-моему гораздо хуже чем Маджентовская.
знаете, я был у истоков ядра магенты и вот что могу сказать… УПАСИ ГОСПОДИ
архитектура не проектировалась не документировалась и разрабатывалась большим числом приходящих и уходящих разработчиков.
Так что вот как-то так.
Пы.Сы. Уже давно не видел магенту. В исходном варианте у нее все еще 120 таблиц в БД или уже стуло лучше? :)
архитектура не проектировалась не документировалась и разрабатывалась большим числом приходящих и уходящих разработчиков.
Так что вот как-то так.
Пы.Сы. Уже давно не видел магенту. В исходном варианте у нее все еще 120 таблиц в БД или уже стуло лучше? :)
240-250
но они сделали возможность объединить eav для каталога (типа merge layers в фотошопе), а то слишком много появилось недовольных требованиями к производительности серверов
но они сделали возможность объединить eav для каталога (типа merge layers в фотошопе), а то слишком много появилось недовольных требованиями к производительности серверов
Ну, архитектура не так проста, плюс там используются разные шаблоны проектирования, что весьма увеличивает количество классов и сложность понимания их работы и взаимодействия.
Взамен получаем хорошую расширябельность :)
Взамен получаем хорошую расширябельность :)
там используются шаблоны везде где только можно, но не только там где нужно.
Шаблоны не панацея и использовать их тоже следует с умом.
насчет расширяемости… Ну вот этот топик отлично показал сколько нужно танцев с бубном, что бы добавить один чекбокс. Возможно кто-то это назовет «хорошей расширяемостью» :)
Шаблоны не панацея и использовать их тоже следует с умом.
насчет расширяемости… Ну вот этот топик отлично показал сколько нужно танцев с бубном, что бы добавить один чекбокс. Возможно кто-то это назовет «хорошей расширяемостью» :)
"<script type=«text/javascript»>payment.init();</script> Не разбирался зачем он нужен, но в данном случае....."
категорически не принимаю такой подход при расширении (несомненно качественного, хотя бы с точки зрения применения в нем классического ООП) продукта
что касается маженты, я бы с уверенностью полез внутрь этого payment.init(), чтобы найти болле корректный, с точки зрения маженты, способ енаблить мой чекбокс
глядишь, и не пришлось бы потом тупо лезть в $_POST, в спокойно принял бы значение чекбокса в $data
race1, вас кто-то в спину гнал скорее это всё забодяжить, или вы хотели сделать расширяемый модуль для расширяемой маженты? а если вас завтра попросят в чекауте добавить дропдаун какой-нить? всё по-прежнему будете отрубать реврайты сторонних модулей? :) (кстати, там проблема не реврайтах конфига, а в экстендах для классов — сделайте свой
class Mage_NewsletterSubscribe_Model_Onepage extends Desitex_Checkoutnewsletter_Model_Onepage
а он пусть останется
class Desitex_Checkoutnewsletter_Model_Onepage extends Mage_Checkout_Model_Type_Onepage
(могу ошибаться в именах классов, надеюсь идею уловили)
категорически не принимаю такой подход при расширении (несомненно качественного, хотя бы с точки зрения применения в нем классического ООП) продукта
что касается маженты, я бы с уверенностью полез внутрь этого payment.init(), чтобы найти болле корректный, с точки зрения маженты, способ енаблить мой чекбокс
глядишь, и не пришлось бы потом тупо лезть в $_POST, в спокойно принял бы значение чекбокса в $data
race1, вас кто-то в спину гнал скорее это всё забодяжить, или вы хотели сделать расширяемый модуль для расширяемой маженты? а если вас завтра попросят в чекауте добавить дропдаун какой-нить? всё по-прежнему будете отрубать реврайты сторонних модулей? :) (кстати, там проблема не реврайтах конфига, а в экстендах для классов — сделайте свой
class Mage_NewsletterSubscribe_Model_Onepage extends Desitex_Checkoutnewsletter_Model_Onepage
а он пусть останется
class Desitex_Checkoutnewsletter_Model_Onepage extends Mage_Checkout_Model_Type_Onepage
(могу ошибаться в именах классов, надеюсь идею уловили)
"<script type=«text/javascript»>payment.init();</script> Не разбирался зачем он нужен, но в данном случае....."
категорически не принимаю такой подход при расширении (несомненно качественного, хотя бы с точки зрения применения в нем классического ООП) продукта
Да мне тоже не нравится… Просто я так подумал, это чекаут, а это моя галочка, к чекауту никакого отношения не имеющая. Я немного посмотрел на код, и мне показалось, он делает что-то с чек-боксами в зависимости от возможности выбора способа оплаты, плюс, что мне очень не понравилось, это тупо распространяется вообще на все. Поэтому я решил что активировать галочку своим js будет проще. А, кстати, какая альтернатива? Зарываться совсем вглубь, что бы, возможно, найти способ не дисаблить мою галочку? Мне кажется это вообще невозможно кроме своего js… Хочу ошибаться в этом вопросе :)
что касается маженты, я бы с уверенностью полез внутрь этого payment.init(), чтобы найти болле корректный, с точки зрения маженты, способ енаблить мой чекбокс
глядишь, и не пришлось бы потом тупо лезть в $_POST, в спокойно принял бы значение чекбокса в $data
Там все непросто. Тот метод, который я переопределяю (savePaymnt) получает только одно значение — выбранный способ оплаты. Да, код, который вызывает savePayment, имеет доступ к реквесту и параметрам, но я не увидел возможности переопределить его.
race1, вас кто-то в спину гнал скорее это всё забодяжить, или вы хотели сделать расширяемый модуль для расширяемой маженты? а если вас завтра попросят в чекауте добавить дропдаун какой-нить? всё по-прежнему будете отрубать реврайты сторонних модулей? :)
О, копание в Мадженто это то еще удовольствие. Поэтому если я нахожу решение, явных минусов которого не вижу, предпочитаю не копать дальше — это может затянуться еще на пол дня отладки маджентовских потрохов :) Вот что действительно хотелось бы поправить — отказаться от реврайта, возможного только для одного модуля.
(кстати, там проблема не реврайтах конфига, а в экстендах для классов — сделайте свой
class Mage_NewsletterSubscribe_Model_Onepage extends Desitex_Checkoutnewsletter_Model_Onepage
а он пусть останется
class Desitex_Checkoutnewsletter_Model_Onepage extends Mage_Checkout_Model_Type_Onepage
(могу ошибаться в именах классов, надеюсь идею уловили)
Эм, не уловил… Предлагаете мне в своем модуле наследоваться от класса из другого модуля? :) Вот это уж очень плохое решение…
категорически не принимаю такой подход при расширении (несомненно качественного, хотя бы с точки зрения применения в нем классического ООП) продукта
Да мне тоже не нравится… Просто я так подумал, это чекаут, а это моя галочка, к чекауту никакого отношения не имеющая. Я немного посмотрел на код, и мне показалось, он делает что-то с чек-боксами в зависимости от возможности выбора способа оплаты, плюс, что мне очень не понравилось, это тупо распространяется вообще на все. Поэтому я решил что активировать галочку своим js будет проще. А, кстати, какая альтернатива? Зарываться совсем вглубь, что бы, возможно, найти способ не дисаблить мою галочку? Мне кажется это вообще невозможно кроме своего js… Хочу ошибаться в этом вопросе :)
что касается маженты, я бы с уверенностью полез внутрь этого payment.init(), чтобы найти болле корректный, с точки зрения маженты, способ енаблить мой чекбокс
глядишь, и не пришлось бы потом тупо лезть в $_POST, в спокойно принял бы значение чекбокса в $data
Там все непросто. Тот метод, который я переопределяю (savePaymnt) получает только одно значение — выбранный способ оплаты. Да, код, который вызывает savePayment, имеет доступ к реквесту и параметрам, но я не увидел возможности переопределить его.
race1, вас кто-то в спину гнал скорее это всё забодяжить, или вы хотели сделать расширяемый модуль для расширяемой маженты? а если вас завтра попросят в чекауте добавить дропдаун какой-нить? всё по-прежнему будете отрубать реврайты сторонних модулей? :)
О, копание в Мадженто это то еще удовольствие. Поэтому если я нахожу решение, явных минусов которого не вижу, предпочитаю не копать дальше — это может затянуться еще на пол дня отладки маджентовских потрохов :) Вот что действительно хотелось бы поправить — отказаться от реврайта, возможного только для одного модуля.
(кстати, там проблема не реврайтах конфига, а в экстендах для классов — сделайте свой
class Mage_NewsletterSubscribe_Model_Onepage extends Desitex_Checkoutnewsletter_Model_Onepage
а он пусть останется
class Desitex_Checkoutnewsletter_Model_Onepage extends Mage_Checkout_Model_Type_Onepage
(могу ошибаться в именах классов, надеюсь идею уловили)
Эм, не уловил… Предлагаете мне в своем модуле наследоваться от класса из другого модуля? :) Вот это уж очень плохое решение…
Sign up to leave a comment.
Magento, подписка на новости во время чекаута