SamDark 30 июл 2012 в 15:54

Yii 1.1.11

2 мин

Yii *

+48

108

Комментарии 108

wartur 30 июл 2012 в 16:34

У меня вопрос. Является ли проблемой то, что когда вызываешь Yii:app()->user->isGuest, создается новая сессия? Просто кажется нелогичным грузить сервер новыми сессиями, если даже сессионной куки не найдено в реквесте.

Fesor 30 июл 2012 в 16:47

сессия по идее должна запускаться для всех пользователей, случаи когда это не так довольно редки.

oYASo 30 июл 2012 в 17:28

С таким подходом тысяча анонимусов вынесут Ваш сайт.
Раздавать сессии направо и налево — очень расточительное занятие для сервера.

esc 30 июл 2012 в 17:42

Та в мемкеш или на рамдиск можно положить, если тормозит. В таком режиме, сессии работают довольно шустро.

oYASo 30 июл 2012 в 17:58

Это само собой, но только с подходом «у меня бесконечно много памяти».

esc 30 июл 2012 в 18:01

Пустые сесии весят не так много. Если чистить отпавшие, то памяти хватит, разве что речь о виртуальном хостинге.

LiaDesign 31 июл 2012 в 10:04

Гостевые Сессии (пустые) в файлах весят ровно 0 байт. в Мемкэше не проверяли.
К Сожалению, такое же поведение (при проверке на Гостя) и в Zend Framework — создается пустая сессия и уходит Куки.

Fesor 31 июл 2012 в 10:30

Фактически это можно объяснить тем что почти во всех фреймворках при инициализации вызывается session_start. Вот собственно и все. При желании это дело можно отключить и дергать руками. Не вижу проблемы.

vitalets 31 июл 2012 в 11:05

Это да.
Только параметр CHttpSession.autoStart долго сбивал меня с толку, т.к. сессии все равно стартовали при первом обращении к компоненту user.

datacompboy 31 июл 2012 в 07:13

наличие сессии делает невозможным кешировать сайт жестко для всех анонов

Fesor 31 июл 2012 в 07:23

Далеко не всегда.

datacompboy 31 июл 2012 в 07:25

кеш-система должна будет уметь поднимать и разбираться с сессиями — аноны или не аноны они.

а вот просто реагировать на наличие этой куки — в разы проще.

Fesor 31 июл 2012 в 07:52

Вы про HTTP кеширование? Если сессия просто создается автоматически это не значит что страница для каждого пользователя разная.

esc 31 июл 2012 в 07:46

Не наличие сессии, а наличие каких-то данных в сесии. Если вы имеете в виду возможность отделять анонимов от неанонимов на уровне nginx, то имеет смысл поставить отдельную куку для неанонимов. Сессию то можно и через GET передать, в таком случае, юзер вроде и залогинен, а получит страницу из кэша.

В прочем, кэшировать всю страницу целиком имеет смысл довольно редко, эффективнее кэшировать блоками и собирать из через ssi (и на уровне того, кто выдает ssi решать залогиненый юзер, или нет).

Fesor 30 июл 2012 в 17:53

Требования разными бывают, как и способы хранения сессий.

BlessMaster 30 июл 2012 в 18:39

Почему до сих пор пол интернета работает и не знает об этой проблеме?

oYASo 30 июл 2012 в 19:57

О чем вообще Ваш комментарий? То, что люди не знают реальной проблемы медленной работы их сайта, делает их хорошими разработчиками?

Если Ваши сессии лежат на харде, то это сущий ад, и об этом известно уже всем и давно. Поэтому зачастую самым логичным решением будет грузить сессии в память (memcached). Скорость круто возрастет, но теперь встает другая проблема — расходуется память. И если при 10 человек на это можно спокойно закрыть глаза, то при 10к человек это не кажется такой уж мелочью.

Fesor 30 июл 2012 в 20:10

Ну большую часть времени пользователь ждет отработки фронтэнда а не сервера. В случае же если у вас 10К людей онлайн активно использующие сессии, то помимо сессий у вас будет еще масса приключений, и для этого архитектуру нужно основательно продумывать.

oYASo 30 июл 2012 в 20:47

Само собой. Ну раз уж затронули вопрос с сессиями, я справедливо заметил, что при грамотном использовании сессии (или не использовании вообще), на них можно неплохо сэкономить памяти.

Fesor 30 июл 2012 в 20:48

ORM-мы как правило жрут на порядок больше, если в сессиях действительно не хранится ничего больше сообщений и токенов для авторизации, то особо много они не жрут.

oYASo 30 июл 2012 в 20:56

В этом случае хранимые процедуры — наше все.
Да, если хранить токены, все будет неплохо. Но зачастую ресурсы хранят там вообще все профили.

SamDark 30 июл 2012 в 21:02

По какой причине?

oYASo 31 июл 2012 в 17:25

Что именно?

SamDark 31 июл 2012 в 17:51

Какова причина хранить профили в сессиях?

Fesor 30 июл 2012 в 22:58

хранимые процедуры это конечно круто, но много дороже в разработке/поддержке. Использовать их стоит либо для узких мест (пересчет листьем дерева при хранении в nested sets например). Да и можно процедурами формировать вьюшки таблиц и с ними уже работать из ORM. хранимые процедуры не панацея.

эм… как это, хранить все профили в сессии? Зачем? Как? И для анонимных пользователей? В этом ровным счетом нету никакого смысла.

suver 30 июл 2012 в 20:50

При грамотном проектировании ничего на них не сэкономишь. А при не грамотном лучше оптимизировать запросы к БД. Потому как чаще всего там кроются все проблемы.

alekciy 30 июл 2012 в 20:13

А не нужно в сессии пихать войну и мир. Отводим планку расхода памяти. К примеру, на гостя не более 1кб, на залогиненого юзера до 10 кб. 10к гостей даем нам ~10МБ. Это не много даже для VDS-ки.

oYASo 30 июл 2012 в 20:47

О том и речь, да.

SamDark 30 июл 2012 в 20:18

Необходимость в таких извратах возникает у очень небольшого числа выстрелевших проектов. Весь highload, по моему, один сплошной изврат, причём на каждый проект изврат на свой лад и с другими проектами не особо работает.

oYASo 30 июл 2012 в 20:53

Есть вещи, которые достаточно просто оптимизировать. Я говорю только об этом.

kotomyava 31 июл 2012 в 17:17

Обычно, есть масса вещей, оптимизация которых даст куда больший профит.

SamDark 31 июл 2012 в 17:51

Если просто, всегда работает и не создаёт проблем — этому место в фреймворке.

BlessMaster 31 июл 2012 в 13:49

Я о том, что нет никакой проблемы — на массе движков сессии создаются автоматом и не являются бутылочным горлышком.
Файловая система также кешируется — это не проблема. До тех пор пока проект живёт на одной машине этот кеш работает исключительно великолепно.
10к человек в день — это ещё даже не нагрузка. В среднем 7 человек в минуту и при учёте разности плотности посещений в 3 раза — в пике один человек в три секунды. Здесь ещё огромный запас на то, чтобы количество хитов на каждого человека было порядка полусотни на не самом дорогом хостинге.
10к человек, которые ломятся на сайт одновременно? Это уже совсем другой разговор и другие технологии. 99,9% сайтов не испытывают подобной нагрузки.

suver 31 июл 2012 в 21:52

Я бы добавил что те которые испытывают имеют не один сервер за пазухой. И нагрузка между этими серверами балансируется. А значит можно вернутся к разговору о том что сессии это вообще не проблема. Если, конечно, в них не хранить том «Война и Мир» ))

BlessMaster 4 авг 2012 в 22:27

Я бы добавил, что сессии в большинстве случае вообще не нужны — их используют для хранения идентификатора пользователя, поскольку фреймворки стандартно альтернатив не предлагают и мало кому надо заморачиваться. Но видел и когда в сессии хранился профиль пользователя вместе со всеми его доступами (ага, он так «кешировался»!), что являло собой конкретную дыру в безопасности — забаненный пользователь спокойно себе продолжал пользоваться своими привелегиями, пока сессия не истекала. В общем, выводы по поводу сессий достаточно неоднозначны, а RESTfull рулит ))

suver 30 июл 2012 в 20:47

Он весь забит сессиями, ему просто некогда об этом знать ))

alekciy 30 июл 2012 в 20:08

Нелогичным оно кажется с точки зрения технических специалистов которые пытаются это мотивировать тем, что сессии пишутся на диск и можно упереться в I/O по диску. Однако бизнес, для которого собственно мы и пишем наши приложения, хочет разных свистелок-пирделок потому что им нужны цифры для анализа поведения пользователя.

Поэтому это не проблема, это практическая необходимость. Поэтому сессии выносим в тот же redis благо такой hendler имеется в готовом виде. Короткое время для гостей в самом redis и сброс таких сессий в СУБД решает вопрос между производительностью (технический аспект) и сбором статистики (бизнес).

dezconnect 30 июл 2012 в 17:18

Ех… этому бы фреймворку еще бы шаблонизатор повменяемей =)

resurtm 30 июл 2012 в 17:23

1. Чем не нравятся представления на PHP?
2. Smarty, Twig, Quicky, Dwoo, Prado. Ещё были, помимо этих.

dezconnect 31 июл 2012 в 03:39

Blitz наш выбор. Я конечно не копался в подсистеме шаблонов Yii, но сам принцип работы несколько усложнен.

Fesor 31 июл 2012 в 07:01

Ниразу, дико простая система, говорю как человек который копался и в системе шаблонов Yii и в twig.

dezconnect 31 июл 2012 в 09:42

у меня проще. есть единый шаблон страницы, в нем происходит генерация контента в зависимости от вызываемового контроллера, в нужных местах страницы я могу вызвать нужный мне вьюв и тот уже вытащит данные из модели. при этом мне не надо заморвчиваться с layout как в yii, сами шаблоны получаются прозрачней, гибче и компактней и в них полностью отсутствует php код.

nikita2206 31 июл 2012 в 13:53

В твиге тоже нет понятия лэйаута. Но вот это «есть единый шаблон страницы, в нем происходит генерация контента в зависимости от вызываемового контроллера» я совсем не понял.

Fesor 31 июл 2012 в 14:34

Посмотрю я на вас если на ЭТОМ вам придется писать большое приложение, с командой из нескольких человек, хотя бы один из которых просто верстальщик, который хочет только верстать и разве что переменные подставлять.

JiLiZART 30 июл 2012 в 17:48

без проблем прикрутил к нему Twig, со всеми его фишками.

wartur 30 июл 2012 в 20:49

Я думаю, что если вы захотите, то в течении 10 дней напишете свой под ваши нужды. У меня он вышел в 400 строк, думаю верстальщикам данный шаблонизатор может понравиться. Система для шаблонов, сделанная в Yii просто замечательна особенно с директорией /protected/runtime/view.

Вот проект, очень простенький. Все естественно компилируется, поэтому скорость высокая.
github.com/wartur/yii-thplike/blob/master/ThpViewRenderer.php

dezconnect 31 июл 2012 в 03:39

Зачем свой? :) blitz наше все.

LiaDesign 31 июл 2012 в 10:08

Нужна обертка для Yii.
Сам давно ищу адекватный(хоть какой-нибудь, а не свой костыльный) ViewRenderer для Blitz… но под альтернативный фреймворк на букву Z ;)

dezconnect 31 июл 2012 в 16:47

Я свой накатал… сырой правда, но на пока устраивает )

LiaDesign 6 авг 2012 в 15:08

Я тоже «свой» накатал… но это было 3 года назад и теперь он мне «не нравится». Как-то не Z-вей.

nikita2206 30 июл 2012 в 17:36

Я довольно давно пользовался Yii, и мне интересно, зачем там этот класс CHtml? Прямое предназначение я конечно понимаю, но с какого перепугу оно может понадобиться?

miraage 30 июл 2012 в 17:41

Как минимум будет автоматически проставлен csrf-token. А еще ActiveForm и куча плюшек.
Все больше и больше мне нравится Yii.

Fesor 30 июл 2012 в 17:57

Попробуйте Symfony 2, в плане форм это мечта. В остальном же, тоже лучше, но это уже вопрос очень субъективный. Все жду вторую ветку Yii что бы сравнить.

nikita2206 30 июл 2012 в 18:05

Не надо пожалуйста! Я тоже сейчас считаю себя адептом симфони, но, пожалуйста, не надо в блогах других фв предлагать попробовать свой фреймворк, это ничем хорошим не заканчивается

SamDark 30 июл 2012 в 18:11

Недавно пост был про формы. Автор даже код побоялся привести целиком потому как «на тучу экранов». Похоже, заминусовали настолько, что пост был убран. В Symfony2 очень гибкие формы, но по-моему, слишком многословный синтаксис.

Fesor 30 июл 2012 в 19:18

Ну есть разные случаи. Обработка форм в симфони действительно немного объемнее, даже местами не немного, но некоторые плюшки в Yii можно сделать только с очень большими костылями. Мне этот фреймворк нравился еще с версии 1.0, и то, что в большей части проектов форм билдер вообще не используется как бы намекает.

Симфони сложнее, причем на порядок. То что в Yii делается через магию и прочее, в симфони делается через рефлексии, все довольно сложно но очень гибко. Помню когда на работе заставили переходить с Yii я плевался еще месяц, но сейчас я с печалью поддерживаю старые проекты на Yii.

Поторопитесь уже с 2.0, хоть сообщите на каком там все этапе, ибо страсть как любопытно.

SamDark 30 июл 2012 в 19:27

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.

Fesor 30 июл 2012 в 19:43

В этих двух пунктах абстрактно заключены почти все нововведения фреймворка (во всяком случае те, о реализации которых не особо известно). И это стоит там уже довольно давно. Выглядит довольно грустно. Состояние разработки вообще не известно. Самое значительное изменение освященное на форуме о изменениях в AR, оно по настоящему радует, но все же с тех пор прошло уже пару месяцев.

Вобщем, вы не обязаны конечно говорить на какой стадии по каждому из пунктов находится разработка, это только мое любопытство, но я жду ветку 2.0 чуть меньше года, по сути с тех пор как ее официально анонсировали, считайте это просто нетерпением.

SamDark 30 июл 2012 в 20:14

Не особо известно потому как всё это в активной работе и постоянно меняется до неузнаваемости. Как только более-менее стабилизируется, выйдет альфа.

Fesor 30 июл 2012 в 20:15

Ясно, спасибо. Будем ждать.

nikita2206 30 июл 2012 в 20:07

DI решили не делать?

SamDark 30 июл 2012 в 20:15

DI есть и в Yii 1.1. Вы про DIC?

nikita2206 30 июл 2012 в 20:21

А вижу, для компонентов. Не знал)

miraage 30 июл 2012 в 17:42

CTRL+Enter наше все…
Хотел добавить, что вероятно Вы еще не раскрыли всю мощь этого хэлпера.
Почитайте документацию.

resurtm 30 июл 2012 в 17:51

Пример:

<!-- вот это: -->
<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) // покажем новое значение рейтинга
); ?>

Fesor 30 июл 2012 в 18:04

<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 фреймворка.

resurtm 30 июл 2012 в 18:10

Просто представьте как весело натягивать…
… формировать HTML из PHP это немного дико.
Мне больше нравится подход…

Ваш комментарий — таки вкусовщина. :-) Обсуждать это не стоит, как мне кажется — сто тысяч раз было «перетёрто» где только можно.

disem 30 июл 2012 в 18:41

Никаких проблем для верстальщика! 'htmlOptions' => array('class' => 'myClass') и всё хорошо.

Fesor 30 июл 2012 в 19:12

Я не считаю это упрощением разработки.

nikita2206 30 июл 2012 в 18:07

Спасибо за разъяснения, кстати почему бы не использовать шорттеги для эха?

resurtm 30 июл 2012 в 18:11

кстати почему бы не использовать шорттеги для эха?

Можно и использовать, а можно и нет. Кому как нравится. :)

SamDark 30 июл 2012 в 18:12

Безопасно только для 5.4+.

НЛО прилетело и опубликовало эту надпись здесь

SamDark 30 июл 2012 в 18:45

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. Не хотелось бы это ломать.

НЛО прилетело и опубликовало эту надпись здесь

Fesor 30 июл 2012 в 19:45

в версии 5.3 включить шорттеги в рантайме нельзя, потому шорттеги не безопасны — мало ли на сервере они отключены. Всекое бывает.

SamDark 30 июл 2012 в 20:22

Мануал вроде говорит, что в 5.3 всё-таки можно. В 5.2 нельзя.

SamDark 30 июл 2012 в 20:23

Доля 5.2 очень большая до сих пор. Вы можете у себя в приложении использовать шорттеги, но заставлять это делать мы не будем.

aTei 30 июл 2012 в 18:24

Зная про такую удобную возможность в другом фреймворке (не холивара ради), спрошу — а можно ли, используя CHtml::link, сделать, чтобы вместо текста ссылки был какой-то html? Например контейнер, какая-то картинка и блок текста (.container>(img+.text)). Только чтобы в первый параметр этот html не запихивать. И если нет, то может кто-то знает в каком php-фреймворке можно такое найти?

nikita2206 30 июл 2012 в 18:31

Нет

maxz 30 июл 2012 в 18:38

Ну как же нет, когда прямо в том месте где вы привели красным по белому написано
@param string $text link body. It will NOT be HTML-encoded. Therefore you can pass in HTML code such as an image tag.

nikita2206 30 июл 2012 в 18:39

> Только чтобы в первый параметр этот html не запихивать.

Может я что-то не понял? Но aTei видимо хотел ООП-шного представления элементов дерева, а там просто строкой

SamDark 30 июл 2012 в 18:47

А каков синтаксис этой штуки? Интересно.

aTei 30 июл 2012 в 19:05

Для варианта с текстом как у CHtml::link:

= link_to 'Новости', '/news'

Для варианта с html внутри:

= link_to photo.large.url do
  .container
    = image_tag photo.thumbnail.url
    .text Hello World

pastebin.com/iA2hjVSv

SamDark 30 июл 2012 в 19:30

Не, у нас нет обёртки над DOM и как-то не особо хочется: повысит количество штук, которые придётся изучать.

Fesor 30 июл 2012 в 19:47

А в этом то какой смысл? Мне всегда казалось что весь смысл в отделении логики от представление с упрощением каждого из компонентов для разработки и поддержки. А это, уж извините, месиво.

nikita2206 30 июл 2012 в 20:04

Чем-то на хамл похоже, а его имплементация на пыхе есть

Fesor 30 июл 2012 в 20:12

А смысл у этой штуки есть? Написано «Markup should be beautiful.» но вижу я прямо противоположное.

nikita2206 30 июл 2012 в 20:19

Ну это в общем то как и с пхп-фреймворками. Пока не изучишь — будешь плеваться, а когда изучишь — сможешь гораздо быстрей писать шаблоны. Другое дело, что я не верстаю настолько быстро, чтобы это мне сильно помогло… Некоторые еще говорят, что читаемость лучше, но тут уже похоже дело вкуса, меня хтмл устраивает пока

Fesor 30 июл 2012 в 20:52

Все эти псевдоразметки как по мне излишнее, хорошая IDE с хорошим автокомплитом позволит реализовать разметку страницы за достаточно небольшой промежуток времени. В случае с CSS помогут всякие LESS или SASS для организации кода. Единственный шаблонизатор который мне понравился и который реально помогает сэкономить время это Twig, очень приятная штука, но не без минусов, хоть они и незначительны пере плюсами. В остальном же нравятся PHP вставки.

Ekstazi 30 июл 2012 в 20:14

На самом деле очень мощная вещь, особенно с учетом того как она с аяксом дружит и формами.

Fesor 30 июл 2012 в 20:16

для форм писал свой лесапед на основе штатного форм билдера, собственно как раз избавлял его от зависимости от CActiveForm и CHtml.

Ekstazi 30 июл 2012 в 20:18

У меня уже давно свой есть, на гитхабе лежит, тока пока зависит, но зато проверяет все формы по аяксу и еще очень много плюшек имеет.

vitalets 31 июл 2012 в 11:01

а ссылочкой не поделитесь?

Ekstazi 31 июл 2012 в 21:19

Пожалуйста Изначально оно было совсем другим, пока я не рассказал о моем подходе Славе(mc_bear). Тот сделал свою версию основанную на моем подходе, но дополненную. А все улучшения и дополнения висят на мне. Сейчас я работаю над более простой версией с другим названием ExForm, которая не будет зависеть от CActiveForm и CForm, и много чего еще… И работать она будет быстрее и в то же время предоставлять больше возможностей, но в то же время и меньше, так как часть возможностей придется убрать.

vitalets 1 авг 2012 в 07:48

Спасибо!

vitalets 31 июл 2012 в 10:55

Самый полезный метод из него CHtml::listData :)

tnz 30 июл 2012 в 20:40

Чуток не по теме, но все же.
В CActiveRecord в методе save вызывается afterSave до того, как установлен флаг isNewRecord=false. Поэтому в обработчике afterSave невозможно получить записи для related полей. Оно просто проверяет флаг isNewRecord и возвращает null для них, хотя для записи уже есть праймари ключ. Возможно это для чего-то сделано. Просто получается что вызов происходит не совсем after этого самого save.

Fesor 30 июл 2012 в 20:56

Ну логика тут есть: после сохранение в базу у вас объект не должен поменять состояния — вы его мгновением назад создали, и он все еще новый. Допустим у вас в afterFind для новых записей должна быть одно дейтвие, а для обновленных — другое. Если менять флаг перед вызовом события, то у вас все записи после afterFind будут проходить как обновленные, а не как добавленные. Как-то так.

Да и потом где гарантии что вы уже создали все связанные объекты?

tnz 30 июл 2012 в 21:10

Залез еще раз в код, посмотреть поточнее.
Метод называется insert. Внутри него после удачного собственно инсерта и проставления праймари ключа в модели вызывается вот что

$this->afterSave();
$this->setIsNewRecord(false);
$this->setScenario('update');

А так да, afterSave вызывается и для insert, и для update. Но, мне кажется, можно параметром передавать вызываем мы его после добавления записи или обновления.

Да и потом где гарантии что вы уже создали все связанные объекты?

Это да, но проблема скорее архитектуры. Если я связные записи еще не сохранил, то и так вернется null записей.

Но в целом да, я уже пораскинул мозгами и пришел к выводу, что странно обращаться к связным таблицам, когда мы только-только сохранили главную запись.

disem 30 июл 2012 в 21:22

Но, мне кажется, можно параметром передавать вызываем мы его после добавления записи или обновления.

Можно узнать какое действие происходит используя $this->getScenario(), также get\set сценариев позволяет создавать массу кейсов для управления данными.