FanatPHP: мне нравится, когда от них идут аргументы типа "потому что на смарти может верстать дизайнер или верстальщик, которому нельзя иметь доступ к коду, или он вообще не секёт в программировании".
Отсюда вопрос, на который они ответить не могут: "откуда дизайнер/верстальщик не секущий в программировании будет знать, какие условия и где их прописывать, если он не имеет доступа к коду или вообще не понимает в программировании."
Дмитрий: долларов, само собой.
Хотя, если авто будет сам в свободное время заниматься дизайном, райтингом и программированием, то лет за 5 он может и сделает что-то близкое по функционалу и наполнению, зато почти бесплатно.
А как-же с дополнительными параметрами? Может лучше сразу так:
$fucn = $_GET['act'];
$params = $_GET['params'];
if(function_exists($func)) {
$func($params);
}
? Ведь так можно будет не только phpinfo выполнить, но и eval, что намного удобнее. О людях думать надо!
И само собой, error_reporting нужно выключать, ведь иначе при пустом $_GET['act'] поедет вёрстка, что нам совершенно не нужно!
Алексей Яхненко: экшн формы просто вызывает различные функции модели, в зависимости от состояния окружения, так сказать. Вас же не смущает, что /blogs/add, мало того, что рисует форму, так ещё и данные для неё загружает из $model->getByID($id)?
> ну и ты соответственно в saveAction разбираешь че там пришло из $_POST.
А в случае ошибок в валидации пришедших данных - обратный редирект на actionAdd()?
Или выводом формы будут заниматься и actionSave() и actionAdd()?
Уж лучше в actionAdd() добавить, что то-то вроде:
if ($_SERVER['REQUEST_METHOD'] == 'POST') {
try {
$myModel->fill($_POST);
$myModel->save();
} catch (Exception $e) {
// обрабатываем сообщение об ошибках
}
}
Причём в fill() ещё вызываем метод валидации модели, складывающий все ощибки в массив и выплёвывающий эксепшеном после проверке всех пришедших данных.
Во мне он тоже больше всего нравится.
При этом "content" можно вообще хранить в другой таблице или БД, что, как мне кажется, благоприятно отразится на общей производительности.
> расшариваете между машинами
расшаривается сам код? и все правят одни и те же файлы без VCS?
Суицидальный метод.
Идеальный вариант уже тут выше описывали. У каждого разработчика свой сервер (vagrant, denwer, просто виртуалка, или всё прямо на рабочей машине - не суть важно), на котором он ведёт разработку и всё проверяет. Потом, когда он уже вроде-как выполнил задачу - он проталкивает её в отдельную ветку, потом сливает с другими разработками и проталкивает свои изменения в общую ветку Test, которая показывается на общем тестовом серваке, там его смотрят, оценивают, если всё хорошо - то всё это ещё раз проталкиватся на pre-production сервер, который ПОЛНОСТЬЮ идентичен production. Там это всё ещё раз проверяется и если всё ОК - спокойно заливается в продакшн в любое удобное время.
Все остальные варианты работы - суицид и самовставляние палок в колёса.
И ещё, всё-же, Монго или Редис? Редис может держать часть данных в памяти, а если его перенести на отдельный сервак, ну или просто памяти много воткнуть - то возможно и все данные. В целом, можно и файлы с БД Mongo держать на tmpfs, но в случае ребута - они просто потеряются. Да и места Mongo ест не мало.
Антон Каракулов: в ленте скорее будет оповещение пользователей о каком-то событии. Т.е. есть например заведение "Кафе у Бобра", на него подписано 100К пользователей, и в какой-то момент администратор этого кафе создаёт событие "Гала-концерт "Еду из Магадана на Родину к корешам". Оно сохраняется в БД, получает свою страницу, а ленте у подписчиков появляется сообщение о том, что создано новое событие. Ну, потом, само собой всякие уведомления "со стены" и из "фотоальбомов" события, т.е., грубо говоря, после успешного $record->save(), выполняем $feed->push($data), который уже кладёт данные в "Кролика", тот их передаёт в какой-то скрипт (вот тут тоже момент нужно продумать, дёргать php со всем фреймворком, или просто написать cli-скрипт (php, python, golang - не суть)), а тот уже всё это записывает в Mongo. Осталось решить момент с подчисткой "лишнего" в ленте, т.е. удаление старых записей.
Пользователей пока 0. Но планируется много. А так как "падающих" проектов я уже насмотрелся, не хочется изначально наступать на грабли, потом и в поисках решения.
Время жизни ленты тоже вопрос ещё открытый. День-два - мало, месяц - возможно много.
Ещё в комментариях встречал, что советую использовать менеджеры очередей, типа RabbitMQ. Я же надеюсь, что исключительно для заполнения ленты, (PubSub) в БД, а не для хранения оной в менеджере очереди?
Кстати, как к хранению ленты отнесётся MongoDB? Ну то, что места отъест не мало - это понятно, а в плане производительности?
Кстати, там смотрю в одной таблице на разных полях разные сравнения - очень не хорошо. Приведите всё к utf8_general_ci, если проект на utf8, либо к cp1251_general_ci, если проект в windows-1251. Тоже, частично, решит проблему. Ну и на таблицах самих тоже сравнение стоит привести в порядок.
Отсюда вопрос, на который они ответить не могут: "откуда дизайнер/верстальщик не секущий в программировании будет знать, какие условия и где их прописывать, если он не имеет доступа к коду или вообще не понимает в программировании."