Я вот подумывал, что если каждый хэлпер элемента добавляет свой js код в ZendX_JQuery_View_Helper_JQuery_Container, то можно написть хэлпер/плагин, кот на postDispatch будет добавлять в ответ этот js код в случае XmlHttp запроса. Но есть одно НО, код добавленный в этот контейнер теряет связь с элементом, кот его добавил, другими словами, это просто стек. И что именно достать из этого стека в postDispatch неясно.
А вариант расширения хэлперов — уж очень трудоемкий, да и к тому же по-хорошему, мы же это делаем для того, чтобы наши элементы конфигурировались в одном месте, а значит эту js-функцию хотелось бы написать на стороне сервера. И вот это мне тоже не нравится, т.к. писать js код в PHP файлах сложее, чем добавление аттрибутов — еще то извращенство.
Немного в сторону от томы, но все же: а может вы знаете хорошее решение как использовать, например, Zend_Jqery_Form_Element_Autocomplete при динамическм добавлении?
Еще есть прекрасная опция auto_prepend_file. Указываем файл, в нем проверяем какой php файл был запущен, если не из списа разрешенных — exit
Вполне неплохое решение, как правило используют mod-rewrite и файл запускают один
Вы правы.
Для сообшений, обрабатываемых по крону, стоит просто увеличить таймаут и запускать очередную задачу чаще чем этот таймаут. Думаю это решит задачу с большего.
Ок, это просто пример был. Видимо неудачный.
Я это все говорил к тому, что иной раз невозможно знать наверняка скорость обработки сообщений и из-за этого мне этот механизм кажется не самм лучшим в отличие от использования демона.
В том то и дело, что нельзя наверняка знать время обработки сообщенийю
Вот, например, я рассылаю емэйлы. STMP сервер может не отвечать по каким-лбо причинам в течении некоторого времени и получается, что мои эмейлы разошлются несколько раз :(
Я хочу чтобы срипт заупскался каждую минуту и рассылал по 50 сообщений. Если коннект с SMTP сервером ок, то все работаеткак часы, если сервер тупит хотя бы минуту — у меня дубрируются емэйлы.
Для background задач вроде обработки очередей — не вижу смысла в демонах.
Я нача лработать с очередями используя Zend_Queue. По крону достаю заданное кол-во сообщений, у них проставляется timeout (время в течении кот они не должны доставаться другой крон-задачей). Но если это время меньше, чем время обработки этих сообщений, получается, что другая крон задача также заберет эти сообщения (какую-то чась из них) и обработает их. Получается, что сообщения могут быть обработаны несколько раз.
Если же использовать демон, то он может проверять через заданный интервал наличие новых сообщений в очереди и обрабатывать их последовательно. Такми образом можно избежать обработку идного и того же сообщения несколько раз наверняка.
Если хранить роутинг в разных страницах, при больших объёмах можно просто забыть где и что лежит, свой вариант считаю вполне удобным.
Когда кол-во роутов возрастет до 500, вам по-прежнему будет удобно?
В дальнейшем, при последующих запросах разумеется, обновляется путём удаление файла *.dat
Роутинг обновляется очень редко, не хотел каждый раз проверять время изменения файла.
Вы моежете быть уверены, что ни один программист из команды, работающий над проектом никогда не забудет обновить файл *.dat?
А вариант расширения хэлперов — уж очень трудоемкий, да и к тому же по-хорошему, мы же это делаем для того, чтобы наши элементы конфигурировались в одном месте, а значит эту js-функцию хотелось бы написать на стороне сервера. И вот это мне тоже не нравится, т.к. писать js код в PHP файлах сложее, чем добавление аттрибутов — еще то извращенство.
Вполне неплохое решение, как правило используют mod-rewrite и файл запускают один
Вот за это люблю python!
Для сообшений, обрабатываемых по крону, стоит просто увеличить таймаут и запускать очередную задачу чаще чем этот таймаут. Думаю это решит задачу с большего.
Какой вы видите выход?
Я это все говорил к тому, что иной раз невозможно знать наверняка скорость обработки сообщений и из-за этого мне этот механизм кажется не самм лучшим в отличие от использования демона.
Вот, например, я рассылаю емэйлы. STMP сервер может не отвечать по каким-лбо причинам в течении некоторого времени и получается, что мои эмейлы разошлются несколько раз :(
Я хочу чтобы срипт заупскался каждую минуту и рассылал по 50 сообщений. Если коннект с SMTP сервером ок, то все работаеткак часы, если сервер тупит хотя бы минуту — у меня дубрируются емэйлы.
Что делать, как знать?
Не понял вас, если честно.
Я думаю имеет смысл, только нужно котролировать кол-во дочерних процессов, чтобы он не было over 9000.
А вообще, конечно, хотелось бы услышать ответ по поводу разбора сообщений с помощью крон-задач, если у кого есть опыт
Я нача лработать с очередями используя Zend_Queue. По крону достаю заданное кол-во сообщений, у них проставляется timeout (время в течении кот они не должны доставаться другой крон-задачей). Но если это время меньше, чем время обработки этих сообщений, получается, что другая крон задача также заберет эти сообщения (какую-то чась из них) и обработает их. Получается, что сообщения могут быть обработаны несколько раз.
Если же использовать демон, то он может проверять через заданный интервал наличие новых сообщений в очереди и обрабатывать их последовательно. Такми образом можно избежать обработку идного и того же сообщения несколько раз наверняка.
А как вы решаете задачу?
Когда кол-во роутов возрастет до 500, вам по-прежнему будет удобно?
Вы моежете быть уверены, что ни один программист из команды, работающий над проектом никогда не забудет обновить файл *.dat?
Ответьте, пожалуйста, также на 2 вопроса из моего первого комментария
Я правильно понимаю, что дерево нужно ТОЛЬКО для этого?