А что если надо будет по этим данным построить нетривиальный кусок html-я?
С помощью jquery строить? Неуклюже.
Использовать шаблоны на клиентской стороне? А что с дублированием кода тогда? Ведь при первом открытии страницы подобный html уже рендерится на сервере (а часто и кэшируется!), и его можно использовать в таких js-ответах.
Плюс в случае проблем явно видно где искать. Желаю Вам не сталкиваться с проектами где весь js-код запихан изначально в один super-main-script.js файл и в нем ничего не найти сразу.
Не до конца понял комментарий. Что за stand-alone приложение?
Скажу другими словами. 1 фоновый процесс обрабатывающий в цикле 100500 сообщений по одному за раз все-таки лучше чем 100500 новых запускаемых одновременно процессов. Или нет? Да, дольше отработает, но в данной ситуации не нужны реалтайм изменения.
Возможно, я не так понял и/или выразился.
Это не просто скрипт, это кусок кода, который надо поместить в Resque/DJ job или rake-task. «Запустить этот скрипт» означает запустить целиком приложение (нам как минимум надо доступ к БД, чтобы пользователей отписать)
А если уже есть экземпляры приложения, которые можно использовать, зачем еще один?
Да еще и на каждое письмо, а если 100500 разом придет? А если почтовый сервер не свой?
Да и ради операции которая запускается раз в несколько дней держать целый экземпляр приложения в памяти, думаю, не стоит. Особенно когда уже есть запущенные экземпляры(Resque, DJ) для других фоновых периодических задач, которые можно использовать.
Здесь двоякий вопрос. Одно дело когда нужно структурировать js-код.
Другое дело — подключать определенные js-файлы только на определенных страницах (и/или для определенных пользователей). Например, ckeditor имеет тонну js и используется только админами приложения. Соответственно загружать для обычных пользователей эту кучу js не стоит.
Может это дело вкуса, но мне показалось очень удобным, когда все скрипты находятся в "#{params[:controller]}.js.coffee".
Согласен, но это больше дело дисциплины разработчиков при соблюдении конвенций именования и расположения кода, или нет? :)
Преимущества пайплайна очевидны, а голый javascript_include_tag делает дополнительный запрос на сервер. Это может отразиться на производительности, если кусок кода большой.
Также ничего не мешает добавить скрипт (или манифест аналогичный application.js) подключенный через javascript_include_tag к config.assets.precompile. А дополнительный запрос будет в обоих случаях.
По моему мнению, использование данного плагина — излишнее усложнение. И добавление пары строк (решение с javascript_include_tag) чище.
Но минус такого подхода в том, что скрипты, относящиеся определенному контроллеру, не находятся в одном месте (а значит тяжелее искать и разбираться). В довесок, если кусок кода большой, то мы теряем преимущества пайплайна.
Неясные аргументы, есть примеры?
И второе, а что если скрипт нужно подключить не только на определенной странице, но и только если у пользователя есть определенная роль в приложении?
Да парсер написан на Си. Как вариант, для добавления новых элементов можно переопределить в своем рендерере методы preprocess и/или postprocess, куда подается весь текст, и обработать дополнительно регулярками или еще как. Не совсем красиво, но должно работать. Спасибо за ссылку на kramdown. Гляну на досуге.
Зависит от задачи конечно. Redcarpet тоже расширяем. Простой пример: хочу чтобы все генерируемые ссылки открывались в новом окне браузера. То бишь надо ко всем ссылкам добавить target="_blank". Реализуем свой рендерер, наследуя от существующего и заменяем один метод, формирующий ссылки, на свой:
class MyRenderer < Redcarpet::Render::HTML
def link(link, title, content)
"<a href='#{link}' title='#{title}' target='_blank'>#{content}</a>"
end
end
И подсовываем в парсер этот рендерер вместо стандартного.
С помощью jquery строить? Неуклюже.
Использовать шаблоны на клиентской стороне? А что с дублированием кода тогда? Ведь при первом открытии страницы подобный html уже рендерится на сервере (а часто и кэшируется!), и его можно использовать в таких js-ответах.
Плюс в случае проблем явно видно где искать. Желаю Вам не сталкиваться с проектами где весь js-код запихан изначально в один super-main-script.js файл и в нем ничего не найти сразу.
Так что не будьте так категоричны.
Скажу другими словами. 1 фоновый процесс обрабатывающий в цикле 100500 сообщений по одному за раз все-таки лучше чем 100500 новых запускаемых одновременно процессов. Или нет? Да, дольше отработает, но в данной ситуации не нужны реалтайм изменения.
Это не просто скрипт, это кусок кода, который надо поместить в Resque/DJ job или rake-task. «Запустить этот скрипт» означает запустить целиком приложение (нам как минимум надо доступ к БД, чтобы пользователей отписать)
А если уже есть экземпляры приложения, которые можно использовать, зачем еще один?
Да еще и на каждое письмо, а если 100500 разом придет? А если почтовый сервер не свой?
Другое дело — подключать определенные js-файлы только на определенных страницах (и/или для определенных пользователей). Например, ckeditor имеет тонну js и используется только админами приложения. Соответственно загружать для обычных пользователей эту кучу js не стоит.
Согласен, но это больше дело дисциплины разработчиков при соблюдении конвенций именования и расположения кода, или нет? :)
Также ничего не мешает добавить скрипт (или манифест аналогичный application.js) подключенный через
javascript_include_tagкconfig.assets.precompile. А дополнительный запрос будет в обоих случаях.Неясные аргументы, есть примеры?
И второе, а что если скрипт нужно подключить не только на определенной странице, но и только если у пользователя есть определенная роль в приложении?
Спасибо за ссылку на kramdown. Гляну на досуге.
И подсовываем в парсер этот рендерер вместо стандартного.