Комментарии 108
У меня вопрос. Является ли проблемой то, что когда вызываешь Yii:app()->user->isGuest, создается новая сессия? Просто кажется нелогичным грузить сервер новыми сессиями, если даже сессионной куки не найдено в реквесте.
сессия по идее должна запускаться для всех пользователей, случаи когда это не так довольно редки.
С таким подходом тысяча анонимусов вынесут Ваш сайт.
Раздавать сессии направо и налево — очень расточительное занятие для сервера.
Раздавать сессии направо и налево — очень расточительное занятие для сервера.
Та в мемкеш или на рамдиск можно положить, если тормозит. В таком режиме, сессии работают довольно шустро.
Это само собой, но только с подходом «у меня бесконечно много памяти».
Пустые сесии весят не так много. Если чистить отпавшие, то памяти хватит, разве что речь о виртуальном хостинге.
Гостевые Сессии (пустые) в файлах весят ровно 0 байт. в Мемкэше не проверяли.
К Сожалению, такое же поведение (при проверке на Гостя) и в Zend Framework — создается пустая сессия и уходит Куки.
К Сожалению, такое же поведение (при проверке на Гостя) и в Zend Framework — создается пустая сессия и уходит Куки.
наличие сессии делает невозможным кешировать сайт жестко для всех анонов
Далеко не всегда.
Не наличие сессии, а наличие каких-то данных в сесии. Если вы имеете в виду возможность отделять анонимов от неанонимов на уровне nginx, то имеет смысл поставить отдельную куку для неанонимов. Сессию то можно и через GET передать, в таком случае, юзер вроде и залогинен, а получит страницу из кэша.
В прочем, кэшировать всю страницу целиком имеет смысл довольно редко, эффективнее кэшировать блоками и собирать из через ssi (и на уровне того, кто выдает ssi решать залогиненый юзер, или нет).
В прочем, кэшировать всю страницу целиком имеет смысл довольно редко, эффективнее кэшировать блоками и собирать из через ssi (и на уровне того, кто выдает ssi решать залогиненый юзер, или нет).
Требования разными бывают, как и способы хранения сессий.
Почему до сих пор пол интернета работает и не знает об этой проблеме?
О чем вообще Ваш комментарий? То, что люди не знают реальной проблемы медленной работы их сайта, делает их хорошими разработчиками?
Если Ваши сессии лежат на харде, то это сущий ад, и об этом известно уже всем и давно. Поэтому зачастую самым логичным решением будет грузить сессии в память (memcached). Скорость круто возрастет, но теперь встает другая проблема — расходуется память. И если при 10 человек на это можно спокойно закрыть глаза, то при 10к человек это не кажется такой уж мелочью.
Если Ваши сессии лежат на харде, то это сущий ад, и об этом известно уже всем и давно. Поэтому зачастую самым логичным решением будет грузить сессии в память (memcached). Скорость круто возрастет, но теперь встает другая проблема — расходуется память. И если при 10 человек на это можно спокойно закрыть глаза, то при 10к человек это не кажется такой уж мелочью.
Ну большую часть времени пользователь ждет отработки фронтэнда а не сервера. В случае же если у вас 10К людей онлайн активно использующие сессии, то помимо сессий у вас будет еще масса приключений, и для этого архитектуру нужно основательно продумывать.
Само собой. Ну раз уж затронули вопрос с сессиями, я справедливо заметил, что при грамотном использовании сессии (или не использовании вообще), на них можно неплохо сэкономить памяти.
ORM-мы как правило жрут на порядок больше, если в сессиях действительно не хранится ничего больше сообщений и токенов для авторизации, то особо много они не жрут.
В этом случае хранимые процедуры — наше все.
Да, если хранить токены, все будет неплохо. Но зачастую ресурсы хранят там вообще все профили.
Да, если хранить токены, все будет неплохо. Но зачастую ресурсы хранят там вообще все профили.
По какой причине?
хранимые процедуры это конечно круто, но много дороже в разработке/поддержке. Использовать их стоит либо для узких мест (пересчет листьем дерева при хранении в nested sets например). Да и можно процедурами формировать вьюшки таблиц и с ними уже работать из ORM. хранимые процедуры не панацея.
эм… как это, хранить все профили в сессии? Зачем? Как? И для анонимных пользователей? В этом ровным счетом нету никакого смысла.
эм… как это, хранить все профили в сессии? Зачем? Как? И для анонимных пользователей? В этом ровным счетом нету никакого смысла.
При грамотном проектировании ничего на них не сэкономишь. А при не грамотном лучше оптимизировать запросы к БД. Потому как чаще всего там кроются все проблемы.
А не нужно в сессии пихать войну и мир. Отводим планку расхода памяти. К примеру, на гостя не более 1кб, на залогиненого юзера до 10 кб. 10к гостей даем нам ~10МБ. Это не много даже для VDS-ки.
Необходимость в таких извратах возникает у очень небольшого числа выстрелевших проектов. Весь highload, по моему, один сплошной изврат, причём на каждый проект изврат на свой лад и с другими проектами не особо работает.
Я о том, что нет никакой проблемы — на массе движков сессии создаются автоматом и не являются бутылочным горлышком.
Файловая система также кешируется — это не проблема. До тех пор пока проект живёт на одной машине этот кеш работает исключительно великолепно.
10к человек в день — это ещё даже не нагрузка. В среднем 7 человек в минуту и при учёте разности плотности посещений в 3 раза — в пике один человек в три секунды. Здесь ещё огромный запас на то, чтобы количество хитов на каждого человека было порядка полусотни на не самом дорогом хостинге.
10к человек, которые ломятся на сайт одновременно? Это уже совсем другой разговор и другие технологии. 99,9% сайтов не испытывают подобной нагрузки.
Файловая система также кешируется — это не проблема. До тех пор пока проект живёт на одной машине этот кеш работает исключительно великолепно.
10к человек в день — это ещё даже не нагрузка. В среднем 7 человек в минуту и при учёте разности плотности посещений в 3 раза — в пике один человек в три секунды. Здесь ещё огромный запас на то, чтобы количество хитов на каждого человека было порядка полусотни на не самом дорогом хостинге.
10к человек, которые ломятся на сайт одновременно? Это уже совсем другой разговор и другие технологии. 99,9% сайтов не испытывают подобной нагрузки.
Я бы добавил что те которые испытывают имеют не один сервер за пазухой. И нагрузка между этими серверами балансируется. А значит можно вернутся к разговору о том что сессии это вообще не проблема. Если, конечно, в них не хранить том «Война и Мир» ))
Я бы добавил, что сессии в большинстве случае вообще не нужны — их используют для хранения идентификатора пользователя, поскольку фреймворки стандартно альтернатив не предлагают и мало кому надо заморачиваться. Но видел и когда в сессии хранился профиль пользователя вместе со всеми его доступами (ага, он так «кешировался»!), что являло собой конкретную дыру в безопасности — забаненный пользователь спокойно себе продолжал пользоваться своими привелегиями, пока сессия не истекала. В общем, выводы по поводу сессий достаточно неоднозначны, а RESTfull рулит ))
Он весь забит сессиями, ему просто некогда об этом знать ))
Нелогичным оно кажется с точки зрения технических специалистов которые пытаются это мотивировать тем, что сессии пишутся на диск и можно упереться в I/O по диску. Однако бизнес, для которого собственно мы и пишем наши приложения, хочет разных свистелок-пирделок потому что им нужны цифры для анализа поведения пользователя.
Поэтому это не проблема, это практическая необходимость. Поэтому сессии выносим в тот же redis благо такой hendler имеется в готовом виде. Короткое время для гостей в самом redis и сброс таких сессий в СУБД решает вопрос между производительностью (технический аспект) и сбором статистики (бизнес).
Поэтому это не проблема, это практическая необходимость. Поэтому сессии выносим в тот же redis благо такой hendler имеется в готовом виде. Короткое время для гостей в самом redis и сброс таких сессий в СУБД решает вопрос между производительностью (технический аспект) и сбором статистики (бизнес).
Ех… этому бы фреймворку еще бы шаблонизатор повменяемей =)
Blitz наш выбор. Я конечно не копался в подсистеме шаблонов Yii, но сам принцип работы несколько усложнен.
Ниразу, дико простая система, говорю как человек который копался и в системе шаблонов Yii и в twig.
у меня проще. есть единый шаблон страницы, в нем происходит генерация контента в зависимости от вызываемового контроллера, в нужных местах страницы я могу вызвать нужный мне вьюв и тот уже вытащит данные из модели. при этом мне не надо заморвчиваться с layout как в yii, сами шаблоны получаются прозрачней, гибче и компактней и в них полностью отсутствует php код.
В твиге тоже нет понятия лэйаута. Но вот это «есть единый шаблон страницы, в нем происходит генерация контента в зависимости от вызываемового контроллера» я совсем не понял.
Посмотрю я на вас если на ЭТОМ вам придется писать большое приложение, с командой из нескольких человек, хотя бы один из которых просто верстальщик, который хочет только верстать и разве что переменные подставлять.
без проблем прикрутил к нему Twig, со всеми его фишками.
Я думаю, что если вы захотите, то в течении 10 дней напишете свой под ваши нужды. У меня он вышел в 400 строк, думаю верстальщикам данный шаблонизатор может понравиться. Система для шаблонов, сделанная в Yii просто замечательна особенно с директорией /protected/runtime/view.
Вот проект, очень простенький. Все естественно компилируется, поэтому скорость высокая.
github.com/wartur/yii-thplike/blob/master/ThpViewRenderer.php
Вот проект, очень простенький. Все естественно компилируется, поэтому скорость высокая.
github.com/wartur/yii-thplike/blob/master/ThpViewRenderer.php
Я довольно давно пользовался Yii, и мне интересно, зачем там этот класс CHtml? Прямое предназначение я конечно понимаю, но с какого перепугу оно может понадобиться?
Как минимум будет автоматически проставлен csrf-token. А еще ActiveForm и куча плюшек.
Все больше и больше мне нравится Yii.
Все больше и больше мне нравится Yii.
Попробуйте Symfony 2, в плане форм это мечта. В остальном же, тоже лучше, но это уже вопрос очень субъективный. Все жду вторую ветку Yii что бы сравнить.
Не надо пожалуйста! Я тоже сейчас считаю себя адептом симфони, но, пожалуйста, не надо в блогах других фв предлагать попробовать свой фреймворк, это ничем хорошим не заканчивается
Недавно пост был про формы. Автор даже код побоялся привести целиком потому как «на тучу экранов». Похоже, заминусовали настолько, что пост был убран. В Symfony2 очень гибкие формы, но по-моему, слишком многословный синтаксис.
Ну есть разные случаи. Обработка форм в симфони действительно немного объемнее, даже местами не немного, но некоторые плюшки в Yii можно сделать только с очень большими костылями. Мне этот фреймворк нравился еще с версии 1.0, и то, что в большей части проектов форм билдер вообще не используется как бы намекает.
Симфони сложнее, причем на порядок. То что в Yii делается через магию и прочее, в симфони делается через рефлексии, все довольно сложно но очень гибко. Помню когда на работе заставили переходить с Yii я плевался еще месяц, но сейчас я с печалью поддерживаю старые проекты на Yii.
Поторопитесь уже с 2.0, хоть сообщите на каком там все этапе, ибо страсть как любопытно.
Симфони сложнее, причем на порядок. То что в Yii делается через магию и прочее, в симфони делается через рефлексии, все довольно сложно но очень гибко. Помню когда на работе заставили переходить с Yii я плевался еще месяц, но сейчас я с печалью поддерживаю старые проекты на Yii.
Поторопитесь уже с 2.0, хоть сообщите на каком там все этапе, ибо страсть как любопытно.
Todos BEFORE Alpha Web controller and application, Request/Response classes, I18N, URL manager, session, asset manager, client script, auth/RBAC, HTML/form helpers, webapp command.
Todos AFTER Alpha Gii, commonly used console commands, advanced widgets (e.g. grid view), API documentation generator.
В этих двух пунктах абстрактно заключены почти все нововведения фреймворка (во всяком случае те, о реализации которых не особо известно). И это стоит там уже довольно давно. Выглядит довольно грустно. Состояние разработки вообще не известно. Самое значительное изменение освященное на форуме о изменениях в AR, оно по настоящему радует, но все же с тех пор прошло уже пару месяцев.
Вобщем, вы не обязаны конечно говорить на какой стадии по каждому из пунктов находится разработка, это только мое любопытство, но я жду ветку 2.0 чуть меньше года, по сути с тех пор как ее официально анонсировали, считайте это просто нетерпением.
Вобщем, вы не обязаны конечно говорить на какой стадии по каждому из пунктов находится разработка, это только мое любопытство, но я жду ветку 2.0 чуть меньше года, по сути с тех пор как ее официально анонсировали, считайте это просто нетерпением.
DI решили не делать?
CTRL+Enter наше все…
Хотел добавить, что вероятно Вы еще не раскрыли всю мощь этого хэлпера.
Почитайте документацию.
Хотел добавить, что вероятно Вы еще не раскрыли всю мощь этого хэлпера.
Почитайте документацию.
Пример:
И ещё:
Unobtrusive JS голосование за пост:
<!-- вот это: -->
<p><?php echo CHtml::link('Ссылка на что-нибудь',array('something/action')); ?>.<p>
<!-- куда короче и приятнее, чем это: -->
<p><a href="<?php echo $this->createUrl('something/action'); ?>">Ссылка на что-нибудь.</a>.<p>
И ещё:
<!-- можно конечно ручками, но упрощает жизнь это очень сильно :-) -->
<?php echo CHtml::activeDropDownList(
$model,'city_id',
CHtml::listData(City::model()->findAll(),'id','title')
); ?>
Unobtrusive JS голосование за пост:
<?php echo CHtml::ajaxLink(
'Проголосовать!', // текст ссылкы для голосования за пост
array('post/vote','id'=>$model->id), // роут голосования
array('replace'=>'#post-rating-'.$model->id) // покажем новое значение рейтинга
); ?>
<p><?php echo CHtml::link('Ссылка на что-нибудь', array('something/action'), array('class'=>'btn btn-warning', 'title'='Заголовок ссылки'); ?></p>
против
<p><a href="{{ path('somethong/action') }}" class="btn btn-warning" title="Заголовок ссылки">Ссылка на что-нибудь</a></p>
Просто представьте как весело натягивать через CHtml верстку, как вас будет любить верстальщик и наоборот. Автокамплита при заполнении параметров нету, некоторые атрибуты игнорируются. Да, очень редко, но этот класс бывает полезным. В случае с теми же дропдаунами, но по большей части формировать HTML из PHP это немного дико. Мне больше нравится подход когда все те же дропдауны запихнуты где-то в шаблоне а функция createDropDown($values, $options) просто рендрит шаблон элемента. Профит тут огромный — захотел, переопределил шаблоны и уже готова поддержка скажем Bootstrap или любого другого CSS фреймворка.
Просто представьте как весело натягивать…
… формировать HTML из PHP это немного дико.
Мне больше нравится подход…
Ваш комментарий — таки вкусовщина. :-) Обсуждать это не стоит, как мне кажется — сто тысяч раз было «перетёрто» где только можно.
Никаких проблем для верстальщика! 'htmlOptions' => array('class' => 'myClass') и всё хорошо.
Спасибо за разъяснения, кстати почему бы не использовать шорттеги для эха?
кстати почему бы не использовать шорттеги для эха?
Можно и использовать, а можно и нет. Кому как нравится. :)
Безопасно только для 5.4+.
НЛО прилетело и опубликовало эту надпись здесь
PHP_INI_ALL in PHP 4.0.0. PHP_INI_PERDIR in PHP < 5.3.0
То есть в PHP 4 можно было менять. Потом до 5.3.0 только через php.ini, .htaccess и httpd.conf. Начиная с 5.3.0 опять можно.
Yii нормально работает начиная с 5.1. Не хотелось бы это ломать.
НЛО прилетело и опубликовало эту надпись здесь
Зная про такую удобную возможность в другом фреймворке (не холивара ради), спрошу — а можно ли, используя CHtml::link, сделать, чтобы вместо текста ссылки был какой-то html? Например контейнер, какая-то картинка и блок текста (.container>(img+.text)). Только чтобы в первый параметр этот html не запихивать. И если нет, то может кто-то знает в каком php-фреймворке можно такое найти?
Ну как же нет, когда прямо в том месте где вы привели красным по белому написано
@param string $text link body. It will NOT be HTML-encoded. Therefore you can pass in HTML code such as an image tag.
@param string $text link body. It will NOT be HTML-encoded. Therefore you can pass in HTML code such as an image tag.
> Только чтобы в первый параметр этот html не запихивать.
Может я что-то не понял? Но aTei видимо хотел ООП-шного представления элементов дерева, а там просто строкой
Может я что-то не понял? Но aTei видимо хотел ООП-шного представления элементов дерева, а там просто строкой
А каков синтаксис этой штуки? Интересно.
Для варианта с текстом как у CHtml::link:
Для варианта с html внутри:
pastebin.com/iA2hjVSv
= link_to 'Новости', '/news'
Для варианта с html внутри:
= link_to photo.large.url do
.container
= image_tag photo.thumbnail.url
.text Hello Worldpastebin.com/iA2hjVSv
Не, у нас нет обёртки над DOM и как-то не особо хочется: повысит количество штук, которые придётся изучать.
А в этом то какой смысл? Мне всегда казалось что весь смысл в отделении логики от представление с упрощением каждого из компонентов для разработки и поддержки. А это, уж извините, месиво.
Чем-то на хамл похоже, а его имплементация на пыхе есть
А смысл у этой штуки есть? Написано «Markup should be beautiful.» но вижу я прямо противоположное.
Ну это в общем то как и с пхп-фреймворками. Пока не изучишь — будешь плеваться, а когда изучишь — сможешь гораздо быстрей писать шаблоны. Другое дело, что я не верстаю настолько быстро, чтобы это мне сильно помогло… Некоторые еще говорят, что читаемость лучше, но тут уже похоже дело вкуса, меня хтмл устраивает пока
Все эти псевдоразметки как по мне излишнее, хорошая IDE с хорошим автокомплитом позволит реализовать разметку страницы за достаточно небольшой промежуток времени. В случае с CSS помогут всякие LESS или SASS для организации кода. Единственный шаблонизатор который мне понравился и который реально помогает сэкономить время это Twig, очень приятная штука, но не без минусов, хоть они и незначительны пере плюсами. В остальном же нравятся PHP вставки.
На самом деле очень мощная вещь, особенно с учетом того как она с аяксом дружит и формами.
для форм писал свой лесапед на основе штатного форм билдера, собственно как раз избавлял его от зависимости от CActiveForm и CHtml.
У меня уже давно свой есть, на гитхабе лежит, тока пока зависит, но зато проверяет все формы по аяксу и еще очень много плюшек имеет.
а ссылочкой не поделитесь?
Пожалуйста Изначально оно было совсем другим, пока я не рассказал о моем подходе Славе(mc_bear). Тот сделал свою версию основанную на моем подходе, но дополненную. А все улучшения и дополнения висят на мне. Сейчас я работаю над более простой версией с другим названием ExForm, которая не будет зависеть от CActiveForm и CForm, и много чего еще… И работать она будет быстрее и в то же время предоставлять больше возможностей, но в то же время и меньше, так как часть возможностей придется убрать.
Самый полезный метод из него CHtml::listData :)
Чуток не по теме, но все же.
В CActiveRecord в методе save вызывается afterSave до того, как установлен флаг isNewRecord=false. Поэтому в обработчике afterSave невозможно получить записи для related полей. Оно просто проверяет флаг isNewRecord и возвращает null для них, хотя для записи уже есть праймари ключ. Возможно это для чего-то сделано. Просто получается что вызов происходит не совсем after этого самого save.
В CActiveRecord в методе save вызывается afterSave до того, как установлен флаг isNewRecord=false. Поэтому в обработчике afterSave невозможно получить записи для related полей. Оно просто проверяет флаг isNewRecord и возвращает null для них, хотя для записи уже есть праймари ключ. Возможно это для чего-то сделано. Просто получается что вызов происходит не совсем after этого самого save.
Ну логика тут есть: после сохранение в базу у вас объект не должен поменять состояния — вы его мгновением назад создали, и он все еще новый. Допустим у вас в afterFind для новых записей должна быть одно дейтвие, а для обновленных — другое. Если менять флаг перед вызовом события, то у вас все записи после afterFind будут проходить как обновленные, а не как добавленные. Как-то так.
Да и потом где гарантии что вы уже создали все связанные объекты?
Да и потом где гарантии что вы уже создали все связанные объекты?
Залез еще раз в код, посмотреть поточнее.
Метод называется insert. Внутри него после удачного собственно инсерта и проставления праймари ключа в модели вызывается вот что
А так да, afterSave вызывается и для insert, и для update. Но, мне кажется, можно параметром передавать вызываем мы его после добавления записи или обновления.
Это да, но проблема скорее архитектуры. Если я связные записи еще не сохранил, то и так вернется null записей.
Но в целом да, я уже пораскинул мозгами и пришел к выводу, что странно обращаться к связным таблицам, когда мы только-только сохранили главную запись.
Метод называется insert. Внутри него после удачного собственно инсерта и проставления праймари ключа в модели вызывается вот что
$this->afterSave();
$this->setIsNewRecord(false);
$this->setScenario('update');
А так да, afterSave вызывается и для insert, и для update. Но, мне кажется, можно параметром передавать вызываем мы его после добавления записи или обновления.
Да и потом где гарантии что вы уже создали все связанные объекты?
Это да, но проблема скорее архитектуры. Если я связные записи еще не сохранил, то и так вернется null записей.
Но в целом да, я уже пораскинул мозгами и пришел к выводу, что странно обращаться к связным таблицам, когда мы только-только сохранили главную запись.
Но, мне кажется, можно параметром передавать вызываем мы его после добавления записи или обновления.
Можно узнать какое действие происходит используя $this->getScenario(), также get\set сценариев позволяет создавать массу кейсов для управления данными.
А не обещали сделать в валидации уникальность по нескольким полям?
А что это?
Например уникальность по email и phone одновременно. Есть екстеншн, но штука настолько популярная, что хотелось бы ее в ядре.
А, понял. Не сильно, видно, популярная штука, раз её до сих пор нет в трекере.
Это больно уж специфичное требование. Да и свой валидатор такого рода написать по времени минут 20.
Рад исключению сценариваев в правилах валидации, очень нехватало. Спасибо!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Yii 1.1.11