Доступно (http://zotonic.com/docs/latest/dev/releasenotes/rel_0.13.5.html) обновление высокопроизводительного web-фреймворка Zotonic 0.13.5 (http://zotonic.com/), написанного на языке Erlang (http://www.erlang.org). Код фреймворка распространяется под лицензией Apache 2 (http://zotonic.com/zotonic-license).
В новой версии:
- Исправлена ошибка полнотекстового поиска, приводившая к многократному морфологическому разбору (стеммингу) текста запроса,
- Исправлена ошибка с многократной компиляцией шаблонов,
- Добавлена возможность принудительного выбора языка,
- Исправлена ошибка с push-отправкой данных при работе через comet и postback,
- Исправлена проблема в модуле mod_video, связанная с несовместимостью с QuickTime,
- Исправлена проблема с разрешением sudo для групп пользователей.
- Обновлён включённый в комплект редактор TinyMCE.URL: https://groups.google.com/forum/#!topic/zotonic-users/KqGQX3...
Новость: http://www.opennet.me/opennews/art.shtml?num=43205
>высокопроизводительного web-фреймворкаА в нём есть что-то интересного, кроме того, что он на Эрланге? Можно было бы и черкнуть пару строк -- что-то мне кажется этот фреймворк даже в узких кругах не очень известная вещь...
Ну, например, в своё время меня привлекло вот это: "while the template is being rendered and one or more processes request the same rendering, the later processes will be suspended. When the rendering is done all waiting processes will be sent the rendering result" (пока выполняется отрисовка шаблона, и один или более процессов запрашивают ту же отрисовку, более поздние процессы будут приостанавлены. Когда отрисовка будет завершена, всем ожидающим процессам будет направлен её результат - http://aosabook.org/en/posa/zotonic.html). Кроме этого, я считаю преимуществом привязку к PgSQL, т.к. Zotonic интенсивно использует фичи постгреса, и не делает сам того, что постгрес сделает быстрее и эффективнее.
>я считаю преимуществом привязку кНе могу согласиться -- привязка к чему-либо это плохо. Особенно когда мы говорим о такой казалось бы гибкой и универсальной вещи как фреймворк.
> Не могу согласиться -- привязка к чему-либо это плохо. Особенно когда мы
> говорим о такой казалось бы гибкой и универсальной вещи как фреймворк.Хорошо бы, но для этого надо поддерживать код, использующий преимущества каждой СУБД. Лучше уж использовать по полной специфику одной, а потом, когда вообще оформится понимание того, что именно нам нужно, распространить это на остальные БД.
Тут наверное дело в том, что в случае с Erlang не имеет смысла использовать что-то вроде PDO, Класс приложений, которые разрабатываются на этом языке подразумевают максимальную производительность. Поэтому и взяли одну хорошую бесплатную СУБД и заточили под неё.
Прикольно, иногда, после применения большого пакета обновлений, начинается такая жесть с отдачей контента, но, к сожалению, архитектура слишком специфичная для обычных проектов.
Нормальные люди выдачу одинакового контента на несколько запросов отдают кеширующему прокси типа nginx.
В разных страницах могут присутствовать блоки, заданные одним темплейтом. В сабже для всех воркеров, которые генерят такие страницы, этот темплейт компилится один раз.
Расскажите мне, как закэшировать в нжинксе одинаковые фрагменты разных страниц.
всегда делали так - разбивается страница на блоки и кешируются
эти отдельные части
> В разных страницах могут присутствовать блоки, заданные одним темплейтом. В сабже для
> всех воркеров, которые генерят такие страницы, этот темплейт компилится один раз.
> Расскажите мне, как закэшировать в нжинксе одинаковые фрагменты разных страниц.SSI
SSI в базу лезет и прочую ништяковую работу по фильтрации/агрегации данных выполняет?
Это не говоря уже про всесторонюю манипуляцию этими данными ))
При чем тут это?
> В разных страницах могут присутствовать блоки, заданные одним темплейтом. В сабже для
> всех воркеров, которые генерят такие страницы, этот темплейт компилится один раз.
> Расскажите мне, как закэшировать в нжинксе одинаковые фрагменты разных страниц.Нжникс умеет ssi