На прошлой неделе, когда я работал над своим проектом rails, все шло хорошо, и, как обычно, это происходит, когда монстр кода решает нависать над нашим усердно работающим успешным кодом с новыми идеями (как будто кто-то просил) и функциями. Поскольку я чувствовал себя ооочень уверенно, я решил послушать этого монстра, он говорил: «Какого черта вы собираетесь найти пациента на своей индексной странице? Вы действительно хотите просто пролистать все это, чтобы найти их? абсурд! ”
Я начал смотреть на свой проект по-другому и полагаться на монстра кода (наше сознание), чтобы увидеть, нужно ли реализовать окно поиска и имеет ли оно смысл для того, что я пытался сделать. Обычно мы узнаем о стольких замечательных новых функциях (бесконечных!), Но мы не уверены, когда и как их использовать, или даже о том, что, черт возьми, нам говорит исходный код. Я отвлекся, так когда же вам понадобится окно поиска? Всякий раз, когда вы хотите найти контент на своей странице, вы можете разместить поле поиска на любой странице просмотра (показать, индексировать и т. Д.), Просто разместив его там, где это имеет смысл.
После поиска в сети я наткнулся на несколько отличных постов среднего размера, как обычно, потому что это сообщество настолько велико. К сожалению, со средними сообщениями я не склонен понимать большинство из них, их код не всегда работает с моим кодом, а фрагменты не всегда объясняются так, как я это понимаю. Я полностью за то, чтобы скопировать какой-то код, но если я этого не понимаю, как я могу его реализовать? Итак, из этих замечательных блогов я создал простое и понятное руководство, которое поможет вашим окнам поиска работать где угодно!
Вот код, который вам понадобится, и где его разместить, после того как мы разберем, что он означает.
ШАГ 1.
Итак, здесь мы используем form_tag для создания окна поиска для вашего файла представления. Он требует аналогичного синтаксиса, который вы могли заметить, если когда-либо создавали форму с form_tag. В строке 3 мы добавили путь к форме, которая является индексной страницей пациентов, чтобы я мог найти пациента (пациента_путь). Это метод GET, потому что мы получаем информацию, запрашивая в поле поиска запрос GET для этого конкретного пациента. В строке 4 у нас есть text_field_tag, который использует модель, о которой мы говорим, рядом с параметрами модели пациента (такими как их атрибуты). Наконец, в строке 5 у нас есть тег отправки и кое-что новое, чего мы не видели до name: nil. Причина добавления этой строки кода - это только то, что вы заметите после того, как отправите свой поиск. В URL-адресе в браузере будет несколько дополнительных лакомых кусочков, которые заканчиваются на:
commit=Search
name: nil удалит это из URL.
ШАГ 2:
Поскольку мы будем работать с индексом в вашем контроллере, вы добавите туда дополнительный код, чтобы ваша форма поиска работала. Нам нужно будет создать некоторую условную логику, чтобы индекс выполнял поиск пациента.
Код проверит, существуют ли params [: Patient], и если да, то он переместится в логику Patient.where, которая имеет необычный синтаксис SQL lite, в котором будет сохранен в экземпляр @ members. Но что на самом деле говорит нам синтаксис Patient.where? К счастью, док-станция API нас покрыла, взгляните, чтобы понять, как использовать метод .where!
Короче говоря, .where () будет обращаться к таблице пациентов, и там, где находится атрибут / столбец имя, он будет сравнивать, НРАВИТСЯ то, что искали, если да Затем он получает информацию о пациенте с соответствующей информацией в столбце.
SELECT “patients”.* FROM “patients” WHERE (name LIKE ‘%%’) LIMIT ?
SQL может выплюнуть что-то вроде этого, в таблице пациентов выберите всех пациентов, имя которых похоже на поиск ввода.
Строка 7 - это наш оператор else, который отображает список всех пациентов.
Уф! Так много информации и способов что-то делать, не бойтесь экспериментировать. Если вы нашли это полезным! Также ознакомьтесь с этими замечательными блогами на Medium, которые вдохновили меня на создание этого поста, удачного кодирования!
Особая благодарность: Джонатану Зильбербергу и Ясси Мортенсену
