sv2109

Я делаю так:В контроллере добавляю 1 строчку: $this->data['l'] = $this->language; В шаблоне вместо: <?php echo $text_checkout_option; ?> пишу <?php echo $l->get('text_checkout_option'); ?>

Проверил, у меня $controller->data['text_checkout'] = 'TEST';Нормально заработало.. правда у меня версия 1.5.3.1, но мало вероятно что из-за этого.Вот скрин http://www.diigo.com/item/image/39n05/5og8?size=o Да, понятно, что это еще не полноценное решение. Нужно все проверить, протестировать. Нужно добавить несколько событий с которыми можно работать. Нужно сделать с десяток полезных примеров, чтобы показать другим как все работает и что это действительно полезно и удобно. Кстати, насчет сборки.. Можно просто пойти по пути vqmod-а.. его же не включали в ядро и сборок отдельных не делали.. просто выложили где-то и показали всем как пользоваться.. Что можно сделать: 1. Допилить все, сделать нормальную документацию с примерами и запаковать все в отдельный модуль. 2. В модуле прописать несколько способов установки: - через ручную правку файлов - через копирование и перезапись уже измененных файлов (в этом случае нужно создавать отдельный файлы для каждой версии опенкарта) - через vqmod 3. Выложить отдельным модулем с описанием. Если решение нормальное, значит его оценят и со временем начнут писать модули под него. Как сейчас - загружаешь модуль и видишь - для использования нужен vqmod. Так же будет там - для использования нужен Event Dispatcher (или может проще ED).

Ага, а еще лучше одну большую кнопку "Сделать хорошо" :)Если вам нужен хороший, качественный, функциональный сайт, который будет отлично решать именно ваши задачи, то вам или нужно быть программистом, который сам допилит этот функционал или нанять такого программиста, заплатив ему за работу. А красивый, удобный интерфейс, с помощью которого, нажав на пару кнопочек в админке можно все сделать хорошо - это миф. Если вы считаете, что это не так но приведите пример хотя бы одной такой системы..

Скажите, пожалуйста, сколько сайтов вы сделали на Друпале, сколько модулей для него написали, с какими апи работали итд? Зачем говорить о том в чем не разбираетесь?Почитайте например вот этот комментарий на хабре о системе баг трекинга на друпал.орг и все станет на свои места. Еще есть статья одного уважаемого друпалера обо всем этом "друпал кризисе".. И вообще прекращаем флуд в теме.

Вы говорите о Event Dispatcher? Так это и есть апи для регистрации событий. В одном файле добавляется событие с помощью одной строчки кода. В другом файле (своем модуле) пишется обработчик этого события. Все делается согласно паттерну Наблюдатель, куда уже феншуйнее :)) Плюс именно этот подход используется и в Друпале и в Симфони, системы, которые пишутся целыми командами профессионалов и раз они пришли с годами именно к такой реализации значит она не может быть неправильной.Событий не будет много. Например один пререндер в контроллере покроет процентов наверное 80% всего, что сейчас делается через vqmod, потому что только с помощью него можно будет переопределить ВСЕ переменные шаблона и добавить свои. Плюс добавить еще штук 5-10 в ключевых точках кода (тут нужно подумать где именно).

Продолжение темы

Я правильно понял - нужно в шаблоне product.tpl получить идентификатор категории к которой относиться товар? Если так то во-первых не идентификатор, и идентификаторы, это должен быть массив потому что у товара может быть несколько категорий. Но я только что посмотрел код контроллера отображения товара (для opencart 1.5.3.1) и там этого массива похоже что нету.. То есть нужно в самом контроллере прописать что-то типа: $this->data['categories'] = $this->model_catalog_product->getCategories($this->request->get['product_id']);Тогда в шаблоне в переменной $categories будет массив с идентификаторами категорий для этого товара.

"Dependent Options is a VQMod script..."

Тут спорный вопрос. Есть Похожие товары (например ноутбук А и ноутбук Б и в данном случае логично их связывать двусторонней связью, потому что если ноутбук А похож на ноутбук Б то и ноутбук Б похож на Ноутбук А), а есть Рекомендуемые товары, например ноутбук А и рекомендуемые для него мышка А, флешка А. Но в данном случае для мышки А ноутбук А не будет рекомендуемым товаром. А то как-то не совсем логично получается - вы заходите в магазин купить мышку а вам магазин впаривает целый ноутбук :))) Я вам открою маленький секрет - в оуперкарет почти для любого более менее функционального модуля нужен vqmod, так как в самом движке нету вообще никаких механизмов изменить поведение из своего модуля без правки кода движка (я тут поднимал тему, пока желающих это развивать не много..) То есть или вы пользуетесь стандартным функционалом (вам его уже не хватает), или используете vqmod или вносите изменения в напрямую в код движка (что еще хуже vqmod-a..).

ID это ID товара в базе сайта или какой-то внутренний ID товара у поставщика? Если первое то пробуем получить id товара из базы простеньким sql запросом. Если такой есть, значит товар присутствует и делаем обновление цены через update, если нету то делаем добавление товара через insert. В чем проблема? Если второе то можно этот внутренний ID добавить в например поле модель или артикул или вообще создать для него отдельное поле в базе и сделать тоже что и в п1. только проверять товар по этому полю.

там аж 2 строчки кода нужно удалить, чтобы убрать обратную связь.. но я не из команды ocStore, ждите ответа именно от них :)

У вас опечатка в коде, исправьте:if ($_SESSION['user_id'] == 1

Не проще..1. для preg_match нужно передать строку в которой будет осуществляться поиск , которую нужно получить из файла, а тут есть 2 варианта: 1. Загрузить весь файл в эту строку, но если файл большой то сделать это не получится 2. Если считывать построчно и проверять каждую строку то это очень долго и не эффективно 2. я не проверял, но подозреваю, что скорость работы консольной команды будет намного больше, чем php функции 3. preg_match вроде имеет ограничение в к-во символов, то есть обработать реально большой файл ей не получиться.

готовые решения есть для стандартных задач, а у вас очень специфическая задача для нее нужно писать индивидуальное решение. Да и в чем проблема? Нужно ТЗ и несколько часов работы вменяемого программиста и будет вам счастье :)

Как я все вижу. Нужно: 1. Точно сформулировать проблему. Потому что начали с хуков а закончили обработчиками форм. 2. Подтянуть русское сообщество в тему. 3. Найти решение этой проблемы. Тут 2 варианта: 3.1. Пересмотреть уже имеющиеся решения, некоторые ссылки есть в этой теме, изучить их код, соответствие стандартам, идеологии движка итд. 3.2. Если ниодин вариант не устраивает, то совместными усилиями найти решение. Возможно это будет система хуков или механизм наследования или наблюдатель 3.2.1 Написать минимальную реализацию, пусть с багами и минимальным функционалом но чтобы можно было запустить и посмотреть как оно работает. 4. Нужны люди, хорошо знающие английский, которые бы могли это решение предложить на оф.форуме, подтянуть сообщество. Написать примерно что вот представители из российского сообщества предлагают слудующий вариант решения следующей проблемы. Я думаю, если решение будет красивое то сообщество его должно поддержать. 5. Если и после поддержки сообщества авторы движка откажутся что-то делать.. тогда можно ставить какие-то ультиматумы.. типа если не добавляете этот или какой-то то другой код, который решает проблему, в ядро то мы создаем свою отдельную ветку. Но создать форк это должно быть самым последним шагом, когда все перепробовано и ничего не помогает. Потому что это только на словах все просто, быстро и идеально.. А реально создать свой движок пусть даже форкнув что-то это огромная работа и ответственность. Мало написать код, нужно его постоянно поддерживать, исправлять баги, отвечать на кучу вопросов пользователей, выпускать новые версии, создавать новые модули, темы, развивать сообщество, не исключены даже какие-то юридические нюансы итд.

У меня сложилось подобное мнение после прочтения темы на оф. форуме OpenCart 1.6.0 Roadmap там народ предлагает разные вещи, которых им не хватает, что бы хотелось видеть в новых версиях. Куча народу предлагало изменить систему модулей и архитектуру.. без толку.. Зато вроде решили добавить vqmod в ядро (фейспалм). То есть для авторов более важным является например добавить поддержку нескольких продавцов для товара (реальный пример с этой темы) или возможность добавлять картинки для товаром с внешних источников (еще один реальный пример) чем что-то поменять в архитектуре. Такое ощущение, что их вообще все устраивает.. а кого не устраивает - добавим вам vqmod в ядро и зачем что-то там выдумывать.. хуки, наследование.. пользуйтесь vqmodом и будет вам щастье!..Ну неужели так сложно понять элементарную вещь - от разработчиков движка требуется 2 вещи: 1. Создать хорошее ядро 2. Создать нормальную систему модулей Все! Все остальное люди сами допишут.. и несколько продавцов и внешние ссылки для рисунков и еще 100500 других модулей..

Могу подсказать один из вариантов решения: 1. В линуксе есть консольная команда grep с помощью которой можно искать в файлах с помощью регулярных выражений. Ищет очень быстро, отдает строки, содержащие совпадение (возможно можно поменять вывод с помощью параметров, нужно курить маны) например. grep "256" utf8_DaneCzesci.csv (файл на пол миллиона строк, размером в 42 мегабайта) время поиска меньше секунды! 2. В php есть функция exec с помощью которой можно выполнять консольные комманды. 3. К стандартному поиску дописать поиск по внешнему файлу.. 4. Профит

А в чем проблема? Токен хранится в сессии. Если админ зашел в админку, а потом на сайт то и сессия будет та же. Токен можно взять из массива сессии $_SESSION['token'] или из реестра, напишите в шаблоне <?php echo $this->session->data['token']; ?> и получите токен. ПС в этом же массиве хранится айди пользователя (админки) - user_id, то есть можно проверить права доступа перед тем как выводить кнопку.

Конкретная задача? Да сколько угодно! Берем любой модуль, у которого какой-то функционал реализован через vqmod (а таких процентов наверное 80), нужно реализовать этот функционал без использования vqmoda и правки кода движка. Например, нужно добавить с помощью своего модуля новый пункт меню.

Кстати, еще один пример, сейчас как раз читаю как круто это все реализовали в Симфони с помощью паттерна Наблюдатель. Статья на Хабре часть1, часть2

Тут вопрос не в том чтобы сделать так, чтоб работало.. Это можно.. создать кучу своих классов, которые унаследуют существующие, поменять кучу кода движка и все заработает. Вопрос сделать это красиво без изменения кода движка. Причем нужна возможность делать это с помощью модулей. Нужен функционал, который даст модулю возможность без изменения стороннего кода и без использования vqmod и прочих костылей менять логику работы сайта. Я уже неоднократно наводил пример - Друпал. Там с помощью хуков можно изменить почти все. Причем Друпал это не какая-то левая система, а цмс мирового масштаба, на которой работает огромное количество сайтов. Я не говорю о том чтобы сделать из опенкарта Друпал. Я говорю о том что в опенкарте ну просто очень слабая и недоделанная система модулей. И что-то с этим нужно делать.

Да.. вроде все на классах, а как переопределить какой-то класс? Например какой-то контроллер или модель? Причем сделать это без правки кода движка? Насчет логики в шаблонах, имхо, избавится от нее полностью не получится, нужно же оставить какие-то циклы для создание меню, списков итд. Делать все в моделях, чтобы модель формировала готовый html код тоже не правильно.

Проблема в том, что render нашего модуля будет работать только с данными контроллера этого модуля, а нам нужно изменить данные прежде всего других классов. Тут нужно или как-то переопределить главный контроллер или добавить пре рендер. Другого пути я не вижу.

Невозможно один хуком поменять и данные и события и вообще все.. В Друпале используется целая система из нескольких десятков хуков, тут же привел пример всего одного, с помощью которого можно поменять все данный в шаблоне, по-моему неплохо как для 20 строк кода.Насчет "те же грабли что и vqmod" в корне не согласен. Так как с помощью vqmod изменяется код ядра движка, что является очень плохой практикой программирования, есть даже рисунок по этому поводу :) А вариант с хуками вносит изменения без правки кода ядра, изменяя лишь данные или поведение. По-моему разница очевидна. Насчет того, что несколько модулей могут менять одни данные. Во-первых это не так критично как изменение кода движка, так как меняются только данные и не затрагивается код. Во-вторых можно как-то присвоить приоритет каждому модулю. Можно даже дать пользователю возможность из админки выставлять эти приоритеты для модулей, как сейчас сделан "Порядок сортировки" для модулей.. итд. вариантов масса. Я не привел окончательную реализацию всего механизма, а лишь показал тестовый пример.

Да, интересное решение. На первый взгляд то что нужно - создаешь свой модификатор, который является наследником какого-то класса и переопределяет любой метод этого класса с последующим вызовов метода родителя. Бегло просмотрел код. Там вводится еще один слой абстракции - фабрика, с помощью которой можно переопределять методы других классов. Правда переопределяется все через какой-то variable stream, пока не разобрался с этим. Шаблоны переопределяются через хелпер modifier или через str_replace, короче тот же vqmod только с другой реализацией.. Плюс еще один слой, который серьезно усложняет логику и может конкретно увеличить скорость загрузки страницы. Короче пока двойственные чувства. С одной стороны классно, то что нужно, с другой слишком сложно и тяжело и местами ничем не отличается от vqmod-a.