Если у вас возникли какие либо вопросы которые вы не смогли решить по нашим публикациям самостоятельно,
то ждем ваше обращение в нашей службе тех поддержки.
Поэтому, я поделюсь кое-какими соображениями о самой сложной части кастомизации - о блоке свойств. И да, речь пойдет исключительно об одношаговом компоненте как самом ходовом и современном.
Много я шишек набил на этих формах, много шагов было сделано неправильных. Вот какие правила я вынес:
1. Нельзя писать свою форму (свою логику). Ой поплачете. За прошлые годы я свидетель как эта форма меняется раз в квартал стабильно. Меняются алгоритмы, добавляются события, на которые вешаются сторонние решения Маркета. В общем, не лезьте туда. Выносить и менять логику - ну если прямо , то можно.
2, Если форма сложная, то по части свойств предусмотреть универсальность практически нельзя. Да, вы конечно будете несомненно крутым интегратором, если сделаете сабж выше универсальным, который бы подстраивался под новые свойства. Но мой вам совет - тоже не стоит. Даже если в такой форме добавится "телефон соседей", то ее придется дорисовать сначала, потом утвердить, а потом снова "доинтегрировать". Я рекомендую такие формы заранее обговаривать с клиентом и объяснять ему, что так мол и так.
3. Есть еще вариант говнокдинга (тоже пройденный, несомненно), когда мы ставим кучу if'ов, чтобы знать в каком месте html вывести то или иное свойство. Были чужие варианты и пострашнее, когда в форму, какая она есть от верстальщика, вставляешь name="ORDER_PROP_123", где 123 завтра может смениться и всему конец. Динамика должна остаться хотя бы в именовании полей.
4. Контролируйте и учите верстальщика. Об этом в самом конце.
Посему, от п.2 мы и оттолкнемся (и не забудем про п.3). Итак, смотрим на верстку, и видим, какие свойства нам надо создать. То есть то, что является именно свойствами
Создаем их, с чувством, с толком, с расстановкой. Вот так они выглядят в шаблоне visual без кастомизации (кстати, этот шаблон вышел недавно, и рекомендую использовать впредь всегда его). placeholder'ы, которые вы видите на первом скрине, я поместил в поле "описание" свойств.
Копируем шаблон на редактирование и идем во внутренний файл шаблона props.php. Там находим блок вывода свойств. Это происходит в два шага - первый это те свойства, которые не входят в профиль, и заполняются каждый раз снова и снова. Второй - свойства, которые могут быть сохранены в профиле. Так как такая форма не предполагает первый вариант, мы его убираем. Ну и все свойства вам конечно надо создавать с галочкой "сохранять в профиле".
Далее перемещаемся в самый верх функции PrintPropsForm, которая расположена здесь же, и пишем там буферизацию куска html, отвечающего за блок свойств.
Кусок html представляет из себя обычный html, где вместо полей формы мы пишем маркеры с кодами свойств (#КОД_СВОЙСТВА#).
Весь этот блок у нас в переменной $props, который надо вывести в аккурат после foreach, который идет далее.
Промежуточный результат у нас какой-то такой
Теперь, в самом начале блока foreach нам надо вставить переопределение нужных полей. Мне нужны были только TEXT и одна TEXTAREA. Руководствуясь пунктом 2 на остальные свойства забиваем. Потом ставим continue и что дальше происходит - нас не волнует.
То есть, еще раз - мы берем и заменяем маркеры в буферизированном блоке на живые поля ввода, такие, какие они были бы в нормальном выводе. Получаем результат полностью рабочий.
Какое правило мы еще отсюда вынесли? То самое - правило 4. То, что верстальщик должен быть в теме, а лучше работать бок-о-бок с интегратором. Верстальщик сей верстки был профессиональным, поэтому не стал каждому инпуту давать свой индивидуальный класс, даже поле индекса не имеет ни отдельного класса, ни size="4". Респект! Что позволило нам максимально быстро и чисто интегрировать верстку в форму.
К посту я прикрепляю файл props.php, где вы можете посмотреть пример кода из урока. Он конечно еще не закончен (для данной верстки), я намеренно оставил его таким для примера.
Назад в раздел
то ждем ваше обращение в нашей службе тех поддержки.
Кастомизируем сложную форму оформления заказа
Наверное, никто не будет спорить, что форма оформления заказа это самый сложный элемент для кастомизации, так как если внешний облик формы не устраивает клиента, то попотеть придется. Как-то так:Поэтому, я поделюсь кое-какими соображениями о самой сложной части кастомизации - о блоке свойств. И да, речь пойдет исключительно об одношаговом компоненте как самом ходовом и современном.
Много я шишек набил на этих формах, много шагов было сделано неправильных. Вот какие правила я вынес:
1. Нельзя писать свою форму (свою логику). Ой поплачете. За прошлые годы я свидетель как эта форма меняется раз в квартал стабильно. Меняются алгоритмы, добавляются события, на которые вешаются сторонние решения Маркета. В общем, не лезьте туда. Выносить и менять логику - ну если прямо , то можно.
2, Если форма сложная, то по части свойств предусмотреть универсальность практически нельзя. Да, вы конечно будете несомненно крутым интегратором, если сделаете сабж выше универсальным, который бы подстраивался под новые свойства. Но мой вам совет - тоже не стоит. Даже если в такой форме добавится "телефон соседей", то ее придется дорисовать сначала, потом утвердить, а потом снова "доинтегрировать". Я рекомендую такие формы заранее обговаривать с клиентом и объяснять ему, что так мол и так.
3. Есть еще вариант говнокдинга (тоже пройденный, несомненно), когда мы ставим кучу if'ов, чтобы знать в каком месте html вывести то или иное свойство. Были чужие варианты и пострашнее, когда в форму, какая она есть от верстальщика, вставляешь name="ORDER_PROP_123", где 123 завтра может смениться и всему конец. Динамика должна остаться хотя бы в именовании полей.
4. Контролируйте и учите верстальщика. Об этом в самом конце.
Посему, от п.2 мы и оттолкнемся (и не забудем про п.3). Итак, смотрим на верстку, и видим, какие свойства нам надо создать. То есть то, что является именно свойствами
Создаем их, с чувством, с толком, с расстановкой. Вот так они выглядят в шаблоне visual без кастомизации (кстати, этот шаблон вышел недавно, и рекомендую использовать впредь всегда его). placeholder'ы, которые вы видите на первом скрине, я поместил в поле "описание" свойств.
Копируем шаблон на редактирование и идем во внутренний файл шаблона props.php. Там находим блок вывода свойств. Это происходит в два шага - первый это те свойства, которые не входят в профиль, и заполняются каждый раз снова и снова. Второй - свойства, которые могут быть сохранены в профиле. Так как такая форма не предполагает первый вариант, мы его убираем. Ну и все свойства вам конечно надо создавать с галочкой "сохранять в профиле".
Далее перемещаемся в самый верх функции PrintPropsForm, которая расположена здесь же, и пишем там буферизацию куска html, отвечающего за блок свойств.
Кусок html представляет из себя обычный html, где вместо полей формы мы пишем маркеры с кодами свойств (#КОД_СВОЙСТВА#).
Весь этот блок у нас в переменной $props, который надо вывести в аккурат после foreach, который идет далее.
Промежуточный результат у нас какой-то такой
Теперь, в самом начале блока foreach нам надо вставить переопределение нужных полей. Мне нужны были только TEXT и одна TEXTAREA. Руководствуясь пунктом 2 на остальные свойства забиваем. Потом ставим continue и что дальше происходит - нас не волнует.
То есть, еще раз - мы берем и заменяем маркеры в буферизированном блоке на живые поля ввода, такие, какие они были бы в нормальном выводе. Получаем результат полностью рабочий.
Какое правило мы еще отсюда вынесли? То самое - правило 4. То, что верстальщик должен быть в теме, а лучше работать бок-о-бок с интегратором. Верстальщик сей верстки был профессиональным, поэтому не стал каждому инпуту давать свой индивидуальный класс, даже поле индекса не имеет ни отдельного класса, ни size="4". Респект! Что позволило нам максимально быстро и чисто интегрировать верстку в форму.
К посту я прикрепляю файл props.php, где вы можете посмотреть пример кода из урока. Он конечно еще не закончен (для данной верстки), я намеренно оставил его таким для примера.
Назад в раздел
Подписаться на новые материалы раздела:
