3. Вот именно, что это школа, и тут надо базис преподать. Зная, как решить задачу абстрактно, на уровне алгоритмов, Вы ее решите на любом языке программирования. И не потребуется погружать школьников в глубины языкознания. Тут надо научить головой пользоваться, а не функции заучивать.
Этот «мертвый» груз знаний Вы (я на это надеюсь) применяете каждый раз, когда что-то программируете. Это необходимый базис, просто в дальнейшем Вы его оборачиваете в термины конкретного языка.
А вот у изученного (интересно, насколько он будет изучен?) ЯП есть очень высокие шансы стать тем самым мертвым грузом.
Основы программирования — это как раз и есть алгоритмы. К сожалению, для применения их на живых компьютерах потребуется изучать собственно ЯП. ИМХО, в школе это лишнее. Максимум — использовать программы для рисования блок-схем или интерактивные обучающие игрушки.
Дык о чем и речь — зачем программировать-то? Надо сперва научиться мыслить логически. А потом уже, если кому потребуется, — дополнительный факультатив по информатике.
Иначе такими темпами юристы потребуют изучение всей базы законов, кодексов и т.д., вслед за ними активизируются экономисты, строители и кадровики. Чуть позже заявят о себе военные, и мы будем отправлять детей на военные сборы в летние каникулы ;)
… по крайней мере, данный фокус был чуть более оригинальным, чем обычная символическая игра в шахматы, которой Смерть всегда побаивался, поскольку никак не мог запомнить, как ходит конь.
Тут проблема заключается в том, что это будет рассматриваться как один проект. Со всеми вытекающими (к примеру, автокомплит может не работать из-за коллизий). Сам долго привыкал, что нельзя иметь несколько открытых проектов в одном окне, как в NB.
Очень приятно, что про Kohana на Хабре все еще пишут :)
Теперь немного критики, не факт, что объективной ;). Как-то все это выглядит, ммм, неООПшно, чтоли.
1. Зачем использовать file_get_contents(), когда есть Request::factory()? Он ведь и для внешних запросов может использоваться.
2. Заполнение данных пользователя после логина выглядит очень коряво. ORM предлагает различные плюшки типа ->values(), а также фильтрацию данных при передаче значений в модель.
3. Я для своего модуля аутентификации делал отдельные драйверы для каждого провайдера. Они уже сами разбирали входящие данные, зная о нужных полях. Соответственно в конфиге уже не придется хранить провайдерозависимые данные. Правда, в моем случае свободы у эти провайдеров было побольше (разные УРЛы, ключи и т.д.), но не суть. Потенциально возможностей для расширения больше получается (опять же, я не в курсе работы с uLogin, поэтому могу ошибаться)
4. Вьюшки уж очень замусоренные. Анализ конфигов вынесите в контроллер, и передавайте в шаблон уже готовые значения
Что касается статьи в целом.
1. Добавьте наверное в начале общее описание проблемы. Т.е. что есть в начале (аутентификация через Auth + желание прикрутить uLogin), чего не хватает и какие проблемы надо решить. А то Вы сразу в дебри кода ныряете, и непонятно, а чего собственно в процессе кодинга мы хотим добиться.
2. А Вы как-то решаете проблему дублирования пользователей? Имеется в виду вход одним юзером через разных провайдеров. Опять же, не знаю, помогает ли в этом как-то uLogin… Просто судя по таблице в БД связь 1-к-1 получается.
3. Было бы неплохо выложить код модуля на Github. И качать не придется, чтобы посмотреть отдельные куски.
2. А я про всякие там паттерны что-то говорил? :)
3. Вот именно, что это школа, и тут надо базис преподать. Зная, как решить задачу абстрактно, на уровне алгоритмов, Вы ее решите на любом языке программирования. И не потребуется погружать школьников в глубины языкознания. Тут надо научить головой пользоваться, а не функции заучивать.
А вот у изученного (интересно, насколько он будет изучен?) ЯП есть очень высокие шансы стать тем самым мертвым грузом.
Иначе такими темпами юристы потребуют изучение всей базы законов, кодексов и т.д., вслед за ними активизируются экономисты, строители и кадровики. Чуть позже заявят о себе военные, и мы будем отправлять детей на военные сборы в летние каникулы ;)
В конце концов, пешеходам необязательно учиться на права, чтобы выучить правила ПДД.
Теперь немного критики, не факт, что объективной ;). Как-то все это выглядит, ммм, неООПшно, чтоли.
1. Зачем использовать file_get_contents(), когда есть Request::factory()? Он ведь и для внешних запросов может использоваться.
2. Заполнение данных пользователя после логина выглядит очень коряво. ORM предлагает различные плюшки типа ->values(), а также фильтрацию данных при передаче значений в модель.
3. Я для своего модуля аутентификации делал отдельные драйверы для каждого провайдера. Они уже сами разбирали входящие данные, зная о нужных полях. Соответственно в конфиге уже не придется хранить провайдерозависимые данные. Правда, в моем случае свободы у эти провайдеров было побольше (разные УРЛы, ключи и т.д.), но не суть. Потенциально возможностей для расширения больше получается (опять же, я не в курсе работы с uLogin, поэтому могу ошибаться)
4. Вьюшки уж очень замусоренные. Анализ конфигов вынесите в контроллер, и передавайте в шаблон уже готовые значения
Что касается статьи в целом.
1. Добавьте наверное в начале общее описание проблемы. Т.е. что есть в начале (аутентификация через Auth + желание прикрутить uLogin), чего не хватает и какие проблемы надо решить. А то Вы сразу в дебри кода ныряете, и непонятно, а чего собственно в процессе кодинга мы хотим добиться.
2. А Вы как-то решаете проблему дублирования пользователей? Имеется в виду вход одним юзером через разных провайдеров. Опять же, не знаю, помогает ли в этом как-то uLogin… Просто судя по таблице в БД связь 1-к-1 получается.
3. Было бы неплохо выложить код модуля на Github. И качать не придется, чтобы посмотреть отдельные куски.