Новости Joomla

👩‍💻 WT CDEK library v.1.3.0 - обновление PHP SDK для Joomla + CDEK.

👩‍💻 WT CDEK library v.1.3.0 - обновление PHP SDK для Joomla + CDEK.

Небольшая нативная PHP Joomla библиотека для работы с API v.2 службы доставки CDEK. Библиотека представляет собой клиент для авторизации в CDEK API по OAuth, работы с некоторыми методами API: получения ряда данных и расчета стоимости доставки. Поддерживается Joomla 4.2.7 и выше.

В пакет входят:
- библиотека Webtolk/Cdekapi
- системный плагин System - WT Cdek для хранения настроек и AJAX-интеграций
- task-плагин Task - Update WT Cdek data для обновления локальных копий справочников CDEK по расписанию
- web asset с официальным JavaScript-виджетом СДЭК

👉 v.1.3.0. Что нового?
- Полный рефакторинг библиотеки. Библиотека переработана в entity-based API с фасадом Cdek и отдельным слоем запросов. Обратная совместимость не нарушена, поэтому версия библиотеки - 1.3.0.
- Добавлена поддержка новых разделов API СДЭК. Добавлена поддержка новых разделов API СДЭК: webhooks, prealert, печатные формы, payment, passport, reverse, intakes и других сущностей.
- Улучшена интеграция с Joomla.
Улучшена интеграция с Joomla: installer script для layouts, новые поля Joomla Form для тарифов и обновлённые js виджета CDEK.
- документация библиотеки. Все методы библиотеки подробно описаны, а так же текст документации собран в отдельной папке в git репозитории и будет опубликован на сайте.

Библиотека эта нужна для разработчиков, создающих свои расширения для интеграции Joomla и курьерской службы CDEK.

Страница расширения
GitHub расширения

@joomlafeed

0 Пользователей и 1 Гость просматривают эту тему.
  • 0 Ответов
  • 1548 Просмотров
*

zaboich

  • Осваиваюсь на форуме
  • 37
  • 11 / 0
Как известно валидация (проверка) данных формы состоит из двух повторяющих друг друга этапов:
1. проверка на клиенте возможностями javascript и/или браузера+HTML5
2. проверка на сервере

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

Посмотрим, что происходит на стороне серевера (рассомтрим стандартный task mycontroller.save:
1. Контроллер mycontroller (extends JControllerForm) в методе mycontroller->save() получает данные из запроса вызывает метод проверки этих данных в модели mymodel(extends JModelAdmin extends JModelForm)
Код
$model = $this->getModel();
$form = $model->getForm($data, false);
$validData = $model->validate($form, $data);

2. метод модели validate() вызывает методы JForm фильтрации и валидации данных
Код
$data = $form->filter($data);
$return = $form->validate($data, $group);

3. Метод JForm->validate() последовательно прогоняет все поля формы через проверку
Код
$valid = $this->validateField($field, $group, $value, $input);
// Check for an error.
if ($valid instanceof Exception){
array_push($this->errors, $valid);
$return = false;
}

и возвращается по цепочке в контроллер либо массив отфильтрованных данных, либо false - что означает, что какое-то поле / несколько полей не прошли проверку.
Информация, об ошибках проверки всех полей возвращается только в виде массива
$errors = $model->getErrors();
В котором хранятся текстовые сообщения вида "Требуется поле: {Label} поля"

4. Пользователь возвращается на страницу формы с Warning Message о незаполненных полях.

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

Вариантов решения проблемы вижу два:
1. Попытаться распарсить сообщения системы и по вхождению label поля их выделить. Делать это надо во View, но обращение к массиву
Цитировать
JFactory::getApplication()->getMessageQueue();
Приводит к его обнулению. Т.е. сразу придется брать на себя и дальнейшую обработку сообщений системы.
2. Перегрузить метод $model->validate() таким образом, что бы он самостоятельно валидировал данные, например, посылал поля на JForm->validateField($field, $group, $value, $input) и таким образом иметь возможность контроля каждого поля.

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

Занимался ли кто-нибудь подобной проблемой, есть ли более удобные пути?
« Последнее редактирование: 29.01.2015, 10:20:44 от zaboich »
Чтобы оставить сообщение,
Вам необходимо Войти или Зарегистрироваться
 

Счётчик полей в админке модуля

Автор zeus07

Ответов: 9
Просмотров: 1300
Последний ответ 28.06.2021, 13:40:31
от zeus07
Вызов формы компонента в pop-up, при клике по ссылке из любого места

Автор SkyAn

Ответов: 1
Просмотров: 974
Последний ответ 01.03.2021, 04:08:48
от gartes
Pagination компонента и данные из формы модуля

Автор platonische

Ответов: 4
Просмотров: 1229
Последний ответ 29.01.2020, 11:32:43
от mardok
[РЕШЕНО] Сохранение значений полей добавленных динамически элементу

Автор platonische

Ответов: 30
Просмотров: 3982
Последний ответ 10.11.2019, 15:42:33
от platonische
Валидация формы

Автор tm2010

Ответов: 2
Просмотров: 1288
Последний ответ 28.12.2017, 12:06:49
от tm2010