код приводить не имеет смысла, т.к. его надо тестить, но алгоритм может быть такой:
1. На beforeValidate вешаем блокировку кнопки
2. На afterValidate вешаем снятие блокировки, при условии что валидация не прошла и в форме есть ошибки (ведь если пользователь допустил ошибку - нужно дать ему повторную возможность сделать сабмит)
3. На beforeSubmit или на Submit (в зависимости от того что Вам нужно) - так же вешаем разблокировку кнопки.
Антон Рейтаровский: вот так стало понятнее :) тогда должно быть две вьюхи и два действия контроллера, т.к. "Резюме" и "Вакансии" два логически разных объекта, которые могут иметь различные характеристики. Возможно сейчас они идентичны, но в любой момент эксплуатации системы это может измениться. К примеру, нужно будет добавить в "Резюме" информацию о предыдущих местах работы, в Вакансиях этой информации по своей природе быть не может.
это относится к ответу на первый вопрос. Не нужно слепо следовать паттернам, например "каждая сущность должна быть построена по принципам ActiveRecord". Если у Вас сущность должна взамодействовать с базой - применение этого паттерна допустимо, если нет - то и паттерн применять не стоит.
Не совсем правильно выразился. Класс сущности не должен наследоваться от класса DB - он должен его использовать. Вообще в этой ситуации я бы рекомендовал применить паттерн ActiveRecord
имел ввиду всяческие архитектурные решения которые сейчас используются (их всех перечислить просто не возможно.) Для понимая основ рекомендую почитать книгу Фаулера - Архитектура корпоративных программных приложений.
нет. format как раз не меняет значение внутри объекта, он просто возвращает строку с датой в нужном формате, например:
$date = new DateTime('2015-06-01');
$date->modify('+1 day'); // дата станет 2015-06-02
echo $date->format('Y-m-d');
$date->modify('+1 day'); // дата станет 2015-06-03
echo $date->format('Y-m-d');
Stasgar: а где именно рекомендуют? Если мы, к примеру посмотрим на стандартный шаблон приложения https://github.com/yiisoft/yii2-app-advanced/tree/... , созданный непосредственно разработчиками yii2 то можно увидеть что подобный вещи реализованы через отдельный модели
ну не скажите, представим такую задачу есть GPS трекер, где у каждой компании есть свой пул автомобилей.
Так же у нас есть отчет содержащий подневно информацию о суммарном расходе топлива для всех машин компании.
Таблица отчета имеет такую структуру:
- идентификатор
- дата, тип date, вес 3 байта
- сумма, ну допустим возьмем float, вес 4 байта.
Теперь у нас стоит задача вывести по конкретной компании отчет за текущий месяц, в котором будет информация о всех днях месяца.
В текущем месяце у компании имеется всего 3 записи (3 дня машины ездили, оставшиеся 28 нет)
Для начала мы выбираем данные по компании - с этим проблем нет.
Но что будет если мы используем таблицу-календарь и заджойним получившуюся выборку с ней?
1. Джойн в самом простом варианте это два цикла (один вложенный в другой), таким образом для получения результата мы получаем 3*31=93 итераций.
2. После осуществления всех операций наш результат будет 31 запись по 7 байт каждая - всего 217 байт. Далее эти 217 байт передаются с сервера MySQL в оболочку который его использует (передача данных тоже занимает какое-то время)
Если же мы недостающие даты будем проставлять в оболочке, без использования джойнов:
1. Мы можем доставить недостающие даты приблизительно за 34 итерации
2. В результате простой выборки из БД в оболочку будет доставлено всего 3 записи общим размером 21 байт, а не 217
Конечно если объемы системы небольшие, и запросы не частые - можно заджойнить и не парится, но если громадные нагрузки второй вариант будет оптимальнее первого
в случае с varchar нет, без разницы какой размер будет выставлен 50 или 250, объем и скорость будет зависеть только от реального объема хранящихся данных
потому что, во первых это дурной тон, а во вторых ваше приложение должно контролировать входящие данные. Сделаете Вы везде максимальную длину полей, а что это даст?
1. Вы не сможете в перспективе сделать индекс по таким полям (длина индекса ограничена)
2. Будет у Вас много таких полей в таблице, в которые пользователи введут по 100500 символов и Вы наткнетесь на лимит размера строки (точно не помню сколько он в байтах). А они ввести могут, разные кадры бывают ...
3. Как уже говорил, приложение должно контролировать ввод данных. Я встречал базы в которых пользователи вводили в поле "Имя клиента" не только его имя но еще и 3 телефона.
в общем ничего Вам не мешает поставить по максимуму, но решая один не большой гемор, Вы в перспективе можете получить несколько более серьезных, которые в процессе эксплуатации проекта будет сложнее устранить.
Вообще рекомендовал бы Вам этот вопрос оговорить с руководством/заказчиком. Как правило они должны знать приблизительный объем вводимых данных.
