Владислав Лысков, смотрите, в вашем коде $first_age - массив, результат действия функции array_column.
Внутри вашей функции calculate_age вы используете strtotime - ему нужна строка.
$first_age[0] - это мы взяли первый элемент массива.
Либо второй вариант, я выше писал, мы в цикле проходим по каждому элементу массива отдельно и сразу его передаём.
ff0xff, ну отлично помогает.
Используете Task Scheduling для настройки выставления и выполнения заданий. События для перехвата событий. Уведомления для уведомлений (не важно имейл, пуш, мессенджеры).
Короче говоря в Ларавел можно сделать жту задачу красиво, масштабируемо и прозрачной.
И пусть что тягать нужно каждый раз.
Суть в том, чтобы пользователь не висел с "зависшим" бразуреом, так как там у вас нет контроля и пользователь в любой момент прервёт всё или отправит повторный запрос и тп.
А так, с отложенной тяжелой задачей, вы всё контролируете, меньше дупликатов и тп и тд.
В любом случае это единсвенно верный подход для тяжелых задач. Ведь пользователю та ки так ждать выоплнения. Но в случае нормальной реализации, меньше шансов что что-то пойдет не так.
Покажи побольше твоего composer.json, можешь там удалить части что касается твоего пакета непосредственно, если это тайна.
Или хотя бы покажи строчку с указанием версии php
Comsequent, не покатит же, там другой домен же. Это работает когда у себя такое делаешь. А здесь iframe вставляется с другого домена, инстаграмного. Доступа не будет.
PHPjedi,
Это вопрос уже больше из UX и в тч UI. У многих такие моменты реализованны определенным путём не потому что правильны, а исторически уже так сложилось.
Если описать общую движуху, то выходит примерно так:
Итак, мы не знаем пользователя и он пришёл в первый раз:
Смотрим локаль браузера, смотрим GeoIP.
Сам интерфейс изначально делаем на языке локали браузере (либо на языке по умолчанию, если языка пользователя нет, обычно это английский).
На основе данных из GeoIP мы решаем, показать ли небольшое всплывающее окошко внизу(важно чтобы оно было не блокирующим основной интерфейс и легко и понятно закрывалось), с предложением выбрать нужный язык.
Например, человек зашел, у него в браузере локаль английская, а ip русский, вот ему и показать миниокошко внизу с сообщением, что есть возможность включить русский язык. Если он его закрыл, значит пиши в localStorage язык его браузера (в данном случае английский), если согласился то соответственно ставим язык русский (или тот что мы предложили). Так же в этом окошке хорошо дать ссылку/указание на все языки.
При это важно, пока пользователь ничего не выбрал, мы ничего никуда не записываем, тк управление должно оставаться на уровне пользователя. Он у себя в системе/браузере меняет язык, и после этого меняется язык и в вашем приложении.
Всё что выше описано касается и постоянных и зарегестрированных пользователей. Пока, человек не сделал активных действий по сохранению настроек, мы действуем на основе данных о локали из устройства (используя GeoIP только для того чтобы не сильно намекнуть на возможность выбора языка страны откуда он вышел в сеть).
Таким образом, пользователь сам у себя определяет с каким языком, на каких своих устройствах он работает.
Теперь насчет сохранения у зарегестрированных пользователей. Конечно же хранить в базе данных. Для таких настроек удачно подходит тип поля json в sql (есть во многих современных бд и в mysql, mariadb, postgresql и тп) в котором удобно хранить различиные подобные настройки пользователя, язык, тема оофрмления и тп.
Итак, приоритеты по выбору языка, от высшего к низшему, каждый действует если он установлен, иначе игнорируется:
1. Настройки из БД (конечно актуальны только для зарегистрированных, будут действовать на любом устройстве где он пройдёт аутентификацию )
2. localStorage (на каждом устройстве/браузере своя)
3. Локаль из устройства(браузера)
3.1 Поправка по GeoIP
Если всё сделать правильно, то выйдет прозрачная и простоя система для пользователя, где дурацкие всплывающие окошки показываются обычно один раз (он либо закрыл его и мы сохранили в localstorage язык его локали браузера, либо он вбырал предложенный язык на основе GeoIP), и пользователь получит скорее всего сайт изначально в ожидаемом виде.
Сергей Некий, я не понимаю о чём мы спорим.
1. Я сам написал что во многих ситуация проще и легче использовать обычные шаблоны.
2. Ну ок, я вам не авторитет, но надеюсь создатели Vue авторитеты? Понимаете нередко в сложных проектах нужно писать собственные рендер функции для своих компонентов, поэтому и советуют использовать JSX, а не стандартный интерфейс рендер функций.
Еще раз, JSX не для замены шаблонов самого vue, а для упрощения кода при использовании рендер функций, чтобы их написание было максимально приближено к шаблонам.
Не вижу противоречий и проблем.
А уж по каким причинам разработчик/архитетор решает конкретную задачу (тем или иным способ, шаблоном, шаблоном в компоненты, просто html, через рендер функции) это отдельный разговор, конкретные цели и задачи, конкретного проекта.
И да, вполне возможно вам это никогда не пригодится. НО, это не значит что так нельзя, или это прям принципиально плохо.
ну блин, есть же моменты когда нужно писать что-то свое, выходящее за рамки стандартных шаблонов.
Тогда JSX нагляднее и выиграет у обычных функций со всеми этими криейтэлемент и тп.
Да даже сами создатели Vue поощряют использование JSX в таких ситуациях, описывая преимущество в соответствующем разделе
Сергей Некий, Ну так и написал, что для простых случаев лично предпочитаю использовать шалоны с директивами. Но ведь есть и не простые случаи, и тогда читабельность множество рендер-функций мягко говоря не очень. Тут с JSX как легче, нагляднее и гораздо ближе к привычным шаблонам.
Я не понимаю почему RAD(если это вы про rapid application development) должно противоречить энтерпрайз разработке.
Это скорее как тёплое и мягкое сравнивать.
Тот же симфони вполне себе RAD и был, и тем более стал им с 4 версии.
Если грубо говорить, то Yii можно сранивать со старым Симфони. Но в новом уже совсем иной подход, точнее они развили/легализовали свои лучшие стороны, став модулями/кирпичиками для чего угодно.
А Yii я бы сегодня уже нигде не использовал в новых проектах.
Slim - мега удобный, и сегодня почти по умолчанию, микрофреймворк на котором можно строить что угодно, без лишних обязательств(читай доп ненужных библиотек и навязывании каких-либо правил, структур проекта). Отлично подходит для мелких задачек.
mrusklon, зачем свои велосипеды с бесконечными подводными камнями в изменяющихся условиях. Уже есть удобное решение. Вам только назначить на селект слежку за изменением( .on( 'change',...) ) и все. Вот даже в примерах есть.
Короче говоря советую не мудрить и брать готовое решение с хорошей оптимизацией.
jazzus, Auth::user() возвращает все верно Он возращает класс юзер, который расширяет класс Model (откуда собственно и растут ноги Eloquent ). Далее вы используете метод first() , который возвращает первого в выборке из БД (по молчанию по первичному ключу, те с id1). И не важно что уже до этого был юзер, вызвав метод first на классе/потомке Типа Model вы делаете запрос к БД, и получаете результат.
withCount('lists') расположен логично, до выполнения самого запроса, так как это можно считать частью условия выборки, так же как и where например.
Андрей Саныч, ну это понятно. Я больше в контексте производительности.
Ну может это мои личные мыши в голове, но я в целом не сильно удовлетворен скоростью работы их IDE, поэтому парюсь из-за лишних плагинчиков.
PS хотя это говорит человек у которого установлен Nyan Progress Bar (-:
coderxx, ну мне кажется для верстки/фронтенда лучше вебсторм(а нет, вижуал студио код). Но конечно же если активная разработка с пхп нечего плодить сущности.
Внутри вашей функции calculate_age вы используете strtotime - ему нужна строка.
$first_age[0] - это мы взяли первый элемент массива.
Либо второй вариант, я выше писал, мы в цикле проходим по каждому элементу массива отдельно и сразу его передаём.