Comments 20
В Kohana вообще-то используется MVC. Формировать HTML-код в файле класса, реализующего логику — плохая практика.
Ну мне показалось нецелесообразным делать View для одной строчки подключения скрипта.
А Ulogin::factory()->render(), естественно должен вызываться из View. Я показал просто единый пример вызова и обработки
А Ulogin::factory()->render(), естественно должен вызываться из View. Я показал просто единый пример вызова и обработки
Вот так, строчка за строчкой, и вырастают монструозные поделки, на которые и смотреть страшно. Пишите сразу правильно, чтобы не пришлось потом переписывать ваш болото-код. А если вас и не смущает данная перспектива, не нужно хотя бы этому учить других.
Кроме того, вы используете фреймворк, стандарты которого документированы. И даже есть пример в стандартной поставке, чтобы не было желания писать неправильно. Пренебрегать данными стандартами категорически нельзя, тем более новичкам.
К сожалению фреймворк очень плохо задокументирован.
Не настолько, чтобы не заметить в нем наличие MVC )
Это видно без документации)
Но когда я изучал этот фреймворк, документации было чуть больше чем ничего, все вещи приходилось выуживать в инете по кусочкам.
К счастью предпочитаю в большинстве проектов юзать симфони, хотя, когда нужно быстро сколотить небольшое приложение Kohana. Хочу попробовать silex для очень маленьких скриптов.
Но когда я изучал этот фреймворк, документации было чуть больше чем ничего, все вещи приходилось выуживать в инете по кусочкам.
К счастью предпочитаю в большинстве проектов юзать симфони, хотя, когда нужно быстро сколотить небольшое приложение Kohana. Хочу попробовать silex для очень маленьких скриптов.
if ($this->config['type'] == 'window')
return '<a href="#" id="uLogin"><img src="http://ulogin.ru/img/button.png" width=187 height=30 alt="МультиВход"/></a><script src="http://ulogin.ru/js/widget.js?'.$params.'"></script>';
else
return '<div id="uLogin"></div><script src="http://ulogin.ru/js/widget.js?'.$params.'"></script>';Там не только скрипт, есть еще ссылка и href="#" — это довольно криво, в таких случаях лучше использовать span. Я не могу ее поменять для своего сайта из-за требований ulogin? Если так, то это еще можно было бы назвать каким-то аргументом.
В статье есть спорные моменты, этот не единственный, но в целом, если вынесите html в шаблон хотя бы ради соблюдения стандартов Kohana, то пойдет как мануал новичкам.
Ничего с собой не могу поделать. Читаю название этого фреймворка как «Какаха» и всё тут.
PomanoB, значительно лучше сделать ULogin как модуль коханы.
Очень приятно, что про Kohana на Хабре все еще пишут :)
Теперь немного критики, не факт, что объективной ;). Как-то все это выглядит, ммм, неООПшно, чтоли.
1. Зачем использовать file_get_contents(), когда есть Request::factory()? Он ведь и для внешних запросов может использоваться.
2. Заполнение данных пользователя после логина выглядит очень коряво. ORM предлагает различные плюшки типа ->values(), а также фильтрацию данных при передаче значений в модель.
3. Я для своего модуля аутентификации делал отдельные драйверы для каждого провайдера. Они уже сами разбирали входящие данные, зная о нужных полях. Соответственно в конфиге уже не придется хранить провайдерозависимые данные. Правда, в моем случае свободы у эти провайдеров было побольше (разные УРЛы, ключи и т.д.), но не суть. Потенциально возможностей для расширения больше получается (опять же, я не в курсе работы с uLogin, поэтому могу ошибаться)
4. Вьюшки уж очень замусоренные. Анализ конфигов вынесите в контроллер, и передавайте в шаблон уже готовые значения
Что касается статьи в целом.
1. Добавьте наверное в начале общее описание проблемы. Т.е. что есть в начале (аутентификация через Auth + желание прикрутить uLogin), чего не хватает и какие проблемы надо решить. А то Вы сразу в дебри кода ныряете, и непонятно, а чего собственно в процессе кодинга мы хотим добиться.
2. А Вы как-то решаете проблему дублирования пользователей? Имеется в виду вход одним юзером через разных провайдеров. Опять же, не знаю, помогает ли в этом как-то uLogin… Просто судя по таблице в БД связь 1-к-1 получается.
3. Было бы неплохо выложить код модуля на Github. И качать не придется, чтобы посмотреть отдельные куски.
Теперь немного критики, не факт, что объективной ;). Как-то все это выглядит, ммм, неООПшно, чтоли.
1. Зачем использовать file_get_contents(), когда есть Request::factory()? Он ведь и для внешних запросов может использоваться.
2. Заполнение данных пользователя после логина выглядит очень коряво. ORM предлагает различные плюшки типа ->values(), а также фильтрацию данных при передаче значений в модель.
3. Я для своего модуля аутентификации делал отдельные драйверы для каждого провайдера. Они уже сами разбирали входящие данные, зная о нужных полях. Соответственно в конфиге уже не придется хранить провайдерозависимые данные. Правда, в моем случае свободы у эти провайдеров было побольше (разные УРЛы, ключи и т.д.), но не суть. Потенциально возможностей для расширения больше получается (опять же, я не в курсе работы с uLogin, поэтому могу ошибаться)
4. Вьюшки уж очень замусоренные. Анализ конфигов вынесите в контроллер, и передавайте в шаблон уже готовые значения
Что касается статьи в целом.
1. Добавьте наверное в начале общее описание проблемы. Т.е. что есть в начале (аутентификация через Auth + желание прикрутить uLogin), чего не хватает и какие проблемы надо решить. А то Вы сразу в дебри кода ныряете, и непонятно, а чего собственно в процессе кодинга мы хотим добиться.
2. А Вы как-то решаете проблему дублирования пользователей? Имеется в виду вход одним юзером через разных провайдеров. Опять же, не знаю, помогает ли в этом как-то uLogin… Просто судя по таблице в БД связь 1-к-1 получается.
3. Было бы неплохо выложить код модуля на Github. И качать не придется, чтобы посмотреть отдельные куски.
1, 2, 4. Спасибо, исправил
3. Тут вся прелесть uLogin'а в том, что если не будет полей, помеченных как обязательные, он запросит их у пользователя. А нам на вход попадают все обязательные поля
1. Добавил
2. Ну тут уж ничего не сделать, если хочет заходить через разных, у них identity будут разные. Может только ники совпадут, и валидацию не пройдёт пользователь
3. Сделал
3. Тут вся прелесть uLogin'а в том, что если не будет полей, помеченных как обязательные, он запросит их у пользователя. А нам на вход попадают все обязательные поля
1. Добавил
2. Ну тут уж ничего не сделать, если хочет заходить через разных, у них identity будут разные. Может только ники совпадут, и валидацию не пройдёт пользователь
3. Сделал
Выложите модуль на GitHub чтобы можно было отправлять вам пулл реквесты и отписываться о ошибках, таким образом модуль достаточно быстро может видоизмениться в лучшею сторону.
Касательно модуля, я бы создал отдельную таблицу с зависимостями, это позволило бы привязать одновременно акаунты из разных соц сетей, и не вспоминать каждый раз при входе на сайт через какую соц сеть я создавал акаунт.
Касательно модуля, я бы создал отдельную таблицу с зависимостями, это позволило бы привязать одновременно акаунты из разных соц сетей, и не вспоминать каждый раз при входе на сайт через какую соц сеть я создавал акаунт.
Зачем вы строите $params вручную, когда можно использовать http_build_query() либо кохановский URL::query()?
Sign up to leave a comment.
Пишем модуль uLogin для Kohana 3.2