кто чем сейчас dry-validation оборачивает? (чтобы делать форм-объекты, а не константы, нормально использовать интернационализацию, в идеале наследоваться уметь)

Скажите погромисты, просто запрос Model.where(name: ["Иван", "Андрей"], age: [25, 44]). Как сделать так, что искал в последовательно порядке? То есть, Иван 25 сперва, а потом Андрей 44?

кто чем сейчас dry-validation оборачивает? (чтобы делать форм-объекты, а не константы, нормально использовать интернационализацию, в идеале наследоваться уметь)

Наследовать схемы?

Скажите погромисты, просто запрос Model.where(name: ["Иван", "Андрей"], age: [25, 44]). Как сделать так, что искал в последовательно порядке? То есть, Иван 25 сперва, а потом Андрей 44?

А если Андрей 25?

Наследовать схемы?

правила валидации (типа как в Reform)

Какой кейс на такое?

Схемы вообще вещь такая, что их переиспользовать не стоит, так что звучит необычно

это когда правила валидации стало необычным наследовать? )

Какой кейс на такое?

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

это когда правила валидации стало необычным наследовать? )

Разные типы же

Нюанс в том, что тут не наследование нужно, а композицию. Бонус: в dry-v для некоторых типов схем наследование работает плохо. Вроде бы в JSON схемах, не помню уже

Нюанс в том, что тут не наследование нужно, а композицию. Бонус: в dry-v для некоторых типов схем наследование работает плохо. Вроде бы в JSON схемах, не помню уже

какой нюанс отвечает за выбор между наследованием и композицией?

Нюанс в том, что тут не наследование нужно, а композицию. Бонус: в dry-v для некоторых типов схем наследование работает плохо. Вроде бы в JSON схемах, не помню уже

и покажи, плиз, пример композиции схем. что-то не помню такого

В мире, откуда пришёл dry-validation, наследование вообще не очень популярное решение

В мире, откуда пришёл dry-validation, наследование вообще не очень популярное решение

поэтому мне кажется вполне логичным нести его в свой рельсомир "обернутым" в абстракцию

Про композицию схем — описываешь какие-то мелкие куски и собираешь из них required(:foo, :hash).schema(MyAwesomeSchema) можно билдер написать, что угодно

В абстракцию оборачивать — нормально, да

Но наследование схем — это что-то не очень естественное

Наследование абстракций, которые используют схему — мб нормально, зависит от абстракции

Наследование абстракций, которые используют схему — мб нормально, зависит от абстракции

дык если внимательно вчитаться я и не просил наследование схем )

а так — reform же работает с dry-v

Если правила валидации проверяют типы, то я закинул это к наследованию схем

а так — reform же работает с dry-v

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

я как-то брал hanami-validations, чтобы самому не выелосипедить, но там тоже все сыро

поэтому мне кажется вполне логичным нести его в свой рельсомир "обернутым" в абстракцию

Что-то так себе идея

Тут для тебя DI из коробки, а ты противишься

Что-то так себе идея

ну в константах хранить что ле?

Ага, в чем беда? Делаешь папочку с валидациями под контроллеры и в каждом файле константу делаешь с объектом схемы

Ага, в чем беда? Делаешь папочку с валидациями под контроллеры и в каждом файле константу делаешь с объектом схемы

ну не удобно чутка. да и чужеродно смотрится в рельсовом проекте

Ага, в чем беда? Делаешь папочку с валидациями под контроллеры и в каждом файле константу делаешь с объектом схемы

в этом твоем ханаме тоже схемы обернуты )

А папка с форм объектами чем тогда лучше? :)

в этом твоем ханаме тоже схемы обернуты )

Я не думаю, что там правильно это сделано

А папка с форм объектами чем тогда лучше? :)

тем, что это привычный рельсопуть – набор форм-обжектов. ну и вообще отличная абстракция на всякий

тем, что это привычный рельсопуть – набор форм-обжектов. ну и вообще отличная абстракция на всякий

Ох сейчас спорить начну

ну чувак. хотя бы взять, что мне неудобно каждой схеме объяснять где файл локализации лежит

к тому же, вопрос был о том, кто как делает, а не как правильно )

так копипаст же ну

ну чувак. хотя бы взять, что мне неудобно каждой схеме объяснять где файл локализации лежит

А делать это в форм объектах удобнее разве?

Можно ж написать базовую схемку, где есть только configure ?

(Не наследуются драй валидации)

Во всяком случае там было очень залупно это

локаль и type_specs вроде не теряются при наследовании

правила — иногда теряются

Про локаль не скажу, правила 100% теряются

Тогда уже проще сделать а-ля экшен ханами

Что бы класс метод был для определения схемы

Который заэвалиться когда и где надо

Ну и наследование это так себе вариант. Даже в джаву уже уходят от него (но это офтоп)

чой то

а как же все design patterns с наследованием

AbstractGavno

чой то

Сейчас все зависимостями прокидывают

коллеги, вы мне очень помогли вчера. можете помочь еще раз? https://stackoverflow.com/questions/53011200/how-to-check-if-the-file-is-still-locked-by-current-thread

вопрос в том, могу ли я как-то узнать глядя на файл — locked он или нет?

Скажите погромисты, просто запрос Model.where(name: ["Иван", "Андрей"], age: [25, 44]). Как сделать так, что искал в последовательно порядке? То есть, Иван 25 сперва, а потом Андрей 44?

Ну погромисты, незнаете ответ на этот вопрос?

И вот еще вопрос для Руби программеров, может подскажете: https://stackoverflow.com/questions/53011865/why-flock-works-differently-when-the-file-object-is-new

И вот еще вопрос для Руби программеров, может подскажете: https://stackoverflow.com/questions/53011865/why-flock-works-differently-when-the-file-object-is-new

это все вопросы скорее для С-программистов, которые лазили в руби-сорсы

а никто не сталкивался с этим?

почему flock() зависит от того, на каком объекте он вызывается?

он же по идее должен лочить файл, а не объект Руби

Как ты понял, что второй пример не рабочий?

подскажите что делаю не так? задача вывести списком c.title

<%= form.select(:kg_category, options_for_select([@categories.each do |c| [c.title, c.id] end])) %>

выводится так: <select name="kg_word[kg_category]" id="kg_word_kg_category"><option value="#<KgCategory:0x00007fee821f9f00>">#&lt;KgCategory:0x00007fee821f9f00&gt;</option></select>

<%= form.select(:kg_category, options_for_select([@categories.each do |c| [c.title, c.id] end])) %>

each возвращает исходный массив, подозреваю, что тебе надо map

each возвращает исходный массив, подозреваю, что тебе надо map

спасибо, с map заработал

Как ты понял, что второй пример не рабочий?

запустил его, а он не пишет Works

запустил его, а он не пишет Works

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

each возвращает исходный массив, подозреваю, что тебе надо map

Не понял

each чета возвращает ?

ессно

Схерали

Он ведь не должен ничего возвращать

схерали он не должен ничего возвращать? ты запрещаешь?)

схерали он не должен ничего возвращать? ты запрещаешь?)

Потому что это сахар для for?)

Потому что это сахар для for?)

наоборот. for в руби реализован через each

> 1 2 3 => nil

s = (1...4).to_a.each do |i| i + 1 end puts s

> 1 2 3 => nil

ну так это ж я и говорю

ну так это ж я и говорю

Про что?

Про nil?)

1 2 3

это откуда?

Т.е

Ты хочешь сказать, что each возвращает значение из каждой итерации?)

нет, each возвращает исходный массив

pry@2.5.1(main)> [1, 2, 3].each { 'pohui' } => [ [0] 1, [1] 2, [2] 3 ]

Не плохо значения возвращает

))))

Окей, в рубях он возвращает

Это самое логичное поведение из всех, что я видел

ну мы ж про руби вроде

ну так ич это же и не мап

а возврат значения для чейнинга

а возврат значения для чейнинга

Для слабаков

Больше стейта - лучше

а возврат значения для чейнинга

ну чейнинг условный конечно... типа чейнинг с только сайдэффектами

Процедурщиной завоняло