sv2109

Коллеги, для удобства совместной работы сделал такую доку http://smartceo.ru/o.../annotated.html. Если полезно - дайте, знать.

Вы бы это вынесли в отдельную тему. Так и эта тема была бы чище и отклик получили бы больший.

По доке. Спорный вопрос. Пользы с нее было бы больше если бы в коде использовались правильные комментарии с использование @param, @return, @var, @todo итд. Подобные док креаторы их вроде подхватывают. А так.. посмотреть, что все контроллеры наследуются от главного контроллера, это и так известно. Та и работать со структурой приходится редко, в основном нужен какой-то конкретный класс, который мне например удобнее открыть в редакторе (у меня NetBeans IDE 7.2), который во вкладке Навигатор покажет список всех методов и свойств этого класса, а по клику можно перейти к конкретному методу и посмотреть его код.

Это мое мнение. Но в любом случае за проделанную работу плюсую.

Другой вариант развития обсуждения и поиска решений - от проблем и слабых мест. Перечисляем слабые места ОС: шаблонизация, управлением модулями, кастомизация ядра и т.п.; потом определяем источники или причины этих проблем в ОС, ну и наконец предложения по их решению, а потом и кодирование новых решений.

Да, все правильно. Я именно с этого и начал. Взял, на мой взгляд. самое слабое место ОС - невозможность что-либо переопределить без правки кода движка. Придумал реализацию системы хуков и событий. И создал для обсуждения именно этой проблемы эту тему. После чего тема превратилась "чего кому не хватает в ОС" :)

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

Еще немного и компоненты (табы, таблицы и т.д. будут генериться почти без шаблонов - получится что-то типа Microsoft Foundation classes). Меньше логики в шаблоны! Вот шаблонизатор mustache не зря такой минималистичный.

А теперь аргументируйте и предложите альтернативу.

vQmod - говно! Я когда увидел в коде опенкарта что его встраивают - заплевал весь монитор ...

... но кому такая сборка нужна? На форуме людей понимающих о чем идёт речь в этой теме - полтора человека... остальных всё устраивает..

Нам нужна! Чтобы при следующем открытии редактора не хотелось плевать в монитор, понимая с чем приходится работать! И чтобы работа не превращалась в скучную рутину для зарабатывания денег, а чтобы получать от этой работы элементарное удовольствие, понимая что работаешь с реально хорошим движком, что у этого движка есть реальные перспективы, что он не просто не хуже аналогов, а даже превосходит их по множеству параметров и при этом постоянно развивается в правильном направлении становясь от этого еще лучше. А направление это не задаст большинство, им пофиг.. как-то работает ну и ладно.. Направление в большинстве проектов как раз и задают тех "полтора человека" и именно благодаря им мы и имеет сейчас Друпал, Линукс, Симфони...

sv2109, у Вас есть виденье того как бороться со статичными страницами шаблонов (и в фронтэнде и в админке)?

У меня 2 варианта:

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

  <div id="tabs" class="htabs">
		<a href="#tab-description"><?php echo $tab_description; ?></a>
	<a href="#tab-attribute"><?php echo $tab_attribute; ?></a>
	<a href="#tab-review"><?php echo $tab_review; ?></a>
	<a href="#tab-related"><?php echo $tab_related; ?> (<?php echo count($products); ?>)</a>
  </div>

То есть все жестко прописано в коде и даже местами поменять например описание с атрибутами без правки шаблона не получится не говоря уже о том чтобы что-то добавить.

Как можно сделать. Создать массив $tabs, в котором каждый таб будет элементом этого массива, и выводить его с помощью foreach. В этом случае мы на сервере сможем и поменять местами табы переставив элементы массива и добавить новый таб добавив новые элемент и он потом выведется на странице, так как все табы печатаются через foreach.

Так же можно и меню выводить и разные списки и например поля для товаров итд. При таком подходе очень много чего можно будет переопределить на сервере с помощью например тех же хуков.

2. Opencart использует паттерн MVC для разделения логики на слои. У каждого слоя своя область применения. Так вот слой Представления в это самый близкий до пользователя слой он специально с создавался чтобы можно было без знания php и баз данных вносить изменения в код. Руками! Открыл нужный шаблон и добавил несколько строк html кода, это сейчас даже школьники делают на уроках информатики. А если человек занимается созданием сайтов то он просто обязан знать самые азы html-а и при необходимости добавить пару строк html кода в шаблон не должно составить для него вообще никакой трудности.

А истина скорее всего где-то посередине. И если найти компромисс между этими двумя вариантами то получится то что нужно. Например максимально добавить динамики в шаблоны чтобы можно было программно их изменять. А то что нельзя так сделать (или не выгодно потому что сильно усложнит логику или скажется на производительности) - просто править руками. Тем кто не умеет - учить html :)

Да я знаю, что есть. Сам достаточно работал с Zend, но осталось прикрутить к OpenCart/

То тогда лучше использовать компоненты Симфони. По нескольким причинам. 1. Не знаю насчет ZF, очень давно его изучал и то была какая-то древняя версия, а в Симфони все компоненты сделаны независимо и их можно подключать к сторонним приложениям. 2. Мне кажется, что почти все подобные компоненты более-менее одинаковы по функционалу, да что-то лучше реализовано в одном, что-то в другом но в основном почти тоже самое. 3. Один компонент от Симфони я уже прикрутил и чтобы не создавать зоопарка то лучше и другие брать именно от Симфони

Еще в симфони есть компонент Лоадер, который позволяет автоматизировать процесс подключения классов с использованием неймспейсов. Для одного компонента я не стал его подключать, но если будут другие то есть смысл его настроить и все подключать через него.

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

Зачем изобретать свои велосипеды, если это до вас уже неоднократно сделали?! Есть десятки уже готовых решений, написанных профессиональными разработчиками и отлаженными на тысячах сайтов.. Причем все опенсорсное, бери и пользуйся :) Вот например по формам - компонент Validator от Symfony или форм хелпер от фреймворка CodeIgniter, форм валидатор от CodeIgniter (ссылки на русскую документацию немного устаревшей версии фреймворка) итд. наверное в каждом фреймворке есть свой готовый класс для подобной рутины.

  $this->data['text_checkout_option'] = $this->language->get('text_checkout_option');
  $this->data['text_checkout_account'] = $this->language->get('text_checkout_account');
  $this->data['text_checkout_payment_address'] = $this->language->get('text_checkout_payment_address');
  $this->data['text_checkout_shipping_address'] = $this->language->get('text_checkout_shipping_address');
  $this->data['text_checkout_shipping_method'] = $this->language->get('text_checkout_shipping_method');
  $this->data['text_checkout_payment_method'] = $this->language->get('text_checkout_payment_method');
  $this->data['text_checkout_confirm'] = $this->language->get('text_checkout_confirm');

Я делаю так:

В контроллере добавляю 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).

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

Ага, а еще лучше одну большую кнопку "Сделать хорошо" :)

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

блин все таки я нашел эту тему http://habrahabr.ru/post/128208/

Мне кажется у opencart меньше? :-)

Скажите, пожалуйста, сколько сайтов вы сделали на Друпале, сколько модулей для него написали, с какими апи работали итд? Зачем говорить о том в чем не разбираетесь?

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

Еще есть статья одного уважаемого друпалера обо всем этом "друпал кризисе"..

И вообще прекращаем флуд в теме.

sv2109, посмотрел твой вариант (извиняюсь, что бегло). Это получается, что надо регистрировать много событий в том же system/engine/controller.php? Правильно? Не фен-шуйно... Вот если сделать API для регистрации событий, то это будет другое дело.

Вы говорите о 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 будет массив с идентификаторами категорий для этого товара.

Странно а они как модуль сделали http://www.opencart....earch=dependent

"Dependent Options is a VQMod script..."

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

Те что с vqmod не интересуют.

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

ID это ID товара в базе сайта или какой-то внутренний ID товара у поставщика?

Если первое то пробуем получить id товара из базы простеньким sql запросом. Если такой есть, значит товар присутствует и делаем обновление цены через update, если нету то делаем добавление товара через insert. В чем проблема?

Если второе то можно этот внутренний ID добавить в например поле модель или артикул или вообще создать для него отдельное поле в базе и сделать тоже что и в п1. только проверять товар по этому полю.

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

итого:

в хеадере, для быстрого доступа к админу:

<?php if ($_SESSION['user_id']=1 && isset($_SESSION['token'])){
echo '<a href="/admin/index.php?route=common/home&token='.$_SESSION['token'].'" target="_blank">ADM</a>';
} ?>

У вас опечатка в коде, исправьте:

if ($_SESSION['user_id'] == 1

тогда уже проще preg_match.

Не проще..

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, то есть можно проверить права доступа перед тем как выводить кнопку.