Комментарии 4
идея интересная но существенный недостаток что в случае с ocmod сразу можно обновить модификации и проверить синтаксис и что модуль работает, а тут все сугубо на плечах программиста. неправильно ввел ocmod правило — фейл, перенес кусок кода и забыл поменять правило — снова фейл, а на тесте все будет работать нормально.
в идеале нужен какойто механизм который сам автоматически определяет положение кода и создает правила search и add
Согласен, надо быть деликатным с определением search, но хорошего способа автоматизировать и этот процесс лично я пока не вижу (о плохом способе напишу внизу), а если и найдется нетривиальный способ, то не факт, что он отработает лучше человека. Здесь еще важно, кто как вообще привык писать модификации, я делал под себя (в хорошем смысле этого выражения :)).
А мне показалось удобным так: написал и отладил модификацию на чистом opencart, получил ocmod, применил его на другой копии opencart-а и проверил, как все работает. Потом часто делать это не придется, только search проверить. Задание search делал один раз, больше менять его не понадобилось, соответственно, многократная доработка модификации шла «наживую» и только иногда проверялась через генерацию ocmod (например, перед публикацией или если появились новые области кода), да и тогда исправления были легкими. Другими словами, мне отлаживать скрипты проще по принципу сохранил скрипт-обновил страницу без промежуточных звеньев вроде переподгрузки модификаций, а с ocmod заморачиваться уже в конце, и то не сильно.
Кстати, было бы интересно, кто как еще придумал делать ocmod.
А вот плохой способ автоматизации определения search (для тех, кто захочет реализовать/дописать мой скрипт):
— Взять последнюю непустую строку в файле перед нашим кодом, если она есть. Если она уникальна в файле, то сократить до минимума, пока она уникальна. Если неуникальна, то посчитать ее индекс.
— Взять первую непустую строку в файле после нашего кода, если она есть. Если она уникальна в файле, то сократить до минимума, пока она уникальна. Если неуникальна, то посчитать ее индекс.
— Если обе уникальны, выбрать короче, если обе неуникальны, выбрать с меньшим индексом, иначе выбрать уникальную. В зависимости от этого генерить search position=«after» или search position=«before» и при необходимости задавать индекс.
— Если нужен search position=«replace», то особым образом комментировать убираемую строку. Регулярка в этой схеме не используется.
В-общем, например, так — первое, что пришло на ум. Кто захочет, может додумать.
А мне показалось удобным так: написал и отладил модификацию на чистом opencart, получил ocmod, применил его на другой копии opencart-а и проверил, как все работает. Потом часто делать это не придется, только search проверить. Задание search делал один раз, больше менять его не понадобилось, соответственно, многократная доработка модификации шла «наживую» и только иногда проверялась через генерацию ocmod (например, перед публикацией или если появились новые области кода), да и тогда исправления были легкими. Другими словами, мне отлаживать скрипты проще по принципу сохранил скрипт-обновил страницу без промежуточных звеньев вроде переподгрузки модификаций, а с ocmod заморачиваться уже в конце, и то не сильно.
Кстати, было бы интересно, кто как еще придумал делать ocmod.
А вот плохой способ автоматизации определения search (для тех, кто захочет реализовать/дописать мой скрипт):
— Взять последнюю непустую строку в файле перед нашим кодом, если она есть. Если она уникальна в файле, то сократить до минимума, пока она уникальна. Если неуникальна, то посчитать ее индекс.
— Взять первую непустую строку в файле после нашего кода, если она есть. Если она уникальна в файле, то сократить до минимума, пока она уникальна. Если неуникальна, то посчитать ее индекс.
— Если обе уникальны, выбрать короче, если обе неуникальны, выбрать с меньшим индексом, иначе выбрать уникальную. В зависимости от этого генерить search position=«after» или search position=«before» и при необходимости задавать индекс.
— Если нужен search position=«replace», то особым образом комментировать убираемую строку. Регулярка в этой схеме не используется.
В-общем, например, так — первое, что пришло на ум. Кто захочет, может додумать.
Формат ocmod — довольно элегантное решение для определения модификаций исходных файлов, причем независимо от их формата.
Сомнительная элегантность, если честно. Это же просто костыль, который придумали как расширение, при том от безысходности, потому что никаких альтернатив платформа не предлагала. А он потом перекочевал во вторую версию CMS.
Небольшое отступление: поиск происходит в строке целиком, и вставка возможна только перед, после или вместо нее, но никак не внутри (в классической поставке OCMOD для Opencart).
С использованием регулярных выражений вставка/замена возможна хоть где.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Генератор ocmod-файла для интернет-магазина на Opencart