Всем привет!
Я пишу веб—приложение с ипользованием Yesod'а для серверной части, вместо ЯваСкрипта для клиентской части, я пишу код на Хаскеле и перевожу его в ЯваСкрипт с помощью GHCJS.
В приложении есть несколько форм, например, таких как форма входа и форма регистриации. Моя конечная цель — написать некую функцию, которая на входе получает форму, а на выходе выдаёт некий проверщик данных. Задумка в том, чтобы упомянутая функция сначала осуществляла поиск всех (стандартных) полей ввода в форме, и на основе атрибутов и типа поля назначала каждому полю своего проверщика (к примеру, Проверщик Пароля, Проверщик ЭлПочты и т.д.), итог проверки всей формы должен быть суммированием итогов проверки каждого её поля ввода. Эту функцию я ещё не написал.
По задумке, ПроверщикДанных — это некий новый тип:
новыйтип ПроверщикДанных д =
ПроверщикДанных { получитьПроверщик :: Проверщик д }По своей природе, он реактивный, то есть входные данные — это не одиночная величина, а некоторая последовательность. Есть некая функция, которая получает на входе ПроверщикДанных и возвращает текущий итог проверки:
выполнитьПроверку :: ПроверщикДанных д -> ИтогПроверки'Итог проврки может быть одним из трёх: данные не проверялись (нет входящего значения), данные неверные (данные не прошли проверку) и данные верные (данные прошли проверку). Сразу отмечу несколько вещей: в случае неверных данных я хочу предоставлять некое описание причины, по которой данные не прошли проверку; в случае успешной проверки данных, я думаю, нужно передавать проверенное значение. По поводу последнего утверждения я ещё до конца не уверен, но интуиция подсказывает, что так должно быть, к примеру, если во время проверки данные подвергаются изменениям, — предположим, проверяется строковая величина с такими условиями проверки: строка не может состоять только из пробельных символов; строка должна начинаться и заканчиваться непробельным символом. В таком случае, функция проверки производит обрезку строки, и очень логично, вернуть в итоге преобразованную, т.е. обрезанную строку. Описать такой тип дынных можно так:
тип ИтогПроверки д причина = НеПроверенно
| НеверныеДанные причина
| ВерныеДанные дПолучается два параметра: тип данных д и тип сообщения причина. Можно избавиться от последнего параметра, но тогда нет никакой возможности описать собственную функцию проверки с собственными сообщениями, т.е. пользователь будет ограничен неким стандартным набором сообщений, что неприемлимо. Эти парметры так же создают другие проблемы, первая из них в том, что ПроверщикДанных теперь тоже должен иметь параметр для указания типа, представляющего причину отрицательной проверки:
новыйтип ПроверщикДанных д причина =
ПроверщикДанных { получитьПроверщик :: Проверщик д причина }Что же с суммированием итогов проверки? Всё очень просто, когда мы суммируем итоги проверки с одинаковыми параметрами, но в оригинальной задумке параметры почти всегда разные:
пусть п1 :: ПроверщикДанных Почта ПричинаПочта
п2 :: ПроверщикДанных Пароль ПричинаПароль
пф :: ПроверщикДанных Форма ПричинаФормаКак же суммировать итоги проверки п1 и п2 так, чтобы получить пф? По задумке, при запросе итога проверки формы в ответ ожидаются следующие варианты:
НеПровереноНеверныеДанные [приина1, причина2,.. ] — форма может не пройти проверку из—за ошибок сразу нескольких полейВерныеДанные (данные1, данные2,.. ) — в случае, когда все данные достоверные, было бы замечательно возвращать величины каждого поля ввода (например, чтобы сформировать из них некий конечный результат определённого типа)Сразу видны основные проблемы: причины могут быть разного типа, поэтому я не могу просто взять и объединить их в список; различие типов не проблема в случае кортежей, но я не знаю, как создавать кортежи из неопрделенного количества элементов.
Подскажите, куда двигаться? Как обойти описанные проблемы?
Текущий вариант библиотеки здесь. Сейчас ИтогПроверки не возвращает никакие данные в случае успешной проверки, а в качестве причины отрицальтельной проверки используется только один тип — ValidationMessage.
P.S. Прошу прощения за длинный текст, непонятный заголовок и скомканные вопросы.
--
Вы получили это сообщение, поскольку подписаны на группу "Русский Haskell".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес haskell-russi...@googlegroups.com.
Чтобы отправлять сообщения в эту группу, отправьте письмо на электронный адрес haskell...@googlegroups.com.
Чтобы посмотреть обсуждение на веб-странице, перейдите по ссылке https://groups.google.com/d/msgid/haskell-russian/cd7894b0-0b0a-4288-aa07-b64119caa72c%40googlegroups.com.
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.
А Вы на Хаскеле прямо по-русски пишете? ИтогПроверки, тип, новыйтип - прямо так?
пятница, 16 января 2015 г. в 16:30, Артур Файзрахманов написал:
--
А почему у вас описание причин ошибки разного типа? Вы разве выводите их пользователю не в виде строки? В этом случае у вас описание нескольких причин ошибки - это список строк, каждая из которых содержит одно описание причины ошибки.
А почему у вас описание причин ошибки разного типа? Вы разве выводите их пользователю не в виде строки? В этом случае у вас описание нескольких причин ошибки - это список строк, каждая из которых содержит одно описание причины ошибки.Всё просто, когда ошибки представлены просто строкой или текстом, а само приложение рассчитано только на один язык. Я же хочу представлять сообщение об ошибке неким типом, а перевод сообщения, скажем, в Текст выполнять с помощью специальных функций, т.е. заранее предоставить возможность переводить сообщения на разные языки (https://github.com/geraldus/DataValidation/blob/master/src/Data/Validator/I18n/Message.hs). Я позаимствовал эту идею в Yesod — https://github.com/yesodweb/yesod/blob/master/yesod-auth/Yesod/Auth/Message.hs#L25.