Посмотрел Вашу ссылку — последние изменения датированы 7 месяцами назад и npm не находит проект в репозитории (намекает на несовместимость с актуальными версиями Ноды).
Вы его использовали где-то в работе? Каковы ощущения, если да?
У нас тоже в свое время встал вопрос о шаблонизации.
Ситуация усугублялась тем, что бизнес логика была реализована на php, а кусочек ее — демон — на Ноде.
В качестве шаблонизатора на пхп части мы использовали толковую штуку Twig, которая является реализацией Джанговских шаблонов.
Перебирая возможные движки для Ноды, с удивлением наткнулись на SWIG, который, за исключением некоторых мелочей, умел все, что нужно.
Теперь изучаем, как серверный SWIG плавно перенести в браузер.
А вообще, странно, что Майкрософт, вместо того, что бы придти к Вам с предложением, предпочитает переписывать заново.
«Еще кстати через IIS с легкостью проксируется Comet, в продакшене. Больше не нужно запускать отдельный процесс для обработки long polling запросов.» — что Вы имеете ввиду? У меня как раз Комет-подобное решение бегает под IISNode, никаких отдельных процессов, кроме ноды, я не использую.
Ярослав, а можно где-то почитать, что умеет Helicon Zoo в применении к NodeJS?
Вы говорите «намного лучше и быстрее» — интересует, чем именно и какие то сравнительные тесты.
Меня в IISNode радует возможность «прятать» внешний порт, в примере Вашей статьи порт виден наружу. Посмотрел официальный сайт — там о такой возможности ничего не увидел :(.
Крайне полезной фичей для хостинга NodeJS является IISNode — дополнение для IIS, позволяющее не «светить» открытый порт в мир (то есть порты IIS и NodeJS будут для клиентского браузера идентичными, работает через именованые пайпы, по заверениям автора — не блокирует собственную очередь IIS-соединений).
Умеет запускать по потоку на ядро процессора (конфигурируемо), перезагружать NodeJS при внезапной «смерти» процесса.
Автор сего чуда — Томаш Янчук, работает в «Майкрософте», оперативно отвечает на тикеты с описаниями проблем.
Его наработку используем на «боевом» сервере — проблем пока не выявили.
Ну да. Мы, например, используем специальный драйвер генератора Ext-компонент на основе XML-описания (что-то типа XUL). Начиналось все с 2.3, потом мы переписывали драйвер с выходом 3.1 и 3.2.
Печалит то, что может «отвалиться» много полезных расширений от комьюнити. С другой стороны, разработчики обещают вменяемый TableLayout :)
Мы вообще отказались от внедрения 3.3 на производстве, когда полезли несовместимости с 3.2
Теперь с трепетом ждем 4 и опасаемся — как бы они снова не выпустили в свет сырую версию, типа ST 1.0
Обещана расширенная документация, но, по опыту работы с Sencha Touch и предыдущими версиями Ext, она далеко не всегда бывает аккуратна.
С другой стороны, в библиотеке хорошо оформлены исходные тексты (ЕМНИП, документация генерируется на основе комментариев в них). Потому при наличие сложностей, нужно смотреть туда.
Кроме официальных примеров, что идут в дистрибутиве, есть еще замечательный сайт extjs.eu/, где есть много интересного и полезного.
На самом деле, там их два. Название оригинального шрифта (им выполнен весь английский текст) я не знаю, а для заголовка на кириллице использовал Franklin Gothic Book.
Как я понимаю, в идеале они хотят предоставить полное MVC, что бы облегчить порог вхождения в их технологию. И разгребают сопутствующие проблемы. А клиенты требуют, например, валидацию в моделях, а не в интерфейсе.
Исправил, спасибо!
Касательно прожорливости и скорости — авторы уверяют, что ситуация коренным образом изменилась, что он стал быстрее и менее ресурсоемким. Правда, это и про Ext 3 говорилось :-) Остается ждать полной беты.
Меня больше смущает измененная политика работы с данными и с шаблонами — на офицальном форуме народ высказывал опасения, что предыдущие наработки могут оказаться несовместимыми с новой версией. Разрабочики вообще хранили молчание и подтерли топик :)
Да, архитектуру они изменили довольно сильно: упор в развитии Ext JS 4 сделан в сторону реализации MVC. Соответственно, в Ext.data введено понятие моделей, связей между ними и подгрузку связанных данных. www.sencha.com/blog/2011/01/21/countdown-to-ext-js-4-data-package/ (на английском) — небольшое описание пакета. Надеюсь собраться с силами и перевести эту статью тоже :)
Да, для части ресурсов показывает плейнтекст.
Да, пароли не первой свежести, но правильные — проверил по части списка друзей.
Модуль написан весьма нехорошо — там нет даже перечня настраиваемых допустимых размеров превью.
Мы генерируем превью при заливке файла, ложим их на винчестер и отдаем потом статику «легким» вебсервером.
Есть мнение, что предложенная автором концепция на высоконагруженном ресурсе приведет к проблемам в производительности.
Вы его использовали где-то в работе? Каковы ощущения, если да?
Ситуация усугублялась тем, что бизнес логика была реализована на php, а кусочек ее — демон — на Ноде.
В качестве шаблонизатора на пхп части мы использовали толковую штуку Twig, которая является реализацией Джанговских шаблонов.
Перебирая возможные движки для Ноды, с удивлением наткнулись на SWIG, который, за исключением некоторых мелочей, умел все, что нужно.
Теперь изучаем, как серверный SWIG плавно перенести в браузер.
Но подобную проблему под Apache и NGinx успешно решал автор VooDoo Chat при помощи своих mod_voc2 и mod_nginx еще в 2005-2006 годах.
Напрямую проксировать, естественно — это убийство сервера, так как веб-сервер держит открытый коннект на все время long pooling сессии.
Описанные выше модули как раз и учили веб-сервер «забывать» о таком соединении, не закрывая сокет.
А вообще, странно, что Майкрософт, вместо того, что бы придти к Вам с предложением, предпочитает переписывать заново.
«Еще кстати через IIS с легкостью проксируется Comet, в продакшене. Больше не нужно запускать отдельный процесс для обработки long polling запросов.» — что Вы имеете ввиду? У меня как раз Комет-подобное решение бегает под IISNode, никаких отдельных процессов, кроме ноды, я не использую.
Вы говорите «намного лучше и быстрее» — интересует, чем именно и какие то сравнительные тесты.
Меня в IISNode радует возможность «прятать» внешний порт, в примере Вашей статьи порт виден наружу. Посмотрел официальный сайт — там о такой возможности ничего не увидел :(.
Может, плохо смотрел?
Умеет запускать по потоку на ядро процессора (конфигурируемо), перезагружать NodeJS при внезапной «смерти» процесса.
Автор сего чуда — Томаш Янчук, работает в «Майкрософте», оперативно отвечает на тикеты с описаниями проблем.
Его наработку используем на «боевом» сервере — проблем пока не выявили.
К сожалению, ссылки на бету четверки нет(.
С большим удовольствием слежу за Вашими статьями.
Печалит то, что может «отвалиться» много полезных расширений от комьюнити. С другой стороны, разработчики обещают вменяемый TableLayout :)
Обещают исправиться.
Теперь с трепетом ждем 4 и опасаемся — как бы они снова не выпустили в свет сырую версию, типа ST 1.0
С другой стороны, в библиотеке хорошо оформлены исходные тексты (ЕМНИП, документация генерируется на основе комментариев в них). Потому при наличие сложностей, нужно смотреть туда.
Кроме официальных примеров, что идут в дистрибутиве, есть еще замечательный сайт extjs.eu/, где есть много интересного и полезного.
Касательно прожорливости и скорости — авторы уверяют, что ситуация коренным образом изменилась, что он стал быстрее и менее ресурсоемким. Правда, это и про Ext 3 говорилось :-) Остается ждать полной беты.
Меня больше смущает измененная политика работы с данными и с шаблонами — на офицальном форуме народ высказывал опасения, что предыдущие наработки могут оказаться несовместимыми с новой версией. Разрабочики вообще хранили молчание и подтерли топик :)
www.sencha.com/blog/2011/01/21/countdown-to-ext-js-4-data-package/ (на английском) — небольшое описание пакета. Надеюсь собраться с силами и перевести эту статью тоже :)