dma026, так вы вопрос сформулируйте более конкретно.
Если я не ошибаюсь, даже для тестового нам выдавали какие-то ключи или как минимум данные клиента.
Запрос строится по документации, сложностей в ней не так много, сам формат простой, когда начинаешь в него вникать при попытке построить первый запрос. Сложнее, когда формируется запрос согласно данным из вашей базы в формат нбки, но и тут, главное соблюдать количество пробелов для каждой секции.
galliard, ее не нужно дублировать. У вас есть две разные сущности, хоть и из одной таблицы в БД. Если я не ошибаюсь, то ДДД игнорит факт наличия структуры в БД и вообще ее наличие, и тогда это не противоречит.
И реализуется логика получения и работы с простой сущностью и логика с полной сущностью. Таблица одна, сущности разные, бизнес логика разная.
Максим Тимофеев, просто я не вижу, чтобы можно было указать относительно модуля. Такое ощущение, что все строится относительно текущего контроллера и максимум что можно сделать относительно - относительно модуля текущего контроллера. Нужно короче переопределять метод в модуле, который будет отдавать это как то мониторить.
Максим Тимофеев, мне нужно разграничить две версии данных на уровне модуля.
Для модуля admin набор rules: 1,2,3
Для модуля user набор rules: 4,5,6
Чтобы не дублировать код, я вынес все в отдельный модуль, который получает нужные данные ориентируясь на конфигурации модуля. Теперь когда я этот модуль помещаю в подмодуль, я не могу использовать виджет из подмодуля, потому что я не знаю имени модуля, в котором он зарегистрирован, который к тому же можно переименовать в конфиге.
З.Ы. Сущность admin, user и rules высосаны из пальца для примера. В реалиности там справочники и полноценные сущности, которые требует распределения по подмолулям с различной конфигурацией. Но суть не меняется.
Максим Тимофеев, тогда оно работать на подмодуле не будет. Запрос должен пойти на /admin/rules/default/index, а не на /rules/default/index. Потому что сейчас появится второй роут в этот же модуль, но в другом контексте /user/rules/default/index. И получается модуль требуется анализировать, куда вложен модуль и прокидывать кучу говна, вместо указания относительного роута.
Максим Тимофеев, виджет находится в модуле, к которому и предоставляет доступ поиска. Почему это ересь? В 10 местах писать один и тот же код инициализации одного и того же поля с настройкой роута для получения поиска?? Логично же вынести код его инициализации в виджет и использовать его везде, где это нужно.
Arik, от него я ожидал так же, как и от валидатора, корректное понимание, что при указании формата yyyy он будет игнорировать даты типа 201, 20 и 2, но по факту, они все считают это валидной датой. Собственно я могу это понять, ведь даты действительно валидные с точки зрения даты.
Пока решил указание везде минимальной даты в 1970 год. Если это единственное решение, то нужно записывать его как обязательное для дат в timestamp формате в своей книге рецептов... И еще более аккуратно относиться к датам в коде.
Arik, с фронта то приходит без ведущего нуля. И мне не нравится именно этот костыль, что нужно тогда каким то боком учитывать, что может завтра поменяться требование к формату даты и опять новый костыль. А учитываю, что Yii2 к форматированию даты полностью полагается на \DateTime объект, поможет только если в самой PHP сделают фикс. А зачем делать фикс для, по факту, валидной даты...
Пора менять bootstrap datepicker на что то толковое.
Понятное дело, что даже 01.01.01 валидная дата, но тогда и timestamp для нее должен создаваться, либо сам валидатор не должен пропускать такие даты. Просто не понятно, почему \DateTime::createFromFormat('d.m.Y', '01.01.201') считает дату валидной, но при этом new \DateTime('01.01.201') пишет, что Failed to parse time string (28.04.201) at position 8.
davidnum95, в одном проекте все запросы отправляем на один контроллер и действие, что отправляет заголовки через корсу и просто true. В других, где только отдельные методы для реста, непосредственно действие отслеживает option запрос и выбрасывает true с заголовками из корсы.
Мне нужно пропихнуть только value. Я хочу чтобы модель сама взяла зависимость от класса. Иначе в чем смысл использовать в данном случае контейнер зависимостей.
З.Ы. Докопался до информации, что через params нужно пропихнуть по ИНДЕКСУ! Т.е. я должен явно указать массив у меня вторым параметром... А если я поменяю зависимость, то нужно менять все вызовы из контейнера.
Модератор, простите, а как вы это определяете?
Yii написан на php. В него можно интегрировать любую разработку на php и использовать, вопрос не исключал такую возможность.
jQuery тут нужен по той же причине. Если есть библиотека для подобного, можно чуть провести времени и интегрировать его в yii для работы с динамическими формами.
Не пойму, почему они лишние? Может я не совсем подробно описал чуть задачи, но это не отменяет возможности внедрения данных тегов. Yii, php и jquery по моему идут бок о бок и любой совет тут полезен.
Если я не ошибаюсь, даже для тестового нам выдавали какие-то ключи или как минимум данные клиента.
Запрос строится по документации, сложностей в ней не так много, сам формат простой, когда начинаешь в него вникать при попытке построить первый запрос. Сложнее, когда формируется запрос согласно данным из вашей базы в формат нбки, но и тут, главное соблюдать количество пробелов для каждой секции.