Отправка файла пользователю — обычно статические файлы передаются по прямому УРЛу в обход рельсового приложения. Тем не менее в ряде ситуаций может быть полезно спрятать расположение файла, особенно если вы посылаете что-либо ценное, наподобии е-книги. Может также требоваться ограничить посылку файлов только залогиненным пользователям. Проблему решает send_file. Файлы передаются по 4096 байтов, так что даже большие файлы систему не затормозят.
К сожалению, это неправда. Когда метод send_file используется в приложении Rails, которое работает под Mongrel (под mod_rails не проверял еще), весь файл считывается-таки в память! Поэтому использование send_file для отправки больших файлов приведет только к головной боли.
Запуск длинных процессов отдельно в фоне — есть небольшой фреймворк BackgrounDRbот Эзры Зигмунтовича (Ezra Zygmuntovich), который запускается в виде демона и принимает задачи от рельсового приложения, и выполняет их независимо. Мощная вещь, помогает в рассылке писем, получении УРЛов, и прочего, что может затормозить время выполнения запроса основного приложения. Демо-таск увеличивает переменную на 1, после чего делает sleep на 1 секунду. Далее делаем рельсовый метод, который опрашивает эту переменную, и чувствуем разницу.
Не спорю, вещь хорошая. Но это хорошо, если память сервера позволяет крутится еще рубишному демону. Иногда cron задача и rake task бывает достаточно.
Выборка элементов страницы через RJS — поменять элемент в RJS нетрудно, но что если мы не знаем, какой именно элемент надо менять, и хотели бы адресоваться через CSS-запрос? Это возможно с методом select. Например, page.select('#items li').each { |item| item.hide }. Мощная штука!
От RJS начинают уже давно отказываться. Он не гибок.
Проверка существования — при выполнении Model.find(id) мы получим исключение, если элемента «id» не нашлось. Чтобы это избежать, сперва выполняем Model.exists?(id), чтобы узнать, есть ли такой.
Исключение будет только на dev-среде. В prod-среде вернет nil.
При работе над масштабным проектом, или просто в случае распределенной разработки часто возникают проблемы из серии «Петя, после твоего коммита опять сломался билд, срочно чини!» или более характерное для славянских программистов «Ебаный в рот! Кто сломал билд?». Одним из очевидных спобов решения таких проблем является «непрерывная интеграция».
Подробнее тут и тут.
ЗЫ
>>если вы при отладке программ используете var_dump() / printr()
отладка кода и непрерывная интеграция это разные вещи.
>>и 10 разных блоков с этими данными в разных комбинациях. Пользователь сменил пол и мне надо сбросить во всех 10 блоках кэш, сменил город — в 8, аватарку — 5 и т.д. Добавили еще блок, бежим по всем классам, меняем метод cleanCache.
Зачем так жестко. Разбейте просто на паршал кеш ваши вьюшки (или через partial или через cache do). И чистите только при обновлении аватарки паршал аватарки.
>> сложность валидации данных: при записи в базу, приходилось сбрасывать данные у различных связанных блоков, из-за этой путаницы часто возникали ошибки.
Не могли бы пояснить пример? Я просто возможно не понимаю проблему. Не проще создать класс-наблюдатель за кешем моделей. При обновлении записи в какой то модели сбрасивать её специфический кеш на view (что успешно реализовано на симфони не раз)?
Само отправило… Странно… Так вот пример. class ListSweeper < ActionController::Caching::Sweeper
observe List, Item
def after_save(record)
list = record.is_a?(List) ? record : record.list
expire_page(:controller => "lists", :action => %w( show public feed ), :id => list.id)
expire_action(:controller => "lists", :action => "all")
list.shares.each { |share| expire_page(:controller => "lists", :action => "show", :id => share.url_key) }
end
end
По строчкам
observe List, Item — модели, за которыми он следит
after_save(record) — функция, выполняется если хотя бы одна модел создалась или обновилась
list = record.is_a?(List)? record: record.list — обновилась одна запись или список
expire_page — очистка страничного кеша
expire_action — очистка активного кеша
list.shares.each { |share| expire_page(:controller => «lists», :action => «show», :id => share.url_key) } — очистка группы страниц
Я за это даже рад. Меньше популярность — меньше внимание со стороны вирусописателей и хакеров.
Перед запуском с консоли наберите
export GDK_NATIVE_WINDOWS=1
и будет Вам счастье.
Перейдут на другие браузеры?
К сожалению, это неправда. Когда метод send_file используется в приложении Rails, которое работает под Mongrel (под mod_rails не проверял еще), весь файл считывается-таки в память! Поэтому использование send_file для отправки больших файлов приведет только к головной боли.
Не спорю, вещь хорошая. Но это хорошо, если память сервера позволяет крутится еще рубишному демону. Иногда cron задача и rake task бывает достаточно.
От RJS начинают уже давно отказываться. Он не гибок.
Исключение будет только на dev-среде. В prod-среде вернет nil.
При работе над масштабным проектом, или просто в случае распределенной разработки часто возникают проблемы из серии «Петя, после твоего коммита опять сломался билд, срочно чини!» или более характерное для славянских программистов «Ебаный в рот! Кто сломал билд?». Одним из очевидных спобов решения таких проблем является «непрерывная интеграция».
Подробнее тут и тут.
ЗЫ
>>если вы при отладке программ используете var_dump() / printr()
отладка кода и непрерывная интеграция это разные вещи.
www.symfony-project.org/cookbook/1_2/en/behaviors
Зачем так жестко. Разбейте просто на паршал кеш ваши вьюшки (или через partial или через cache do). И чистите только при обновлении аватарки паршал аватарки.
Не могли бы пояснить пример? Я просто возможно не понимаю проблему. Не проще создать класс-наблюдатель за кешем моделей. При обновлении записи в какой то модели сбрасивать её специфический кеш на view (что успешно реализовано на симфони не раз)?
leopard.not.a[at]gmail.com
Благодарен заранее!
class ListSweeper < ActionController::Caching::Sweeper
observe List, Item
def after_save(record)
list = record.is_a?(List) ? record : record.list
expire_page(:controller => "lists", :action => %w( show public feed ), :id => list.id)
expire_action(:controller => "lists", :action => "all")
list.shares.each { |share| expire_page(:controller => "lists", :action => "show", :id => share.url_key) }
end
end
По строчкам
observe List, Item — модели, за которыми он следит
after_save(record) — функция, выполняется если хотя бы одна модел создалась или обновилась
list = record.is_a?(List)? record: record.list — обновилась одна запись или список
expire_page — очистка страничного кеша
expire_action — очистка активного кеша
list.shares.each { |share| expire_page(:controller => «lists», :action => «show», :id => share.url_key) } — очистка группы страниц