Первые впечатления, а также вопрос OpenCart vs ocStore

[aVadim]

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

Я как-то не очень понял, как соотносятся ocStore и OpenCart, то ли ocStore - это форк от OpenCart, то ли всего лишь локализованная сборка, дополненная некоторыми модулями. Кто-то может просветить на этот счет? Буду признателен, если кто-то расскажет историю проекта или ткнет ссылкой, где почитать можно. Хотелось бы это понять, чтобы знать - имеет ли смысл писать сюда свои соображения относительно оптимизации кода или нет. Если тут занимаются всего лишь сборкой, не трогая ядра - то смысла нет. Если готовы пилить ядро движка - могу давать советы, кое-какие рекомендации и делиться некоторыми фиксами, которые я вношу в движок.

[Sammy95]

ocStore - что-то типа форка на начальном этапе, изменения из основного проекта постоянно вливаются в ocStore.

Если готовы пилить ядро движка - могу давать советы, кое-какие рекомендации и делиться некоторыми фиксами, которые я вношу в движок.

Лучше сразу патчи в "Что добавить?" на каждой странице форума вверху.

[aVadim]

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

Переместил код в новую тему в раздел "Дополнения", т.к. показалось, что это более подходящее место:

https://opencartforum.com/topic/2707-%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D1%87%D0%B8%D0%BA%D0%B0%D0%BC-%D0%BD%D0%B0-%D0%B7%D0%B0%D0%BC%D0%B5%D1%82%D0%BA%D1%83-%D1%83%D0%BB%D1%83%D1%87%D1%88%D0%B5%D0%BD%D0%BD%D0%B0%D1%8F-%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%B0-%D1%81-%D1%82/

Змінено 22 квітня 2011 користувачем aVadim

[UncleAndy]

aVadim, добро пожаловать! :)

У меня такая-же ситуация. Выбрал этот движок как основной для установки магазинов клиентам. И начал допиливать. Основное что я хотел я сделал - адаптировал SQL запросы для использования Postgresql и сделал драйвер БД для этого и добавил возможности кэширования (в ближайшее время добавлю кэширование в драйвер Postgresql). Кроме того, исправил несколько небольших проблем в функционале.

В принципе, правка SQL - это тоже большое изменение. Но, то что ты предлагаешь (по поводу строк) очень плохо из-за того что надо править шаблоны. И выложенные в куче мест шаблоны для OpenCart "из коробки" не будут работать. Меня тоже много что коробит в коде. Но я давно понял, что то что удобно программисту может быть плохо либо пользователю либо серверу (падает скорость, жрется память и т.д.). В твоем случае я пока вижу что для каждого процесса будет грузится вся языковая база. Это плохо с точки зрения памяти. Я считаю что такое изменение излишним, т.к. оно дает только удобство программисту и непонятно как влияет на расход памяти.

Но, думаю, нам всем, в любом случае, интересно какие еще доработки вы используете.

[Sammy95]

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

А патчи, это тоже просьбы, только хорошо оформленные :)

Трекер, он и в африке трекер.

Минусы:

1) Шаблоны, где используется $t->... нельзя использовать в стандартном движке (но мне лично это пофиг)

Нет, подобные изменения мы не можем принимать. Совместимость модулей и шаблонов с оригинальным движком опенкарт, это основная фишка ocStore.

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

[Yesvik]

Но, то что ты предлагаешь (по поводу строк) очень плохо из-за того что надо править шаблоны. И выложенные в куче мест шаблоны для OpenCart "из коробки" не будут работать.

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

[aVadim]

Основное что я хотел я сделал - адаптировал SQL запросы для использования Postgresql и сделал драйвер БД для этого и добавил возможности кэширования (в ближайшее время добавлю кэширование в драйвер Postgresql)

Да, работа с базой - это отдельная тема разговора. Сейчас тут используется простейший класс. Конечно, если делать по уму - надо бы взять какую-то более-менее развитую библиотеку. Но тут опять возникает проблема совместимости.

Но, то что ты предлагаешь (по поводу строк) очень плохо из-за того что надо править шаблоны.

А вот и нет! При таком подходе никто не мешает использовать оба метода - старый и мой. У меня, кстати, сейчас так и работает - мне банально влом сидеть и убирать лишние строки из всех контроллеров и переделывать все шаблоны. Старые контроллеры и шаблоны работают, как есть - текстовые переменные загоняются в $this->data[], а в шаблоне юзаются по их имени. А вот новые шаблоны я уже пишу с использованием своего метода. Ведь тут фишка-то в том, что выдергивание текстов из Language происходит не заранее (на уровне контроллера, как сейчас в Opencart), а на лету - по мере обращения к ним из шаблона.

Поэтому уже имеющиеся шаблоны для OpenCart (если нужные переменные добавляются в контроллере) будут работать "на ура!". Но вот шаблоны, сделанные с использованием моей методы, конечно, в стандартном OpenCart работать уже не будут.

И выложенные в куче мест шаблоны для OpenCart "из коробки" не будут работать. Меня тоже много что коробит в коде. Но я давно понял, что то что удобно программисту может быть плохо либо пользователю либо серверу (падает скорость, жрется память и т.д.). В твоем случае я пока вижу что для каждого процесса будет грузится вся языковая база. Это плохо с точки зрения памяти. Я считаю что такое изменение излишним, т.к. оно дает только удобство программисту и непонятно как влияет на расход памяти.

Вопрос, конечно, спорный, как чисто теоретически, так и в данном конкретном случае. :) Но холивары затевать не хотелось бы, скажу лишь, что я лично скорость разработки ставлю значительно выше экономии "на спичках". Более того, чем выше скорость разработки, тем больше (если разработчик грамотный) профита для пользователя, т.к. за тот же промежуток времени больше "плюшек" для юзера можно напечь. Но это теория.

Что же касается данного случая, то при моем подходе мы даже получаем некоторую экономию памяти:

1) Вся языковая база не грузится, используется только то, что подгружено явно вызовом $this->language->load() в контроллере

2) При моем подходе в пространство имен не загружается дополнительно большое число новых переменных (при старом подходе каждый элемент текста - это создание отдельной переменной)

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

Но, думаю, нам всем, в любом случае, интересно какие еще доработки вы используете.

Ок, буду периодически делиться ими

Нет, подобные изменения мы не можем принимать. Совместимость модулей и шаблонов с оригинальным движком опенкарт, это основная фишка ocStore

В таком случае, это не форк, а всего лишь локализованная сборка. Жаль :( Но я бы советовал серьезно подумать на тему создания реально своей ветки. Ведь может быть и такое условие - совместимость в одну сторону. Т.е. все, что делается для OpenCart должно работать в ocStore. А вот обратно - не обязательно. По одной простой причине - потому что ocStore лучше ;)

[Sammy95]

Но я бы советовал серьезно подумать на тему создания реально своей ветки. Ведь может быть и такое условие - совместимость в одну сторону. Т.е. все, что делается для OpenCart должно работать в ocStore. А вот обратно - не обязательно.

Для полноценного форка у нас сейчас слишком мало разработчиков.

А моё личное мнение - лучше не пилить одно и то же порознь, а возвращать свои наработки в родительский проект. Правда, я не знаю как сейчас с этим обстоят дела.

[aVadim]

А моё личное мнение - лучше не пилить одно и то же порознь, а возвращать свои наработки в родительский проект. Правда, я не знаю как сейчас с этим обстоят дела.

Ну, дык, если мои наработки в основную ветку пойдут - я ж разве против! Буду только рад. Я почему и спрашивал в начальном топике про взаимотоношения, т.к. не знаю просто ни ваших планов, ни задач, ни то, взаимодействуете ли вы с разработчиками OpenCart и т.д.

[Sammy95]

т.к. не знаю просто ни ваших планов, ни задач, ни то, взаимодействуете ли вы с разработчиками OpenCart и т.д.

А это, по-моему, только babushka знает, но он постоянно в разъездах.

[tim21701]

;)