А у него «из-коробки» есть что-нибудь консольное для запуска 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.
пример с флагом о просто сообщении приведён для простоты
отключенный JS это тема отдельного холивара
а js словарь всё равно придётся делать если есть js и i18n :)
Да, конечно, это довольно редкий случай когда имеет смысл так делать.
Собственно я и выбрал этот пример для статьи о нотификациях, потому что в нём без нотификатора ну никак не обойтись.
Спасибо.
Кэширование идёт на самом верхнем уровне, до поиска
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-unit-тесты и JsLint на сервере гонять. Можно было бы сразу на двух движках тестировать…
только посередине стоит вставить перевод страницы (\page ) или строки (\par или \line — по ситуации) и хотя бы сброс стилей параграфа ( \pard )
пример: есть два документа {\rtf1… hello… } и {\rtf1… bye… }
если склеить должно получится:
{\rtf1… hello… \pard \page… bye… }
возможно, переопределять стили, шрифты и цвета второй раз не очень хорошо. но на первый взгляд работает.
Кстати не обязательно делать сообщения предвбитыми, на JS вполне можно сделать схему не менее гибкую чем на базе сессии в PHP.
5-10 сообщений могут вылезти только в каком-нибудь внутреннем залогиновом интерфейсе, тут безусловно удобнее делать реализацию через сессию например как в Codeigniter::Flashdata.
отключенный JS это тема отдельного холивара
а js словарь всё равно придётся делать если есть js и i18n :)
в логике сайта полагаться на REFERER нельзя.
вот такая вот паранойя :(
ну и такой метод требует refresh страницы, а hash убирается без перезагрузки.
Собственно я и выбрал этот пример для статьи о нотификациях, потому что в нём без нотификатора ну никак не обойтись.
Спасибо.
1. приходит запрос /search?q=вася
2. я к нему дописываю зависимости (например признак того что это страница для гостя)
3. смотрю нет ли чего у меня в кэше по такому запросу,
4. и не лазя в базу отдаю редирект
1-й вариант очень удобен как универсальное решение для всего сайта, могу объяснить почему если интересно
проблема, как я сейчас вспомнил, была немного хитрее — у меня поиск кэшировал редирект на страницу с результатом, — т.е. при попадании в кэш редирект происходил, а вот в сессию сообщение уже никто не писал, решение сохранять вместе с редиректом часть сессии показалось уж слишком странным, — тут-то и начались изыскания :)
Мне просто по жизни механизм кэширование мешает пользоваться сессией, и я её как-то мысленно всё время отбрасываю.
Хотя когда такой проблемы нет, сессия и без лишних заморочек отлично справляется — очень удобно, — можно в любом месте кода добавлять туда уведомления и не думать когда произойдёт редирект.
1. меня кидает на /a.php
2. я не даю ей загрузится (тупо кликаю по закладке и ухожу в другое место), т.е. JS-ы которые удалят куки не выполняются
3. гуляю по сайту, захожу на /a.php — и вижу уведомление. не очень к месту :)
Это можно лечить таймаутами — но опять же, на глючном GPRS-е страница может 30 секунд запросто грузиться. А для быстрого интернета за 30 секунд вполне можно вопсроизвести описанный ранее глюк :)
Если чесно, все эти заморочки не стоят своей разработки.
Да и проблемы при использовании сессии или кук появляются как раз от того что это неподходящее место для такой информации.
на мой вкус это не хорошо хотя бы тем что нельзя дать нормальную ссылку на эту страницу,
всё таки если в результате поиска находится страница про Васю, то и отображатся она должна по соответствующему URL-у: например localhost/pages/Вася