@nepster09 я невнимательно прочитал вопрос, извиняюсь.
Применительно к htmlcpecialchars - зависит от политики сервиса. К примеру, можно сделать так: фильтром вычищать все теги перед сохранением, а при выводе использовать encode (на случай если в базу что-то попало извне).
beforeSave вызывается один раз, непосредственно перед сохранением.
Хранить экранированные значения в базе не вижу смысла.
@cissav Эээээм.
В каком месте я превозносил одних и принижал других?
На любом проекте есть задачи, требующие РАЗНОГО вложения времени от специалистов в разных областях.
Возьмем конкретный пример: условная форма редактирования элемента.
Нарисовать: один час.
Сверстать: один час.
Запрограммировать: один час.
Далее, пользуясь готовым внешним видом и версткой, программист может создать еще сто форм всех видов, затратив дополнительно сто часов. При этом затрат со стороны дизайнера и верстальщика либо не потребуется, либо они будут минимальны.
Означает ли это, что программер круче всех? Нет!
Означает ли это, что программер затратил больше всех времени? Да!
При этом, суммарные затраты по созданию условного сайта легко измеримы и контролируемы (таск-менеджмент, коммиты, whatever)
Если в Вашем рабочем процессе каждую из ста форм приходится рисовать и верстать заново - это какой-то неправильный рабочий процесс.
Нет, серьезно, я вообще не понял, что Вы сейчас сказали.
@wapmorgan Ну так я ж и говорю,
SELECT MAX(creation_datetime) AS m
WHERE user_id = 1 OR receiver_id = 1
GROUP BY user_id, receiver_id
ORDER BY m desc
LIMIT 1
Вот есть у Вас куча контроллеров. Их всех можно, допустим, отнаследовать от некоторого базового контроллера (и, вроде, по умолчанию они наследуются от components/Controller.php)
Дальше где-нибудь в базовом контроллере можно ДО старта экшна слазить в БД за параметрами. Таких мест минимум два: init() и beforeAction().
Слазив в БД и добыв оттуда нужные параметры, можно сохранить их в стандартный массив Yii::app()->params, при необходимости перезаписывая уже существующие ключи:
Yii::app()->params['adminEmail'] = $model->adminEmail.
Дальше добывать параметры, соответственно, можно из любого места аналогично: <?= Yii::app()->params['adminEmail'] ?>
Я, может, просто вопрос не понял? а то каким-то Капитаном Очевидность себя сейчас ощущаю. Ну, в том смысле, что наследование от базового контроллера прописано прямо в файлах, добыча параметров прописана в каментах к конфигу, ну и так далее, то есь даже в доку лазить не надо.
@Fesor в данном случае требуется привязка именно к id, поскольку случайное появление элемента с аналогичным селектором (класс, ...) на странице вызовет нежелательные эффекты.
@eprivalov
Вариант 1: воспользоваться готовым решением (ссылки есть выше в ответах)
Вариант 2: найдите базу стран-регионов-городов. Сделайте к ней ajax-интерфейс, который по названию будет отдавать данные по городам. К примеру:
select c.id, c.name, r.name, k.name from cities c left join regions r on c.region_id = r.id left join countries k on c.country_id = k.id order by ...
У некоторых городов мира нет привязки к региону, поэтому в region_id иногда будут встречаться null.
Ответ от сервера разгребайте и формируйте выпадающий список с указанием региона и страны, типа
МО
МОСКВА, Россия, Московская обл.
МОЖАЙСК, Россия, Можайская обл.
МОГИЛЕВ, Белоруссия, Могилевская обл.
Самое интересное, полагаю, будет с order by. Тут, наверное, имеет смысл ввести понятие "вес", чтобы москва появлялась выше мохосранска. Хорошо бы еще учитывать текущее местоположение пользователя, чтобы еще и по стране сортировать.
ActiveRecord в yii2 работает следующим образом: сначала мы создаем объект ActiveQuery с необходимыми условиями и параметрами запроса, дергается БД, выгребается массив.
Если мы дополнительно указали asArray() - то больше ничего не происходит, массив возвращается в качестве результата.
А вот если не указали (и, не дай бог, указали дополнительно indexBy('some_field') - тогда начинается лютая свистопляска с пробегом по массиву данных и конвертацией в AR-объекты.
Предположим, нам нужно сделать какое-нибудь API, или, к примеру, экспорт в csv. Как это делается - вот тут писал: https://github.com/samdark/yii2-cookbook/blob/mast...
правда недописал про custom formats, допишу при случае, там прикольно.
Но суть в том, что УЖЕ имея на руках массив, выполнять конвертацию в AR, а потом обратно в массив только из-за формата поля created_at - это анальная педофилия, так быть не должно по-хорошему. И красивое
для json-ответа на самом деле внутри себя выполняет что-то около четырех циклов по одним и тем же данным,.
Можете считать меня задротом, но я не думаю, что это круто. И, кстати, абсолютно так же думают некоторые провайдеры, которые любят отстреливать процессы за превышение памяти (пальцем показывать не буду, но название начинается на "ру").
А там довольно занятные значения получаются, особенно если включить задрота и заносить каждую мелочь.