Pull to refresh
24
0
overPlumbum @overPlumbum

User

Send message
А у него «из-коробки» есть что-нибудь консольное для запуска js, по аналогии с коммандой «js», как у SpiderMonkey?
так очень удобно js-unit-тесты и JsLint на сервере гонять. Можно было бы сразу на двух движках тестировать…

Через личные сообщения можно точно так же спамить.
поидее если просто склеить тела документов, то всё должно быть хорошо.
только посередине стоит вставить перевод страницы (\page ) или строки (\par или \line — по ситуации) и хотя бы сброс стилей параграфа ( \pard )

пример: есть два документа {\rtf1… hello… } и {\rtf1… bye… }
если склеить должно получится:
{\rtf1… hello… \pard \page… bye… }

возможно, переопределять стили, шрифты и цвета второй раз не очень хорошо. но на первый взгляд работает.
там может быть текстовый слой. но это скорее редкость
надо только не забывать что чаще всего в DJVU нет текстового слоя, а есть только картинка с текстом — её можно разве что только распознать каким-нибудь FineReader-ом, но это уже совсем другая тема.
пример описывает частый случай нагруженной гостевой страницы на которой обязательно должно быть кэширование, которое плохо уживается с передачей сообщений через сессию (можно, но страшно костыльно).
Кстати не обязательно делать сообщения предвбитыми, на JS вполне можно сделать схему не менее гибкую чем на базе сессии в PHP.

5-10 сообщений могут вылезти только в каком-нибудь внутреннем залогиновом интерфейсе, тут безусловно удобнее делать реализацию через сессию например как в Codeigniter::Flashdata.
а для гостя как сообщения к пользователю привязывать? по id сессии? тогда это и есть просто сессия, которая хранится в БД :)
пример с флагом о просто сообщении приведён для простоты
отключенный JS это тема отдельного холивара
а js словарь всё равно придётся делать если есть js и i18n :)
храненение информации не в урле мешает кэшированию страниц. а это куда важнее сессионого хранилища для нагруженного проекта
для статистики хватит тех у кого он не отрублен.
в логике сайта полагаться на REFERER нельзя.
REFERER очень много у кого не работает из-за файерволов (и прочих InternetSecurity) и корпоративных проксей
у существенного процента пользователей REFERRER отшиблен файерволом(или типа того).
вот такая вот паранойя :(

ну и такой метод требует refresh страницы, а hash убирается без перезагрузки.
Да, конечно, это довольно редкий случай когда имеет смысл так делать.
Собственно я и выбрал этот пример для статьи о нотификациях, потому что в нём без нотификатора ну никак не обойтись.
Спасибо.
Кэширование идёт на самом верхнем уровне, до поиска
1. приходит запрос /search?q=вася
2. я к нему дописываю зависимости (например признак того что это страница для гостя)
3. смотрю нет ли чего у меня в кэше по такому запросу,
4. и не лазя в базу отдаю редирект
Второй вариант проигрывает 3-му тем что пользователи начинают друг-другу давать ссылки на страницы с открытым уведомлением, хотя сторонним людям оно нафиг не упало ( пример: moikrug.ru/companies/571544408/?one=1 ). Но эта проблема не касается страниц на которые ссылок не дают ( ну например внутренние страницы какой-нибудь админки )

1-й вариант очень удобен как универсальное решение для всего сайта, могу объяснить почему если интересно
всё самописное, и с параметризацией всё порядке.

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

Мне просто по жизни механизм кэширование мешает пользоваться сессией, и я её как-то мысленно всё время отбрасываю.
Хотя когда такой проблемы нет, сессия и без лишних заморочек отлично справляется — очень удобно, — можно в любом месте кода добавлять туда уведомления и не думать когда произойдёт редирект.
Это тоже не панацея :) (для кук в большей степени, для сессии это надо умудрится, но теоретически тоже можно)

1. меня кидает на /a.php
2. я не даю ей загрузится (тупо кликаю по закладке и ухожу в другое место), т.е. JS-ы которые удалят куки не выполняются
3. гуляю по сайту, захожу на /a.php — и вижу уведомление. не очень к месту :)

Это можно лечить таймаутами — но опять же, на глючном GPRS-е страница может 30 секунд запросто грузиться. А для быстрого интернета за 30 секунд вполне можно вопсроизвести описанный ранее глюк :)

Если чесно, все эти заморочки не стоят своей разработки.
Да и проблемы при использовании сессии или кук появляются как раз от того что это неподходящее место для такой информации.
я правильно понимаю что предлагается по урлу поиска ( например localhost/search? параметры) показывать найденную страницу?

на мой вкус это не хорошо хотя бы тем что нельзя дать нормальную ссылку на эту страницу,
всё таки если в результате поиска находится страница про Васю, то и отображатся она должна по соответствующему URL-у: например localhost/pages/Вася
можно отмазаться тем что ничего страшного без JS по сути и не произойдёт :) просто небольшая деградация интерфейса

Information

Rating
Does not participate
Location
Россия
Works in
Date of birth
Registered
Activity