Комментарии 30
Мой выбор пал на Wt в первую очередь за возможность полного абстрагирования от HTML, CSS, JavaScript в пользу одного языка — C++, а также за автоматическую поддержку как Ajax браузеров, так и браузеров без Ajax.
К сожалению это большое заблуждение, как только захочется сделать что-то выходящее за рамки элементов представленных в библиотеке виджетов, вам придется со всем этим столкнуться в полной мере.
Вы правы, поэтому я написал "возможность абстрагирования". Если хочется чего-то особенного, скажем, прикрутить какой-нибудь jquery-плагин, то, разумеется, на JavaScript писать придется. Библиотека предоставляет ряд удобств, упрощающих подключение своего JavaScript: JavaScript сигналы и слоты, методы для загрузки JavaScript-библиотек и выполнения произвольного JavaScript-кода.
Но при стандартном использовании можно обойтись без использования HTML, CSS и JavaScript.
Кстати, в галерее виджетов не представлены некоторые виджеты библиотеки, например, WGLWidget для работы с WebGL.
Но при стандартном использовании можно обойтись без использования HTML, CSS и JavaScript.
Кстати, в галерее виджетов не представлены некоторые виджеты библиотеки, например, WGLWidget для работы с WebGL.
Может вы мне подскажете? Нет ли у них чего-нибудь удобного, чтобы налету делать видео из множества snapshot'ов? Потому что я так и не смог заставить его показывать нормальное видео без проскакивания белых полосок при смене кадров.
Не связано ли это со скоростью?
Не связано ли это со скоростью?
Думаю, склеить снимки в единый видео-файл проще всего внешними средствами (например, ffmpeg, mencoder), после чего показывать через WMediaPlayer.
В галерее виджетов есть работающий пример показа видео.
В галерее виджетов есть работающий пример показа видео.
К сожалению такой вариант не подходит, т.к. длительность видео заранее неизвестно и необходимо воспроизводить его в реалтайме, ну или очень близко к нему.
Мне не доводилось работать с видео в Wt, поэтому могу лишь предположить, что можно использовать WMediaPlayer, а в качестве источника использовать свою реализацию WResource, выдающую видео, склеенное из кадров. Так как WResource по умолчанию кеширует весь ответ, а потом отдает его, при этом нужно использовать ResponseContinuation, подавая каждый раз очередной небольшой кусочек видео.
Не знаю, можно ли при этом обойтись без знания полного размера. В классе WStreamResource реализована отдача любого потока. Только, судя по его коду, полный размер потока ему таки требуется. В принципе, если допускается не полностью чистое решение, можно попробовать подать максимальную длину, которую размер потока точно не превысит.
Не знаю, можно ли при этом обойтись без знания полного размера. В классе WStreamResource реализована отдача любого потока. Только, судя по его коду, полный размер потока ему таки требуется. В принципе, если допускается не полностью чистое решение, можно попробовать подать максимальную длину, которую размер потока точно не превысит.
Но при стандартном использовании можно обойтись без использования HTML, CSS и JavaScript.
Звучит как «раздели на 0».
К сожалению это большое заблуждение, как только захочется сделать что-то выходящее за рамки элементов представленных в библиотеке виджетов, вам придется со всем этим столкнуться в полной мере.это утверждение соответствует большинству фреймворков, и как правило всегда тебе или заказчику чего-то хочется большего, и ты вынужден копаться в тоне говнокода. И тогда по времени выходит больше, чем если бы реализовывал все сам.
Вы сейчас стали по другую сторону баррикад. В итоге разработка любого продукта занимает в 10 раз больше времени, а отладка…
речь идет о некоторых фичах вашего Продукта, которые очень хочет Заказчик. Но, к сожалению эти фичи не предусмотрены в используемом фреймворке. Есть два пути реализации: Правильный — разбираться в тонне говнокода и пытаться их реализовать средствами фреймворка, путем написания дополнительных плагинов, использования кучи кэллбэков, обвязок и прочих вязок… Или не совсем верный — реализовать их самостоятельно и внедрить во вреймворк. Как показывает практика — второй путь короче.
Часть Заказчиков предпочитает не открывать код покупателям приложения. Ещё может так получиться, что распространять проприетарный плагин к фреймворку позволяется лицензией, а вносить изменения в код фреймворка и распространять измененный вариант без открытия кода — нельзя. Это не относится к Wt, но относится к фреймворкам, распространяемым под лицензией GNU Lesser General Public License.
Мне кажется, для написания плагина требуется не такое глубокое «погружение» в код фреймворка, как для внесения своих изменений. Если мы внесли изменения в сам фреймворк, то как быть при выходе новой версии фреймворка? Наши изменения могут оказаться несовместимыми с изменениями разработчиков фреймворка. Так что в плане сопровождения плагин выглядит привлекательнее.
Мне кажется, для написания плагина требуется не такое глубокое «погружение» в код фреймворка, как для внесения своих изменений. Если мы внесли изменения в сам фреймворк, то как быть при выходе новой версии фреймворка? Наши изменения могут оказаться несовместимыми с изменениями разработчиков фреймворка. Так что в плане сопровождения плагин выглядит привлекательнее.
Видел где-то некий проект под названием node.cpp, думаю такой подход был бы выгоднее. На плюсах всё-таки лучше делать числодробилки, а не генерилки html'ек, в которых от ЯП уже мало что зависит.
Речь идет об этом проекте?
При подходе, в котором используются виджеты, объекты, отвечающие за них, приходится хранить на сервере (иначе не получится сделать HTML-версию, аналогичную Ajax-версии). При использовании других языков возросли бы затраты ресурсов, которые пришлось бы выделять на сервере для работы с деревом виджетов. Собственно, это заметно по самому Wt: для каждой версии Wt выходит аналогичная версия jWt, написанная на Java; было замечено, что jWt оказывается примерно в 2 раза медленнее, чем release-версия Wt. Это может быть иметь значение при использовании на устройствах с ограниченными ресурсами.
В принципе, подобный подход применяется и в других библиотеках, написанных на других языках: Pyjamas (Python) и Google Web Toolkit (Java). Однако обе библиотеки не предоставляют HTML-версии, для ситуаций, когда JavaScript недоступен.
К числодробилкам часто хочется иметь веб-интерфейс. Написать его можно на том же языке, что и саму числодробилку (часто это как раз C/C++/Java). Причем задача генерации HTML перекладывается с разработчика на библиотеку: написание веб-интерфейса напоминает написание обычного графического приложения, например на Qt.
При подходе, в котором используются виджеты, объекты, отвечающие за них, приходится хранить на сервере (иначе не получится сделать HTML-версию, аналогичную Ajax-версии). При использовании других языков возросли бы затраты ресурсов, которые пришлось бы выделять на сервере для работы с деревом виджетов. Собственно, это заметно по самому Wt: для каждой версии Wt выходит аналогичная версия jWt, написанная на Java; было замечено, что jWt оказывается примерно в 2 раза медленнее, чем release-версия Wt. Это может быть иметь значение при использовании на устройствах с ограниченными ресурсами.
В принципе, подобный подход применяется и в других библиотеках, написанных на других языках: Pyjamas (Python) и Google Web Toolkit (Java). Однако обе библиотеки не предоставляют HTML-версии, для ситуаций, когда JavaScript недоступен.
К числодробилкам часто хочется иметь веб-интерфейс. Написать его можно на том же языке, что и саму числодробилку (часто это как раз C/C++/Java). Причем задача генерации HTML перекладывается с разработчика на библиотеку: написание веб-интерфейса напоминает написание обычного графического приложения, например на Qt.
Скорее про этот github.com/d5/node.native
Я использовал эту либу как раз для того, чтобы сделать сразу и GUI и веб интерфейс. В теории все было гладко и приятно. На деле пришлось воротить множество костылей, чтобы подружить Qt и Wt. В основном это было связано с тем, что они оба работают в mainLoop'ах.
Мне не доводилось писать общий код, из которого можно получить и Qt и Wt приложение. Так как их системы виджетов не связаны, а лишь похожи, сделать это сегодня будет нелегко. Разве что с кодогенерацией: заменять WPushButton на QPushButton и т.д., но не думаю, что так будут делать: классы всё-таки разные и не все методы одной библиотеки имеют аналог в дргой. Ситуацию мог бы исправить qt-backend для Wt, но его нет.
Если речь идет о приложении, которое было бы одновременно и Qt, и Wt-приложением (скажем, прикрутить веб-интерфейс на Wt к qbittorrent вместо того, что у него сейчас) — теоретически можно благодаря wtwithqt, но я этого не пробовал.
Если речь идет о приложении, которое было бы одновременно и Qt, и Wt-приложением (скажем, прикрутить веб-интерфейс на Wt к qbittorrent вместо того, что у него сейчас) — теоретически можно благодаря wtwithqt, но я этого не пробовал.
Для Qt полно движков, для чего вам понадобился Wt, который тянет еще Boost?
Я их упомянул. В обоих этих проектах требуется писать HTML руками. В обязательных зависимостях Wt только boost.
Я их упомянул.<.blockquote>
Действительно, прошу прощения.
В обоих этих проектах требуется писать HTML руками
А вот ту я не совсем понял, что вы имеете ввиду?
К примеру, в CppCMS очень удобный архитектура, а шаблонизатор сделан по типу Django.
Когда мы пишем шаблоны в Django, мы пишем при этом HTML (с надстройками, касающимися шаблонов: подстановки, условия, циклы и т.п.). То есть, без знания HTML проект на Django (или CppCMS) не сделаешь.
Кстати, в Wt тоже есть виджет, отвечающий за шаблоны. Так что если в каком-то месте удобнее писать HTML напрямую, это возможно.
Кстати, в Wt тоже есть виджет, отвечающий за шаблоны. Так что если в каком-то месте удобнее писать HTML напрямую, это возможно.
Как раз html в данном случае проще и эффективнее руками писать.
Писать HTML руками просто до тех пор, пока это простой HTML. А стоит столкнуться с элементами, которые по-разному поддерживаются браузерами, проще пользоваться библиотекой виджетов, которая снимает с разработчика необходимость следить за особенностями разных браузеров.
К примеру, для WSpinBox (поле для ввода числа) используется встроенная возможность браузера, если она доступна, в противном случае используется собственная реализация на JavaScript.
Для JavaScript проблему несовместимости браузеров можно решить при помощи JavaScript-библиотеки, например, jquery, а в данном случае решается проблема и для браузеров, в которых JavaScript недоступен.
Эффективность (скорость создания) HTML самописными генераторами может быть довольно высокой, но в случае Wt преимуществом будет использование Ajax, позволяющее генерировать не всю страницу, а лишь изменившуюся часть. Это хорошо продемонстрировано на этой странице: при прокрутке таблицы загружаются только необходимые ряды, а не вся таблица. В то же время, если JavaScript недоступен, таблица будет выводиться постранично.
К примеру, для WSpinBox (поле для ввода числа) используется встроенная возможность браузера, если она доступна, в противном случае используется собственная реализация на JavaScript.
Для JavaScript проблему несовместимости браузеров можно решить при помощи JavaScript-библиотеки, например, jquery, а в данном случае решается проблема и для браузеров, в которых JavaScript недоступен.
Эффективность (скорость создания) HTML самописными генераторами может быть довольно высокой, но в случае Wt преимуществом будет использование Ajax, позволяющее генерировать не всю страницу, а лишь изменившуюся часть. Это хорошо продемонстрировано на этой странице: при прокрутке таблицы загружаются только необходимые ряды, а не вся таблица. В то же время, если JavaScript недоступен, таблица будет выводиться постранично.
Демонстрашка медленная, несмотря на всю мощь нативной природы С++. Не видел ещё ни одной web-платформы на С++, которая бы демонстрировала хорошую отзывчивость. Решения с интерпретаторами и garbage-коллекторами работают как правило не хуже. Не движется веб-прогресс в сторону С++. Жаль. Хотя может оно и к лучшему.
Несколько долгие ответы (особенно, время на создание сессии) могут быть связаны с нагруженностью или удаленностью сервера, где запущены демострации. При тестах нетривиального приложения на локальном компьютере ответы получаются довольно быстрые.
Приведу здесь немного цифр. Были скомпилированы release-версии приложения и библиотеки. Былы включена запись времени, затраченного на стороне сервера, в лог (запись времени можно включить, если добавить в файл wt_config.xml:
В Ajax версии создание сессии состояло в нескольких относительно долгих запросах около 20 мс (загрузка jquery, стилей и других файлов, которые в Ajax приложение требуется загрузить 1 раз). Большинство дальнейших действий занимали меньше 1 мс (например, 0.4 мс).
В HTML версии время на каждое действие было чуть больше (2-3 мс). Думаю, это связано с тем, что нужно было перегенерировать всю страницу, а не её часть.
Тут речь идет о времени, потраченном одним из потоков выполнения сервера (их запускается по умолчанию 10, чтобы не было простоев, например в случае работы с БД).
Чтобы ускорить соединение с сервером, можно разрешить соединяться через WebSocket (
Приведу здесь немного цифр. Были скомпилированы release-версии приложения и библиотеки. Былы включена запись времени, затраченного на стороне сервера, в лог (запись времени можно включить, если добавить в файл wt_config.xml:
<log-response-time>true</log-response-time>). Затем я открывал приложение и делал несколько действий, приводящих к перерисовке части страницы.В Ajax версии создание сессии состояло в нескольких относительно долгих запросах около 20 мс (загрузка jquery, стилей и других файлов, которые в Ajax приложение требуется загрузить 1 раз). Большинство дальнейших действий занимали меньше 1 мс (например, 0.4 мс).
В HTML версии время на каждое действие было чуть больше (2-3 мс). Думаю, это связано с тем, что нужно было перегенерировать всю страницу, а не её часть.
Тут речь идет о времени, потраченном одним из потоков выполнения сервера (их запускается по умолчанию 10, чтобы не было простоев, например в случае работы с БД).
Чтобы ускорить соединение с сервером, можно разрешить соединяться через WebSocket (
<web-sockets>true</web-sockets> в настройках), если он доступен. Я не измерял ускорение, которое при этом получается, но на глаз всё движется мгновенно.
Такой командой у меня не собралось:
Собралось такой
g++ -lwt -lwthttp -lboost_signals hello.cpp -o helloСобралось такой
g++ hello.cpp -o hello -lwt -lwthttp -lboost_signalsЗарегистрируйтесь на Хабре, чтобы оставить комментарий
Wt, библиотека C++ для разработки веб-приложений