Базовый скелет проекта PHPixie задуман быть минималистичным, чтобы не навязывать архитектуру пользователю. Но в нашем чате часто возникают вопросы о том как настроить авторизацию, стоит ли разделять фронтенд и бекенд в отдельные бандлы, как лучше организовать процессоры, и тд. Начинать с пустого проекта гораздо труднее для новых пользователей, что поднимает порог вхождения, к тому же иногда просто хочется начать на шаг вперед. Как раз для этого был создан расширенный скелет проекта, в котором это все уже работает.
Демо
Итак, более подробно что у нас тут:
- Регистрация пользователей
- Логин с опцией «запомнить меня»
- Проверка логина на страницах
- Панель администратора с отдельным логином
- Администраторы хранятся в отдельной таблице, их можно добавлять через консоль
- Возможность администратору имперсонировать любого пользователя
Использование
composer create-project phpixie/project-auth project
Настраиваем веб-сервер в папку project/web и готово. Один администратор уже добавлен, его логин phpixie / framework, но можно и добавить своего через консоль (к сожалению в PHPixie пока нет красивого компонента для вызова команд с консоли):
php addAdmin.php someUser somePassword
Проект настроен использовать SQLite базу данных которая лежит в database.sqlite. Вот ее структура для MySQL:
CREATE TABLE `users` (
`id` INTEGER AUTO_INCREMENT PRIMARY KEY,
`email` VARCHAR(255) NOT NULL UNIQUE ,
`passwordHash` VARCHAR(255) NOT NULL
);
CREATE TABLE `userTokens` (
`series` varchar(50) NOT NULL,
`userId` int(11) DEFAULT NULL,
`challenge` varchar(50) DEFAULT NULL,
`expires` bigint(20) DEFAULT NULL,
PRIMARY KEY (`series`)
);
CREATE TABLE `admins` (
`id` INTEGER AUTO_INCREMENT PRIMARY KEY,
`username` VARCHAR(255) NOT NULL UNIQUE ,
`passwordHash` VARCHAR(255) NOT NULL
);
Код на Github: github.com/PHPixie/Project-Auth
Если вам интересно как выглядит работа с PHPixie загляните в этот проект и надеюсь вы приятно удивитесь.
SerafimArts
На будущее — не используйте регистр в именах полей, вместо userId желательно именовать поля как user_id. В некоторых реализациях БД регистр не имеет никакого значения и поля, например для пароля (password) «проверочного слова восстановления пароля» (passWord) будут идентичными. Пример конечно же излишне надуманный, но всё же правила хорошего тона и всё такое.
jigpuzzled
так в чем проблема? сама БД не позволит создать колонки password и passWord в одной таблице по той же причине
Big_Shark
Ну и как минимум все другие орм и фреймверки хотят использовать поля именно с _, тем самым использую такую схему, человек получит геморрой при смене фреймверка.
jigpuzzled
ммм, я вот с доктриной всю жизнь кемел кейс использую. «Все» это какие?
Lachezis
Правило хорошего тона в SQL базах данных.
jigpuzzled
Где такое написано?
Lachezis
Ниже написал причину.
ellrion
тоже ближе snake_case однако не слышал что это «правила хорошего тона» и знаю много разработчиков которые любят camelCase и в названиях таблиц и в именах полей (и ругаются на Laravel что она по дефолту работает именно со snake_case).
Lachezis
Snake_case это case insensitive идентификатор, все ОРМ сейчас экранируют колонки и имена таблиц — так что это не так критично, но если нужно написать запрос руками то с CamelCase возможно придется экранировать идентификаторы в зависимости от настроек базы (Postgres вроде по умолчанию все приводит в lowercase). Это просто удобнее.
jigpuzzled
так есть куча полей которые и так придется экранировать по этой логике, например поле «name» и тд. snake_case и camelCase различаются только когда дело доходит к нескольким словам в идентификаторе
Lachezis
По какой логике? Поля приводимые к lowercase экранировать не обязательно.
jigpuzzled
давай лучше скинь пример запроса где это будет проблемой, а то честно в упор не пойму о чем ты
Lachezis
select name, countPurchases from usersчто бы это заведомо завелось нужно использовать
select name, "countPurchases" from users.snake_case отработает с и без экранирования идентификаторов на любой базе.
jigpuzzled
попробовал с кавычками и без, все работает
summerwind
Первая ссылка в google по «sql style guide»:
ellrion
Ну как бы стайлгайд од какого то чувака это не доказательство и не правило хорошего тона. В разных фирмах или сообществах свои стайлгайды. (напомню что я за snake_case, но не против camelCase)
summerwind
Я бы не стал называть его просто «каким-то чуваком» =) Я просто привожу в пример реально существующий стайл-гайд, где четко указано использовать «underscore». И я знаю людей и команды, которые придерживаются его (за неимением официального от MySQL или PostgreSQL). По мне, так достаточно нормальный аргумент, если учесть что в поддержку CamelCase я не вижу ничего кроме вкусовых предпочтений отдельных людей.
jigpuzzled
Стайлгайд это просто стайлгайд а не правило хорошего тона. По такой логике можно сказать что ваш код на PSR-2 плох потому что он не по стайлгайду Зенд фреймворка.
Если честно я совсем не понимаю что все придрались к именам таблицы и полей, если вам никто не мешает использовать какие-себе хотите. Уже больше 20 комментов, ни один по фреймворку и коду, а все о камелКейсе
Rastishka
Так холивар же.
Мне больше нравится этот ответ:
"Being consistent is far more important that what particular scheme you use."
Так что для большего единообразия полей AR и кода лично я выбрал camelCase.
summerwind
А я считаю, что каждый язык должен использовать свой style guide. У SQL свой, у PHP свой, у JSON-API свой. У меня был случай, что мне нужно было перенести проект на другой язык. И что мне, всю схему БД менять? Или добавился второй клиент, использующий JSON-API, написанный на языке с другим стилем именования переменных.
Rastishka
У меня данные из MySQL базы данных, через Active record на PHP загружаются в объект JS и рендерятся на клиентсайде в HTML5.
Вопрос: какой стайлгайд мне использовать? Или на каждом уровне свой?
PS Использую camelCase на всех уровнях.
summerwind
Я бы использовал на каждом уровне свой + маппинги. Потом я мог бы переименовать хоть все поля в БД, и мне не пришлось бы менять ни строчки в JS.
summerwind
Если, как вы заметили, многие сделали вам замечание по поводу имен полей — так, может быть, действительно что-то не так?
P.S. И да, я считаю, что писать согласно общепринятому для языка стайлгайду — это правило хорошего тона. Для PHP это PSR, для Python это PEP 8, для Javascript это гайд от Airbnb (несмотря на то, что он неофициальный, его придерживаются очень многие).
jigpuzzled
так для SQLа какой? Лично я люблю кемелкейс потому что я могу сразу с БД отправлять в джаваскрипт где и так все камелкейсом.
summerwind
Так хотя бы вот этот. Это более-менее распространенный, хорошо оформленный стандарт.
А потом, когда у вас поменяется название поля в БД, вы будете по всему JavaScript-коду его тоже исправлять?
ИМХО, более-менее серьезные проекты должны использовать что-то вроде https://github.com/thephpleague/fractal
Rastishka
Всегда было интересно посмотреть список этих "некоторых БД", где проблема с camalCase,
чтобы никогда с ними не сталкиваться.SerafimArts
sqlite, mysql, наверняка ещё какие-нибудь.
Lachezis
В MySQL кстати флаг есть который вырубает это.
SerafimArts
Ну так оттюнить можно по-разному почти что угодно, наставить плагинов, ещё чего-нибудь. Не суть.
Более жизненный пример: Напишет кто-то поле
userNameс камелкейсом в БД, а внутри самого кода другой человечек будет писать$entity->username, потом окажется что потребуется переезд на новую БД, т.к. этот сервак сгорит к чертям (у меня такое было, когда БД повреждалась, благо реплика была). А там этот флаг стоит и весь код накрылся, догадывайся только почемуusernameне отображается (значение null в популярных AR для доступа к неизвестным полям моделей). Удачной отладки, называется. Ну а в случае выборкиSELECT username FROM ...— вообще все запросы накроются, т.к. мол полеusernameне найдено.Сама суть в том, что работа программиста — это не только писать код, но и думать о будущем своего кода, в каких ситуациях и каких задачах он будет использоваться и проще уж выработать привычку в БД всегда хранить андерскор поля, благо это не сложно и не потребует никаких усилий, а не разбираться в возможных проблемах уже после того, как они случаются.
jigpuzzled
ну уж если говорить о переезде с одного конфига на другой так тут историй можно еще хуже понапридумывать. Суть проста: большинство БД не чувствительны к регистру, камелкейсу это никак не мешает если писать нормальный код а не «uSerNAme», а если писать фиг знает что то проблемы будут везде
Rastishka
Работаю с mysql поля в camelCase и не было проблем.
Вопрос: что я делаю не так?
xstudent
В постргесе будут проблемы: Таблицу можно создать как «TeSt1», а попытаться использовать как select * from test1. Будет ошибка «ERROR: relation „test1“ does not exist LINE 1: SELECT * FROM test1»
jigpuzzled
так а зачем использовать другое имя?
xstudent
В том то и суть, что оно другое только за счет регистра. Масса примеров, когда можно попасть на ошибки. Например, когда код не использует автоматическое заключение в кавычки, или запросы написаны напрямую, Зачем создавать потенциальные проблемы, если можно этого избежать, следуя соглашению о не-использовании в бд кемелкейса?
xstudent
P.S. Привычка не-использовать кемел-кейс в моем случае выработалась не в результате чтения код-стайлов, а как раз после многократного выяснения, почему не работает вроде бы правильно написанный код.
Rastishka
Ога ога......
Расскажите это разработчикам на JS: согласно code conventions там переменные и функции надо называть в camelCase, а переменные TeSt1 и test тоже внезапно будут разные.
xstudent
Простите, а причем тут js? В php и js я тоже за camelCase, но как это связано?