Установка проверки граничных значений в формах

[Chernetskiy 469]

Наверное есть смысл для этажей указать rules=Type:int,Min:-2,Max:25 (выше практически не строят), а в подсказке для человека указать -1 (цоколь), -2 (подвал)

а для этажности указать rules=Type:int,Min:1,Max:25 (только положительные значения)

[doma 22]

8 часов назад, Chernetskiy сказал:

Наверное есть смысл для этажей указать rules=Type:int,Min:-2,Max:25 (выше практически не строят), а в подсказке для человека указать -1 (цоколь), -2 (подвал)

а для этажности указать rules=Type:int,Min:1,Max:25 (только положительные значения)

и еще такой вопросик, предположим правила такие поставили 
и сделали этаж и этажность не сейфстринг а селект бокс-ничего не поломается и все ли будет корректно обрабатываться?
так как делая селект бокс мы уже и так не даем пользователю что то внести криво ограничивая право выбора и ничегоневписания, но вот как будет движок корректно обоабатывать + на будущее.
Предположим сейчас сделаем селект бокс а спустя какое то время что то поменяется и так сказать будет наша "стратегическая ошибка", так как  -что делать потом если опять захотим вернуть к сейфстринг?   (например выгружаться придеться куда то, или наоборот грузить, требования поменяются + что то новое)

и как от селект бокса потом безболезненно и не потеряв данные вернуться к сейфстринг?
 

[abushyk 694]

Отличие сейвстринг от селектбокс в том, что в первом мы храним значения, но никак их не трактуем. Т.е. значение -2 в поле floor  случае сейвстринг означает только "минус два" и больше ничего. При селекбоксе все точно так же, но есть подсказка в интерфейсе в виде значения {-2~~подвал}, т.е. не нужна отдельная подсказка, что писать при указании подвала. На всяких выгрузках-загрузках нужно посмотреть, но для селектбоксов обычно в выгрузку идет именно значение, а не ключ, и для -2 выгрузится скорее всего "подвал", а вот остальные значений типа {1~~1} выйдут как нужно.

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

[doma 22]

17 минут назад, abushyk сказал:

Отличие сейвстринг от селектбокс в том, что в первом мы храним значения, но никак их не трактуем. Т.е. значение -2 в поле floor  случае сейвстринг означает только "минус два" и больше ничего. При селекбоксе все точно так же, но есть подсказка в интерфейсе в виде значения {-2~~подвал}, т.е. не нужна отдельная подсказка, что писать при указании подвала. На всяких выгрузках-загрузках нужно посмотреть, но для селектбоксов обычно в выгрузку идет именно значение, а не ключ, и для -2 выгрузится скорее всего "подвал", а вот остальные значений типа {1~~1} выйдут как нужно.

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

ок то есть можно переходить безболезненно-чтобы не давать пользователям хулиганить со сейфстринга на селектбокс
так по вышеописанному храниться ключе а не значение получается используя например такое представление {1~~кровать} {2~~диван}  {3~~стул} спустя время поменять просто представление   {1~~кроватьширокая} {2~~диванбольшой}  {3~~стулжелезный}
либо поменять местами -но информация подавальщиком исказиться   {1~~диван} {2~~кровать}  {3~~стул} 
так как поменяется отображение с кровати на диван  

но вопрос был немного иной -все ли корректно будет обрабатываться если в селект бокс будет вписано правило  rules=Type:int,Min:1,Max:25  или лучше данное правило удалить совсем? 

 

[Chernetskiy 469]

17 часов назад, doma сказал:

но вопрос был немного иной -все ли корректно будет обрабатываться если в селект бокс будет вписано правило  rules=Type:int,Min:1,Max:25  или лучше данное правило удалить совсем? 

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

[Chernetskiy 469]

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

[doma 22]

подскажите есть поле сейф стринг например общая площадь, есть криворукие которые пишут 50,7метров вместо "50,7" если для этого поля поставиь правило
rules=Type:int,Min:1,Max:10000 то это не будет правильным, так как уже буквы вписать не смогут так как будет запрашиваться целое число, но как дать пользователям писать не целое число, а например "35,66"    то есть только не целые числа, но и числа с запятой, при этом исключив возможность писать буквы, в том числе например 5соток
если написать  Type:decimal ,Min:1,Max:1000 то что будет ? решит ли это проблему описанную мной?

кстати, попробовали decimal вроде работает но вот не целое число надо писать через точку то есть 45 точка 33 что означает 45,33кв.м
мало кто будет вникать в особенности иписать площадь через точку так как в 90% все пишут через запятую, то есть пишут 44 запятая 36 что означает 44,36кв.м

как быть?

[Chernetskiy 469]

• в названии поля четко написать "Площадь общая, м²" или "Площадь участка, сот." - тут будет понятно, что размерность задана и ничего писать не надо;
• в подсказке для человека написать, что дробные значения указывать через точку
• сделать обработчик, который будет приводить дробные значения через точку, запятую, да хоть через "/" к единому значению или убирать всё что после знака / округлять, оставляя целое число.

 

[abushyk 694]

type:int пропускает только целые числа

type:decimal пропускает дробные числа с разделителем дробной и целой частей в виде точки

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

Даже если разрешить вводить с запятой, то хранить все равно нужно с точкой. Но "разрешение" запятой тянет за собой сразу два момента:

- так как хранить нужно с точкой, то при сохранении число должно быть приведено в вид с точкой (эот тот обработчик о котором пишет Игорь Иванович)

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

[doma 22]

7 часов назад, abushyk сказал:

type:int пропускает только целые числа

type:decimal пропускает дробные числа с разделителем дробной и целой частей в виде точки

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

Даже если разрешить вводить с запятой, то хранить все равно нужно с точкой. Но "разрешение" запятой тянет за собой сразу два момента:

- так как хранить нужно с точкой, то при сохранении число должно быть приведено в вид с точкой (эот тот обработчик о котором пишет Игорь Иванович)

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

следовательно простого решения в принципе нет, и сегодняшние пользователи пишущие в поле площадь значения типа 55,7-53м-15сот-10соток впринципе сами же и пострадают, так как например поставив в общую площадь значение15сот не понятно вообще как будут обрабатываться, например заданным условием пользователя
показать объявки с площадью от 10 до 20 (поле общая площадь), хоть у нас у нас в подсказке и написано не ставьте площадь если у вас земельные участки, то все равно пользователи ставят то площадь в виде соток 10сот то 5га и как искать площадь тут не понятно, даем им рекомендацию писать эти сведения в описательной части , так и никак не вменят и не читают
поэтому и хотелось как-то оганичить их писанину в общую площадь

[Chernetskiy 469]

14 минуты назад, doma сказал:

следовательно простого решения в принципе нет, и сегодняшние пользователи пишущие в поле площадь значения типа 55,7-53м-15сот-10соток впринципе сами же и пострадают, так как например поставив в общую площадь значение15сот не понятно вообще как будут обрабатываться, например заданным условием пользователя
показать объявки с площадью от 10 до 20 (поле общая площадь), хоть у нас у нас в подсказке и написано не ставьте площадь если у вас земельные участки, то все равно пользователи ставят то площадь в виде соток 10сот то 5га и как искать площадь тут не понятно, даем им рекомендацию писать эти сведения в описательной части , так и никак не вменят и не читают
поэтому и хотелось как-то оганичить их писанину в общую площадь

В таком случае, как я предлагал выше, рядом с полем указать размерность, например м² , но если чайник при этом в поле пишет 5 га, то сделать обработчик, который будет принимать в базу только цифровые значения, отсекая буквы. Понятное дело, что сохранится 5 (м²), но это уже будет к радости того, кто размещал данное объявление... увидит, убедится и исправит.

В случае с парсингом, подобные значения следует изначально приводить к единой размерности и приемлемому виду для размещения в базе и дальнейшего использования. Это обратная сторона разведения плагиата со всевозможных источников на своем сайте. Мое мнение, данные парсинга в первую очередь должны использоваться для оперативной обработки и горячего предложения существующему клиенту а не для того, чтобы раздуть базу 1 агента тысячами объявлений, которые он не обработает в ближайшею пятилетку. В этом плане приветствую крупные порталы недвижимости, которые снижают рейтинг агента при наличии у него в работе более 100 объявлений.

[doma 22]

Только что, Chernetskiy сказал:

Это обратная сторона разведения плагиата со всевозможных источников на своем сайте. 

про то что писать в кв.м подсказка написана, там же написано для земельных участков не пишите ничего, все равно пишут и игнорируют хоть сколько раз не говори, даже если позвонишь и скажешь голосом в беседе, тут вижу такие варианты
1вариант вообще закрыть для видимости поле общая площадь, жилая, кухни чтобы пользователь вообще не видел для заполнения эти поля, ограничив видимость в разделе земельные участки например
2) вариант тоже самое сделать как и в 1варианте но чтобы пользователь мог все же вписать свою любиимую площадь, в админке в дате внести доп.позе типа сейфстринг для того чтобы можно вводить хоть 5га хоть 15-100соток например назвав "площадь участка", но вот поис по его площади не делать, так сказать просто информационное поле,
которое впринципе можно и в описании вписать 5-10буквами

а на счет плагиата скажите как бороться с этим  так как разумного решения так и не нашли. ситуация следующая, например у пользователя есть объявка, забитая на основной ави сайт   (без рекламы), он тупо потом берет объвку и текстовку вставляет на все сайты без единого редактирования, например наш сайт у него 3 на очереди (сначало ави потом местный и потом мы якобы), так вот -плевать он хотел чтобы что-то править так ивставляет 1 текст на 3 сайта, ну и естественно у нас как бы вырастает "плагиат" на сайте :))
предлагаем им хотябы на наше сайте менять пару слов или хотя бы слова местами, но это не выход так как остальные 95 % слов будет явный плагиат

[Chernetskiy 469]

1. У меня на сайте, при публикации объектов показываются только те позиции, которые необходимы конкретному типу недвижимости. Соответственно для аренды квартиры не будет указываться площадь участка.  

2. Площадь участка желательно задействовать, только добавить обработчик, который оставит только цифры. Достаточно будет в настройках строки в data указать граничные значения type:decimal и буквы сами отвалятся, при этом останется возможность указывать значения с точкой.

3. Здесь сложнее. В качестве полумеры можно решить вопрос автогенерацией описания, как делают некоторые порталы. Но при этом описание становится шаблонным, машинным а не живым текстом, что собственно и предпочтительнее поисковикам. Остается только на видном месте в форме при размещении объявления вставить напоминалку, в которой кратко изложить о качестве текста, фото объявления и т.п., что критично для повышения рейтинга объявления. Агенты конечно проигнорируют, но собственники прислушаются, т.к. для них это не избитая рутина и есть интерес привлечь внимание к объявлению.

[doma 22]

Только что, Chernetskiy сказал:

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

нука нука :)) отсюда поподробнее где, в каком файле и как просто вставить напоминалку задествовав ее именно только тогда когда в форме подачи объявления например именно видно только поле "Площадь зем.участка"

[Chernetskiy 469]

Только что, doma сказал:

нука нука :)) отсюда поподробнее где, в каком файле и как просто вставить напоминалку задествовав ее именно только тогда когда в форме подачи объявления например именно видно только поле "Площадь зем.участка"

1. Про напоминалку лучше у Константина справиться, боюсь косяк предложить, поскольку мне не нужно было и не пробовал. Важно определиться, куда именно её вставить. Думаю логично в шапку формы подачи объявления.

2. Про показ необходимых полей к заполнению в зависимости от типа недвижимости - проще... Проходим в data, открываем необходимую строку, например with_children (можно с детьми) и в позиции "Активно для категории" выбираем всё, что связано с арендой жилой недвижимости - Аренда-комнаты-квартиры-дома-дачи (не знаю как у вас)... Сохраняем и наблюдаем ситуацию при подаче объявления, что это поле появится только в случае выбора типа недвижимости Аренда-квартира и т.п., из того, что указали в data.

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

[Chernetskiy 469]

1 минуту назад, Chernetskiy сказал:

1. Про напоминалку лучше у Константина справиться, боюсь косяк предложить, поскольку мне не нужно было и не пробовал. Важно определиться, куда именно её вставить. Думаю логично в шапку формы подачи объявления.

2. Про показ необходимых полей к заполнению в зависимости от типа недвижимости - проще... Проходим в data, открываем необходимую строку, например with_children (можно с детьми) и в позиции "Активно для категории" выбираем всё, что связано с арендой жилой недвижимости (ставим галочки) в позиции - Аренда-комнаты-квартиры-дома-дачи (не знаю как у вас)... Сохраняем и наблюдаем ситуацию при подаче объявления, что это поле появится только в случае выбора типа недвижимости Аренда-квартира и т.п., из того, что указали в data.

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

 

[doma 22]

Только что, Chernetskiy сказал:

1. Про напоминалку лучше у Константина справиться, боюсь косяк предложить, поскольку мне не нужно было и не пробовал. Важно определиться, куда именно её вставить. Думаю логично в шапку формы подачи объявления.

2. Про показ необходимых полей к заполнению в зависимости от типа недвижимости - проще... Проходим в data, открываем необходимую строку, например with_children (можно с детьми) и в позиции "Активно для категории" выбираем всё, что связано с арендой жилой недвижимости - Аренда-комнаты-квартиры-дома-дачи (не знаю как у вас)... Сохраняем и наблюдаем ситуацию при подаче объявления, что это поле появится только в случае выбора типа недвижимости Аренда-квартира и т.п., из того, что указали в data.

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

1 сделать наверное так -подробности естественно не знаю,но механизм такой
идет перебор достпупных и видимых параметров и вслучае его доступности вставляется напоминалка принцип такой
если поле зем.участки доступно и видимо то отобразить напоминалку

2) мы знаем это "азы"   :)))  спасибо

3) подробнее,что за 100 таких параметров вы напридумывали  скиньте в личку сфомированный ексель файл там будут все поля, может чего то полезного и найдем, так как у вас в столице виднее :))

[Chernetskiy 469]

Только что, doma сказал:

1 сделать наверное так -подробности естественно не знаю,но механизм такой
идет перебор достпупных и видимых параметров и вслучае его доступности вставляется напоминалка принцип такой
если поле зем.участки доступно и видимо то отобразить напоминалку

2) мы знаем это "азы"   :)))  спасибо

3) подробнее,что за 100 таких параметров вы напридумывали  скиньте в личку сфомированный ексель файл там будут все поля, может чего то полезного и найдем, так как у вас в столице виднее :))

по п.3 - все параметры из требований к формату XML Яндекс.Недвижимость. Пока не все они выводятся в выгрузку, всё руки не доходят, но начало положено. Меня на пол-пути Яндекс сбил с толку новым форматом, пока осмыслишь и приспособишь...  

[Smoke 3]

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

[Chernetskiy 469]

16 часов назад, Smoke сказал:

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

Если поле будет ограничено вводом диапазона цифр, например этажность от 1 до 25, то ничего кроме цифр пользователь не введет. Это применимо в любом поле где требуется ввод только цифр. Можно задать только минимальное значение или только максимальное или оба.

[Дмитрий Кондин 690]

В 1/4/2017 в 00:57, Smoke сказал:

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

Можно прямо в базе поменять тип поля с varchar на int

ALTER TABLE re_data MODIFY colname INTEGER;

calname это название колонки, меняйте ее на свое.

[abushyk 694]

В 03.01.2017 в 19:57, Smoke сказал:

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

в данный момент можно заказать либо только целое, либо только десятичное. варианта "числоподобная строка" пока нет и я не знаю в данный момент стоит ли ее добавлять. если ваши данные укладываются в вариант "целое число" (т.е. не нужно поддерживать телефоноподобные строки как 05922222222), то можно использовать Type:int или вариант Дмитрия. Но последнее - это "жесткая посадка", так как rules при несовпадении вернет ошибку заполнения и форму назад для правильного ввода, если поле обязательное, а тип поля в БД просто не сохранит подходящее значение, но не вернет ошибку, даже если поле обязательно к заполнению.

[Smoke 3]

9 часов назад, abushyk сказал:

в данный момент можно заказать либо только целое, либо только десятичное. варианта "числоподобная строка" пока нет и я не знаю в данный момент стоит ли ее добавлять. если ваши данные укладываются в вариант "целое число" (т.е. не нужно поддерживать телефоноподобные строки как 05922222222), то можно использовать Type:int или вариант Дмитрия. Но последнее - это "жесткая посадка", так как rules при несовпадении вернет ошибку заполнения и форму назад для правильного ввода, если поле обязательное, а тип поля в БД просто не сохранит подходящее значение, но не вернет ошибку, даже если поле обязательно к заполнению.

Я как раз говорил о целых или десятичных числах. Дело в том, что при указании площади многие указывают её в сотах и приписывают слово сот, например 5 сот. Так вот хотел узнать, можно ли как-то вырезать слово СОТ и оставлять только 5. Подсказка с просьбой указывать только цифры в квадратных метрах не помогает. Пока использую метод Дмитрия, изменил значение типа поля.

[abushyk 694]

Если вас устраивает молчаливый режим, когда оно будет записывать в базу то, что удастся выжать числового из переданного значения, то можно только базой. Если же это поле вам важно и вы хотите что бы юзер получал предупреждение при попытке задать "левое" значение, тогда лучше rules и Type:int.

Последний способ отличается только тем, что по нему проходит проверка значения и, если оно неформат "5 сот.", "5.0", "пять соток" то форма будет возвращена на дозаполнение. А изменение формата поля в БД приведет к тому, что значение будет принято всегда, но вот в БД останется только то, что подходит под формат колонки в базе "5 сот."=>"5", "5.0"=>"5", "пять соток"=>"0", тогда как rules будут заворачивать форму до тех пор, пока пользователь не введет реальное целое число.

И,что главное, rules не изменяют переданные значения, а только обуславливают их формат и соотвествие ему (кроме decimal который с крайней версии будет вместе с проверкой еще и заменять запятую в числе на точку). Т.е. речи об осмысленном вырезании нет ни в одном из этих случаев.

ПС. Я долго боролся с человеками подсказаками при заполнении и в результате проставил rules на выжных для меня полях расстояний и площадей + выставил форматы колонок в БД на соотв. (это из соображений экономии памяти, така как числовой формат более худой, быстроты сортировки, так как сортировка по числам лучше и адекватнее чем по строкам, и потому что у меня много данных идет с парсеров и прогонять их через сложные проверки с созданием объекта формы не всегда выгодно по производительности).

[banzai72 32]

У нас в 

price rules=Type:int,Min:5000

square_all rules=Type:decimal

 

Нужен совет

Возможно ли как то сопоставить

этажи (floor и floor_count)

и

площади (square_all, square_live и square_kitchen)

 

А то Яндекс и ЦИАН иногда бракует объявления по этим причинам:

1) Общая площадь объекта не должна быть меньше суммы площадей кухни и жилой площади.

2) Этаж объекта недвижимости должен быть меньше или равен этажности здания.