MVC в Webasyst Framework

Иногда у меня создается впечатление, конечно ошибочное, что разработчики Webasyst услышали слово MVC, прочли про это в Википедии, потом купили книжку типа «MVC для чайников» и курили ее до того, как прочесть. Ну как вот такое писать:

Иногда формирование содержимого страницы в браузере выполняется только средствами JavaScript. В этом случае с сервера снимается задача генерации HTML-кода с использованием шаблона, а реализация слоя «вид» в терминологии MVC перемещается на клиента. При этом вместо формирования HTML-кода перед сервером встаёт другая задача — передача данных клиенту.

Документация

Если бы они не выкурили книжку, а прочли ее сначала, то узнали бы, что «вид» (View) это то, что отдатется клиенту. И html страница — вид, и структура json — вид, и atom/rss — тоже вид. И у действия (Action) может быть много Views. Вместо этого они честно налепили отдельных Actions под каждый View, даже если данные отдаются одинаковые.

Дополнительные характеристики товара в списках

Понадобилось мне использовать дополнительные характеристики товара в списках, которые можно создавать в админской части WebAsyst ShopScript. Вот есть у товар трех размеров, в списке товаров в категории показывается, что есть размеры S, M и L, а в списке новинок — нет. Обидно. Тем более, что кнопку «купить» я товарам в списке сделал, но надо же еще размер уточнить.

Чтобы, на скорую руку, исправить это недоразумение добавил в файл /published/SC/html/scripts/classes/class.productlist.php пару строк. В указанном файле надо найти метод getProducts() и перед последней строчкой return $products добавить следующий код:

Все, теперь у каждого товара в списке есть массив дополнительных характеристик product_extra, как у товаров при просмотре категории.

Chosen: работа над SELECT’ами

Chosen оказалось очень неплохим решением для различных выпадающих SELECT’ов. Правда, множественный выбор как был неочевидным, так и остался — приходится в подсказках все равно писать что-то типа «можно выбрать несколько вариантов».

С Twitter Bootstrap вполне себе скрещивается. Есть даже Helper для CakePHP, но я его еще попробовать не успел.

Реализация корзины

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

  1. Корзина хранится в БД
  2. Если пользователь известен (залогинен), то id корзины записывается ему в профиль
  3. Если пользователь неизвестен (гость), id корзины сохраняется в долгоживущую cookie

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

Нужно предусмотреть механизм удаления старых корзин.

Почему бы просто не хранить все это добро в сессии? Спросите у маркетолога, какие идеи у него появляются при словах «брошенная корзина». :)

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

Импортировать существующий код в новый репозиторий Git

Ничего сложного.

  1. Создать на Github новый репозиторий и получить ссылку типа git://github.com/youruser/somename.git
  2. Если локального репозитория еще нет, настроить локальный репозиторий. git init
  3. Если локальный репозиторий только что создали на предыдущем шаге, добавить в него код
    • git add .
    • git commit -m 'initial commit comment'
  4. Добавить к локальному репозиторию удаленный с именем origin, как это сделала бы команда clone. git remote add origin [URL из первого шага]
  5. Отправить изменения в удаленный репозиторий в ветку master: git push origin master

Многоколоночное выпадающее меню в Bootstrap

Понравилось мне, как в стандартном шаблоне Opencart сделано двухуровневое меню категорий товаров.

Картинка кликабельна
Картинка кликабельна

Для Shop-Script, в принципе, можно выдернуть необходимые данные но вот мне сейчас очень по душе фреймворк Twitter Bootstrap. Поэтому захотелось заверстать похожее меню под него. Немного погуглил, немного подправил результат. В Opencart можно задавать количество колонок. У меня получилось, что это количество задано в шаблоне и вообще не может быть больше 12-ти, но это не страшно. Во-первых на лету пересчитывать в зависимости от количества колонок все-таки можно, если очень захочется, а во-вторых что-то мне подсказывает, что больше пяти это все равно будет плохо смотреться.

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

Читать далее Многоколоночное выпадающее меню в Bootstrap

Оформление заказа

В который раз покрутил разные магазинные скрипты, рассматривая процесс оформления заказа. Magento, PrestaShop, Webasyst. Все грустно чрезвычайно. При оформлении заказа все еще запрашивается куча ненужной информации и, похоже, никаких подвижек в сторону улучшения нет. Идея состоит в том, что от клиента для оформления заказа нужен минимум информации — страна и регион (если страна делится на регионы). E-mail опционально. Телефон тоже. Все остальное вообще нужно спрашивать только тогда, когда человек определился с методом доставки. Если самовывоз из офиса, то достаточно просто придти и назвать номер заказа. Если один из пунктов самовывоза курьерской службы, то, например телефон. Если почта — то индекс, адрес, ФИО получателя, если курьер — телефон и адрес. В общем идея в том, чтобы человек заполнял как можно меньше полей. Вот, как у Enter.Ru — указал, что ты в Москве, выбрал пункт самовывоза, написал номер мобильного и жди SMS о том, что заказ можно забирать. Какая в этом случае разница, как человека зовут и какой у него e-mail? Читать далее Оформление заказа

Одно поле из двух

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

Сделал вот такой метод для валидации:

Вот так его в правилах валидации указываю.

Получилось красиво, но насыпалась неприятностей:

  1. Cake считает, что оба поля необходимы, в форме он формирует поля со свойством required и div обертки с соответствующим классом
  2. Если принудительно указать при вызове помощника (helper), что ‘required’=>false, то у input’а свойство убирает, но div продолжает оборачивать. Возможно, глюк dev-версии 2.4
  3. Если обоим полям в модели при валидации указать ‘allowEmpty’=>true, то красивый метод не срабатывает, Cake тогда считает что оба пустых поля тоже валидны

Увы, придется, видимо, в beforeValidation или afterValidation переносить проверку.

Немного о web fonts

Нарыл в разных местах, чтоб не пропало записываю.

Совместимость с разными браузерами

Отсюда.

Стало быть, нужен конвертер шрифтов из otf (или ttf) во все остальное. Известная Белка, увы, ест не все шрифты, кое-какие у нее в «черном списке».

PHP 5.4 и session_register

Песец, как обычно, подкрался незаметно. Я легко обновил PHP на сервере до версии 5.4 и… конечно обнаружил, что функции session_register(), session_unregister(), session_is_registered() не работают. Просто потому, что вообще больше их нет. Перелопачивать кучу старого кода и срочно его переписывать у меня не было никакого желания. Поэтому приделал костыль в начало каждого скрипта, который использует эти функции. Костыль взял в комментариях на сайте php.net, костыль оказался вполне полезным и рабочим. Во всяком случае все мои скрипты работают, хотя и валят в лог предупреждения.