Читал про такой вариант, но тоже не очень подходит, так как придется все равно следить за внесением основных доменов, от которых будут уже множиться поддомены
А если же сортировки и выборки происходят? Предположим, одна из настроек приватности определяет, можно ли посылать пользователю оповещения, и надо выбрать всех пользователей, у которых эта настройка стоит в true?
Если честно, такой вариант не очень приемлем, по той причине, что я хочу пощупать именно реальное окружение, существующее в большинстве ЦОДов и прочих серверных компаниях. Во-вторых, вариант с виндой тоже не очень приемлем, потому что хочется получить знания именно по юникс-системам.
Адский шум не парит, есть места, куда можно спрятать оборудование, счета за свет тоже не особо напрягают. Как говорится, во имя благой цели никакие средства не являются тратой)
Во-первых, как я уже написал, чтобы руками пощупать то, с чем я работаю, чтобы было лучшее представление процесса со всех сторон. Я, хоть и веб-разработчик, хочу развиваться по своей специальности максимально глубоко, чтобы, случае чего, самостоятельно уметь сделать то, что мне нужно, или решить проблему.
Во-вторых, есть ряд задач, которые удобно решить именно таким способом)
Хочется именно ручками повозиться, разобраться с самой сутью того, с чем я вообще работаю. Да и, опять же, никто не запрещал ставить такую стойку на балконе или в самом дальнем углу квартиры)
Кстати, заранее рекомендую озаботиться вопросом очереди, ибо класть из проекта прямиком подобные записи в базу это будет смертельно при более-менее большой нагрузке. Для начала можно создать только табличку очереди, куда класть само событие, но обрабатывать эту очередь (для раскладки по таблицам активности и стены) должен какой-нибудь специально обученный крон или сервис. Можете, кстати, покопать в сторону инструментов вроде RabbitMQ.
Когда вы обращаетесь к статичному методу А, у него еще нет переменной $this, так как она ведет на экземпляр, только self, которая ведет на класс. Другой вопрос, почему вообще срабатывает подобная штука, а не ругается на $this)
Как вариант наиболее предпочтительный, да. Но на деле хватило бы и ручной настройки с простейшим ЧПУ (его можно направить только на ваш администраторский раздел) и хотя бы небольшое разнесение вашего функционала по классам
Все-же, если бэкэнд в таком состоянии, то имеет смысл задуматься о его рефакторинге. Как минимум, для собственного же удобства. Иначе ваш $_GET['module'] рискует превратиться во что-то вроде
$module = $_GET['module'];
$module()->init();
А последствия, думаю, даже можно не озвучивать
Первая статья описывает способ подключения к серверам OAuth, а не способ организации подобного сервера на фреймворке Yii, так что эта часть статьи по любому нужна.
Вторая статья почти полностью копирует (правда, не знаю, чья была раньше) мою же статью на подобную же тему, которую я вполне успешно внедрил на нашем проекте.
Можно, например, первую статью посвятить самому OAuth, разжевав сам процесс общения с сервером и получения токенов и прочего, а во вторую вынести что-то вроде организации API для получения контента и управления сайтом, на манер того же Graph API от фейсбука.
К сожалению, не смотря на хорошую документированность в контакте, в ней тяжело ориентироваться, гиперссылки слабо расставлены из за ограничений vk-wiki. Да и сообщество разработчиков мертвое, последние сообщения в обсуждениях датируются весной, а то и прошлым годом
