Shane Matte: в вашем случае нужно хранить в localStorage. С учетом того что вы собирались хранить в метатеге - рекомендую более детально разобраться что зачем и почему.
DevMan: Да, но скажите это Apple и их гайдлайнам. Они категорически настаивают на том что бы для кастомной аутентификации использовались X-* заголовки, потому что дефолтный Authorization может быть переопределен системой.
В целом RFC 6648 говорит ли что это не рекомендуется но не запрещено.
Владимир Грабко: забейте на терминологию laravel. Модели в контексте eloquent это модели отдельных сущностей а не всей предметной области (не все бизнес логика может быть в сущностях).
Для этого и придуман сервисный слой. По сути "модель" в контексте MV* штук это приложение без UI. То есть это далеко не один класс. Причем с точки зрения каждой вьюхи моделью для нее будет вершина графа объекта с которой оно соприкасается и только.
Короч сервисы - это хорошо. Контроллеры не должны особо знать разницу между сервисами и сущностями. Это просто объекты.
Владимир Грабко: уточню на всякий случай. В чем вопрос? Где делать запросы к внешним сервисам - в сервисах. В случае авторизаци - сервис юзер провайдеров я полагаю.
В вашем вопросе слишком много хваставства и очень мало вопроса.
Владимир Грабко: это называется не пассивная а анемичная модель. И повторюсь, в случае пассивной модели у вас логика должна была вытечь в контроллер и тогда как бы можно забыть вообще о том что у нас есть это разделение. Тогда контроллер становится моделью и возникает высокая связанность модели и представления (так как нет мидиатора между ними и моделька вынуждена сама готовить представление).
Типизация в php7 такая же какая была в php5, слабая динамическая. Тайпхинтинги помогают но не сильно. С динамической системой типов удобнее работать.
NikHaker: ну вот, то есть уже есть какая-то база. В этом случае да, можно пробежаться по документации что бы скоррелировать свои знания с тем что есть в PHP (типы данных, ограничения накладываемые, по тому же ООП что есть а чего нет. например нет множественного наследования зато есть интерфейсы, с которыми проще не нарушать LSP).
Ссылку на php right way вам привели, можете там ознакомиться. А далее незнакомые слова - википедия (желательно не русская, там часто расплывчато).
javanub: а какого рода практика может быть без опыта написания алгоритмов? Я же не предлагаю погружаться в это с головой, просто тренироваться решать задачи мол "у тебя есть массив с рандомомными числами, отсортируй".
javanub: это да, тут вопрос вовремя остановиться и попробовать разобраться в более глубоких проблемах. Например построение алгоритмов. Просто банально больше практики в этом ключе. Даже банально написать пузырек бывает полезно.
когда человек не знает как обходить результаты базы - это означает более фундаментальные пробелы в знаниях а именно неумение проводить декомпозицию и строить алгоритмы.
а зачем вам хранить исходники в отдельном контейнере? Пихайте их прямо в контейнер с PHP и там храните. Намного проще и профита от отдельного контейнера с исходниками вы не получите.
Кот Учёный: повторюсь. Есть разные проекты и разные требования. В моих проектах сделать все p2p будет безумно сложно и проще вынести бизнес логику на клиент. С другой стороны в некоторых проектах можно вообще без бэкэнда обойтись как вы и описываете.
Вы сейчас говорите о проекте где от бэкэнда не требуется ничего сложнее CRUD-а. таких проектов пожалуй процентов 90%.
SerzN1: если у вас 10 ресолверов, у вас есть один главный, который занимается непосредственно проверки, а остальные просто требуют что бы тот отработал первым.
artem_music: посмотрите по ссылке. Там именно краткое описание возможностей и особенностей фреймворка. А погружаться в документацию или нет решайте сами после прочтения вводной части.
