LINUX.ORG.RU

Helios Javascript framework and libraries


0

0

Доброго времени суток.

Хочу рассказать о проекте, над которым я сейчас работаю. За последние шесть месяцев он стал весьма объёмен, и мне уже сложно управиться одному, поэтому я буду рад, если найдутся люди, которым этот проект также окажется интересным, и которые пожелают присоединиться к разработке. С другой стороны, сейчас уже есть что показать.

Проект называется Helios Javascript framework and libraries (http://gna.org/projects/helios/ хотя страница давно не обновлялась). Первый релиз состоялся 14 февраля сего года.

Фреймворк helios предоставляет способ создания приложений написанных на javascript и запускаемых в броузере. Основная вещь, которую делает ядро helios'а --- это управление модулями и их зависимостями. Модуль --- это отдельный .js файл с кодом, который может быть подключен (included) к некоторому другому модулю. Программист начинает код приложения в модуле main.js, к которому он может подключить другие необходимые модули. Ядро helios'а загрузит все требуемые модули в броузер, распарсит их и проинициализирует в порядке зависимостей. В общем, это вполне обычная функциональнасть доступная на большинстве других платформ и отсутствующая в броузерном javascript. Также есть несколько дополнительных фич, таких как динамическая загрузка и выгрузка модулей.

С точки зрения броузера, есть index.html, который ничего не содержит, кроме включения скрипта с ядром helios'а, которое, в свою очередь, подключает модуль main.js и все его зависимости, и, наконец, запускает код.

Всё это дело работает полностью на клиентской стороне (я однажды видел солюшн, который предоставлял такую же функциональность с загруской модулей, используя ajax и таким образом требуя запущенного сервера, здесь не тот случай). Это также означает, что такое приложение может быть загружено в броузер с удалённого http сервера, как и обычная веб-страница.

Основная идея заключается в том, что появляется возможность создавать "богатые" веб-приложения, и при этом клиентский и серверный код оказываются полностью разделены (забудьте про ужасный javascript внутри html внутри php).

Helios поставляется с некоторыми полезными библиотеками, без которых было бы сложно создать приложение. Низкоуровневые библиотеки определяют такие объекты как Signal (реализация паттерна observer) и Property (который хранит значение, предоставляет геттер и сеттер, а так же Signal, посылаемый при изменении значения). Есть также несколько библиотек более высокого уровня, такие как math (расширяет объект Math некоторыми дополнительными объектами), color (предоставляет функции для манипуляций с цветом), canvas (сейчас содержит функции рисования некоторых примитивов, а в будущем будет также обеспечивать совместимость между различными реализациями в броузерах), и, конечно, уже традиционнная для JS фреймворков ;) библиотека под названием anime, которая предоставляет функции для создания различных типов анимации.

Сейчас я работаю над библиотекой виджетов (которая пока называется heliwidgets). На самом деле, остальные библиотеки, упомянутые выше, расширяются по мере необходимости в какой-то функциональности для heliwidgets, поэтому практически каждый объект из других библиотек используется где-то в heliwidgets. На сегодня в heliwidgets уже реализовано несколько стандартных виджетов, в их числе Frame, Button, Label, Glasscase, Table и Selector. Heliwidgets также включает в себя подержку движков (engines), которые осуществляют рендеринг виджетов. Сейчас есть только один движок, который использует canvas для рисования.

Я написал простой калькулятор с использованием heliwidgets для того, чтобы продемонстрировать, как приложение на helios работает и выглядит (на сегодня, оно правильно работает только под firefox, в опере некоторые виджеты рендерятся криво):

http://absens.org/helios/helioscalc/

Чтоб лучше понять, как устроено приложение для helios, я рекомендую ознакомиться с исходным кодом. Это может заинтересовать программистов. Так как пока нет документации по heliwidgets, я написал код для каклькулятора в виде "codecast" (подробно откомментированный код с объяснением библиотечных вызовов), что должно хорошо продемонстрировать основные возможности helios и его библиотек. Вы можете загрузить исходный код калькулятора (запакованного вместе с helios и библиотеками) отсюда:

http://absens.org/helios/helioscalc.tar.gz

Я бы ещё хотел продемонстрировать одну фичу библиотеки heliwidgets под названием свойства стиля (style properties). Она относится к движку (engine), то есть движок предоставляет некоторый граф (зависимостей) из style properties, а программист может переопределить некоторые свойства для каких-нибудь виджетов. Когда некоторое свойство переопределяется для некоторого виджета, все свойства, от него зависимые вычисляются заново, а все дочерние виджеты наследуют эти изменения. Например, изменяя свойство primaryColor виджета rootWidget на #112233, можно перекрасить приложение так:

http://absens.org/helios/helioscalc_dark/

Исходный код фреймворка и библиотек доступен под GPLv3. Если кому-либо проект покажется интересным, пишите на heliosframework в гмейле.

Сайт absens.org к проекту отношения не имеет, просто нужно было где-то выложить :)

Пока сумтно представляю зачем это нужно. Не могли бы Вы дать несколько конкретных юзкезов (примеров использования) для такой системы?

theos ★★★
()
Ответ на: комментарий от theos

Любая система, предполагающая клиент-серверную архитектуру реализованная в вебе (интерфейсы к почте, соц сети, вообще чему угодно). Я представляю себе клиент-сервер как два приложения, которые общаются друг с другом по протоколу. В нынешнем вебе пользователь всё же больше с сервером взаимодействует, а сервер генерит ему на каждый запрос новую страницу, которую броузер загружает, парсит и показывает. Несмотря на всякие аджаксы, ситуация сейчас именно так обстоит в основном.

И помимо этого, сейчас веб девелоперы очень много времени тратят на решение вопросов потипу "как сделать так, чтобы у бокса были скруглённые углы, а внутренний контент мог быть произвольного цвета, и чтоб всё работало под всеми броузерами". Мне кажется, мой подход более близок к системному программированию.

xpostman___
() автор топика
Ответ на: комментарий от theos

Ну и кроме того, хтмл уже изжил себя, он был хорош для гипертекста, а программы нужно всё-таки делать на языках программирования, а не разметки.

xpostman___
() автор топика
Ответ на: комментарий от xpostman___

>интерфейсы к почте, соц сети, вообще чему угодно

Программировать отдельно на JavaScript? Подход GWT мне кажется куда как разумнее. Если посмотреть контакт, гмейл - без "хтмл"я там всё равно не обойтись (если пишете именно под хтмл). А "калькулятор" в вёбе не нужен. Кстати. Ещё про построение RichClient - во-первых стоит посмотреть Eclipse RAP, во-вторых видел фреймворк, который умеет одновременно генерить DHTML И Flash. Я пока не вижу что конкретно ваша библиотека даёт.

theos ★★★
()
Ответ на: комментарий от theos

На мой взгляд, это очень существенное преимущество :) Хотя, с другой стороны флекс убирает проблему совместимости между броузерами. Я начал этот проект до того, как узнал о флексе (это было пару лет назад). И ещё в числе преимуществ в сравнении с флексом я бы выделил то, что мой подход "более непосредственный", откуда следует, например, меньшее потребление памяти и, возможно, большая скорость работы. Хотя, сейчас canvas очень медленный, надеюсь ситуация улучшится постепенно.

xpostman___
() автор топика
Ответ на: комментарий от xpostman___

>что мой подход "более непосредственный"

эээ?

>большая скорость работы.

Оочень сомневаюсь, учитывая заточенность флекса

theos ★★★
()
Ответ на: комментарий от theos

> Программировать отдельно на JavaScript?

да, именно так

> Если посмотреть контакт, гмейл - без "хтмл"я там всё равно не обойтись (если пишете именно под хтмл).

Вот, если мы пишем под хтмл. Не знаю, недостаток это или преимущество, но в приложении для helios хтмл вообще к использованию не предполагается.

Я, к сожалению, весьма поверхностно знаком с упомянутыми технологиями, но я хочу попробовать отойти от идеи писать код на каком-то языке, а потом неким транслятором всё это превращать в неудобоваримый DHTML + JS + flash + что угодно. Javascript очень гибкий и удобный язык, но пока ему негде было проявить свою мощь.

xpostman___
() автор топика
Ответ на: комментарий от theos

> >что мой подход "более непосредственный"

> эээ?

имеется в виду непосредственное написание js кода и отсутсвие дополнительных прослоек в виде флэша

xpostman___
() автор топика
Ответ на: комментарий от xpostman___

>Javascript очень гибкий и удобный язык

Тогда почему с него валят при разработке проектов больше "галереи фотографий"? GWT и все его последователи, Eclipse RAP, Charisma?

>в приложении для helios хтмл вообще к использованию не предполагается.

Ну я пока видел только калькулятор. Я мне бы что-то вроде GoogleReader.

theos ★★★
()
Ответ на: комментарий от theos

> Тогда почему с него валят при разработке проектов больше "галереи фотографий"?

Потому что из-за отсутствия нормального апи (DOM это ненормальный апи :) ) для проектов больше галереи с фотографиями код превращается в crap (по-русски не знаю такого меткого слова). Либы гелиоса как раз и предполагается что предоставят такой апи.

> Ну я пока видел только калькулятор.

Ну я пока написал только калькулятор, уж извините :) За тем я сюда этот тред и запостил.

xpostman___
() автор топика
Ответ на: комментарий от theos

> >дополнительных прослоек в виде флэша

> Флэш не прослойка а другая платформа.

Тогда, может быть, в связке "приложение - флэш - броузер" лишним является броузер?

xpostman___
() автор топика
Ответ на: комментарий от xpostman___

>Потому что из-за отсутствия нормального апи

А чего в jQuery не хватает?

>Тогда, может быть, в связке "приложение - флэш - броузер" лишним является броузер?

Ну почему же, он рисует привычные пользователю рамочки с кнопками "закрыть" и "свернуть" =)

theos ★★★
()
Ответ на: комментарий от theos

> А чего в jQuery не хватает?

jQuery облегчает работу с DOM, DOM предоставляет интерфейс по манипуляции HTML, HTML определяет разметку веб-страницы. Здесь опять всё завязано на HTML и на том факте, что есть страница. Это далековато от программирования приложения.

xpostman___
() автор топика
Ответ на: комментарий от xpostman___

>jQuery облегчает работу с DOM,

Ну вот не надо, jQuery действительно поднимает уровень абстракции и привносит понятия виджетов и действий с ними связанных. Можно было бы добавить к этому расстановку их тоже на jscript но даже не вижу в этом особого смысла. Вы не спрячете глубоко HT<ML - всё слишком уникально, а общее имеют только калькуляторы. ПОсмотртие на google reader, gmail. Да и не понимаю зачем его вообще прятать. Такие прятки не могут быть самоцелью.

theos ★★★
()
Ответ на: комментарий от theos

Я не прячу никуда хтмл. Единственное взаимодействие с DOM, которое происходит --- это то, что каждый виджет генерится на своём слое. Кстати, у меня была мысль сначала сделать один большой canvas и всё рисовать внутри него, но это оказалось гораздо медленнее, и, кроме того, некоторая его функциональность (отображение одного канваса в другом) не реализована в гугловской exCanvas, которую я расчитываю оформить в виде модуля для гелиоса.

В heliwidgets для разметки предоставляется апи, который, на мой взгляд гораздо удобнее для приложений. Он описан в комментах к include/heliwidgets/Geometry.js, хотя, Вы, скорее всего не будете туда заглядывать (мне бы было лень на Вашем месте :) ), ну да это и не так важно.

xpostman___
() автор топика
Ответ на: комментарий от theos

Почитал код калькулятора. Китайский метод программирования ужасает. Особенно при том, что вроде всё добросовестно закомментировано - то есть времени уделено не мало. Скажите действительно циклы не возможны?

Если бы не это, то смотрится ничего. Но задание таким способом лэйаута хотя в таком варианте и смотрится неплохо - не уверен что это подойдёт для действительно сложных конструкций (Протмер из Eclipse RAP : http://ondemand.yoxos.com/geteclipse/start ), тем более что лэйаут при помощи html хорошо изучен и для него уже много готовых тулзов.

theos ★★★
()
Ответ на: комментарий от theos

> Китайский метод программирования ужасает.

что именно?

> Скажите действительно циклы не возможны?

где именно? =)

> Но задание таким способом лэйаута хотя в таком варианте и смотрится неплохо - не уверен что это подойдёт для действительно сложных конструкций

Для действительно сложных конструкций я ещё создал виджет Table, он должен дополнить объект Geometry в тех случаях, где его штатных возможностей не хватает.

> Протмер из Eclipse RAP : http://ondemand.yoxos.com/geteclipse/start

Что есть протмер? Страница подвесила бровзер на полминуты, наверное у меня машина слабовата :( Я не увидел там ничего такого, что нельзя сделать с помощью Geometry & Table, и даже ничего такого, что на хтмл делалось бы более быстро/удобно чем с помощью объектов из heliwidgets.

> лэйаут при помощи html хорошо изучен и для него уже много готовых тулзов.

Согласен, мышой удобнее создавать лейаут нежели чем кодом. Но редактор лейаута дело наживное, я как раз для того и сделал поддержку инициализирующих структур, чтоб их можно было вынести в отдельный скрипт и в перспективе рисовать редактором.

xpostman___
() автор топика
Ответ на: комментарий от theos

> Скажите действительно циклы не возможны?

а, это речь о вешаньи евентов на кнопки в конструкторе калькулятора? циклом это описать не сложно:

for ( var i = 0; i <= 9; i++ ) { this["button" + i].sigPushed.listen( function(){ this.handleDigit( i ) }, this ); }

действительно так гораздо компактнее, но я утверждаю, что такой код гораздо менее читаем, чем то, как написано у меня.

Вообще, весь этот калькулятор не имеет свой целью продемонстрировать, как нужно писать код. Я лишь хочу продемонстрировать апи библиотек.

xpostman___
() автор топика
Ответ на: комментарий от xpostman___

tl;dr

>Ну и кроме того, хтмл уже изжил себя

Дальше можно и не читать :}

Deleted
()
Ответ на: комментарий от xpostman___

> >Ну и кроме того, хтмл уже изжил себя

> Дальше можно и не читать :}

Сразу видно, мы на лоре :(

> > Скажите действительно циклы не возможны?

theos, здесь Вы правы, а не прав я. действительно тут нужно писать циклом, а я написал без цикла, потому что мне было лень придумывать, как организовать перебор по всем цифрам от 0 до F, и ещё я хотел побыстрее всё закончить и выложить, а также, видимо, возымел своё действие литр туборга, использовавшийся при написании данного калькулятора =) сейчас я вижу что два ассоциативных массива решили бы эту проблему, а также позволили бы конвертировать цифру в значение и обратно (у меня это сделано с помощью двух соотв. функций), но тогда мне эта идея не пришла в голову.

в общем, калькулятор - это просто демка, я буду очень признателен, если мне кто-нибудь выскажет подобные комментарии по поводу кода в каталоге include/

на самом деле, я регулярно нахожу похожие идиотизмы в своём коде, который пересматриваю или дополняю через несколько месяцев после написания :(

xpostman___
() автор топика
Ответ на: комментарий от ce_tamotko_za_uzori

> А ты не Ext JS изобрёл?

Ext JS тоже ведь DOM-ориентирована, насколько я знаю. мб есть аналогия в плане виджетов, я же думаю, что может получиться что-то интересное, если не заморачиваться на DOM и писать на чистом JS. Посмотрим, во что это выльется..

xpostman___
() автор топика
Ответ на: комментарий от xpostman___

>сейчас я вижу что два ассоциативных массива решили бы эту проблему

Дадада, именно их я и имел ввиду =).

Но на самом деле лично мне это затея не нравится во-первых тем, что я не люблю динамику, ибо она от слабой выразительности языка. Вот если бы вы такое на Jetbrains MPS замутили - да, было бы очень даже не плохо. Во-вторых - тот-же файрбаг покажет мне именно ДОМ, а не ваш джаваскриптовый код, и это тоже, на мой взгляд, существенный минус.

Как кстати у вас с динамическим изменением лэйаута - насколько всё просто?

theos ★★★
()
Ответ на: комментарий от theos

> Во-вторых - тот-же файрбаг покажет мне именно ДОМ, а не ваш джаваскриптовый код, и это тоже, на мой взгляд, существенный минус.

В фаербаге вкладочка скрипт покажет js код, позволит выбрать в списке нужный модуль, расставить где нужно брейпоинты, в-общем, всё как положено. Дом он конечно тоже покажет, но он уже будет не так существенен.

> Как кстати у вас с динамическим изменением лэйаута - насколько всё просто?

Примерно как-то так:

myWidget.geometry.set({
    left : 10, top : 20, right: 30, bottom: 50
});

перерисует myWidget в новом месте и также перерисует все его дочерние виджеты, если их геометрия указана, например, в процентах. Кстати у geometry тоже есть сигнал-нотификатор, на который можно подписаться если нужно.

У виджета Table есть некоторые свои методы, упрощающие манипуляцию с ячейками таблицы. Этого нет в codecast с калькулятором, поэтому я приведу краткое описание его апи здесь. Сейчас Table представляет с собой пустой (в плане графики) виджет с некоторым дочерними виджетами, упорядоченными одномерно (то есть либо по-вертикали, либо по-горизонтали). Это определяется его свойством layout. Кстати говоря, основные свойства виджетов --- это наследники объекта js.Property, о котором я писал в первом мессадже, и поэтому если программист пишет, например, myTable.layout.set( "vertical" ), тогда по сигналу вызовется некоторый метод объекта, который обновит геометрии его ячеек, согласно новому лейауту, и так же вызовется метод, описанный уже в движке, который всё что нужно перерисует. Эти методы подписываются на сигнал в конструкторе. И, конечно, программист может повесить на этот сигнал какие-то свои действия.

Table предоставляет необходимые методы для манипуляций с ячейками (addCell, resizeCell, removeCell, switchCells, moveCell). Размер каждой ячейки м.б. задан либо абсолютно (в пикселах), либо относительно (в процентах), в этом случае такие "резиновые" ячейки таблицы растягиваются пропорционально указанному их значению в процентах так, чтобы заполнить всю ширину (высоту) таблицы.

Виджет Table задумывался как раз для того, чтобы можно было создавать лейауты, подобные тому, на который Вы сослались (из Eclipse RAP). Пользуясь только лишь свойством geometry было бы действительно сложновато создавать сложные лейауты.

Вообще, при написании либов я пытался исходить из простоты (программного) интерфейса, то есть обычно я сначала представлял (а часто даже писал) код, который пользуется каким-то компонентом, а потом уже думал что отсюда следует и как писать этот компонент.

> Вот если бы вы такое на Jetbrains MPS замутили - да, было бы очень даже не плохо. 

К сожалению, не знаком с Jetbrains MPS и не владею джавой. Про динамику и выразительность языка --- это вопрос скорее философский, и наверное можно бесконечно его обсуждать. Я снова приведу в качестве примера объект js.Property, поскольку, как мне кажется, он очень хорошо демонстрирует динамику и выразительность языка: реализация подобной функциональности на том же C++ требует в разы больше кода. И, поэтому, да: если говорить о JS, то, на мой взгляд, выразительность этого языка как раз и заключается в его динамике.

xpostman___
() автор топика
Ответ на: комментарий от xpostman___

> Я снова приведу в качестве примера объект js.Property

прошу прощения, имеется в виду js.Signal, конечно же. Речь идёт о возможности посылать сигнал так, чтоб подписавшееся на него функции получали произвольное число аргументов

xpostman___
() автор топика
Ответ на: комментарий от xpostman___

>Сразу видно, мы на лоре :(

Просто это слишком категоричное утверждение. А альтернатива HTML'у только поделки вроде флеша и явы. Нет уж, уж лучше пусть HTML, а ява может и десктопным приложением быть сама по себе, если очень хочет.

Deleted
()
Ответ на: комментарий от xpostman___

Пригляделя к лэйауту калькулятор. Да он у вас ручной о_О Скажите, а нельзя что бы было просто - сказал GridLayout 8х5 а потом навставлял в цикле кнопок - и они бы правильно расставились?

theos ★★★
()
Ответ на: комментарий от xpostman___

>прошу прощения, имеется в виду js.Signal, конечно же. Речь идёт о возможности посылать сигнал так

Так вы и не выражаете такую конструкцию. Всё на что способен язык "сделать так, чтоб работало". Рефакторинг, валидация, комплишн идут найух. А всё это очень нужно, особенно для тех, кто не автор этого фреймворка. Вот в MPS это всё делается тривиально, с поддержкой всего того что я описал. Очень советую приглядеться - к реализации этого на MPS я бы присоединился.

theos ★★★
()
Ответ на: комментарий от Deleted

> А альтернатива HTML'у только поделки вроде флеша и явы.

Нунуну. Зря не порчитали - автор не предлагает откзаться от HTML. Он предлагает построить более удобное АПИ надо DOMом и минимизировать код разметки на HTML за счёт генерации его в рантайме джаваскриптом.

theos ★★★
()
Ответ на: комментарий от theos

Так от этого HTML никуда не исчезает. А автор пишет «хтмл уже изжил себя». Что есть ложь выходит, ибо он полагается на него.

К тому же, интерфейс, который не работает без JS это фейл.

Deleted
()
Ответ на: комментарий от Deleted

>А автор пишет «хтмл уже изжил себя». Что есть ложь выходит, ибо он полагается на него.

Ну это конечно не очень корректно, но схоже фразе "ассемблер изжил себя" - вобщем то без него никуда - любой компилятор транслирует программу в асм, но на асме писать хреново. Скорее всего имеется ввиду использование HTML непосредственно для вёрстки интерфейса вёб-приложения.

> тому же, интерфейс, который не работает без JS это фейл.

И у скольки реально отключен JScript? (кроме красноглазых с лора). Да, у те кто ставят NoScript могут его включать на этом сайте. И да, можно проовать генрировать JScript на "сервере" и отдавать статику (урезанную).

theos ★★★
()
Ответ на: комментарий от theos

>Ну это конечно не очень корректно, но схоже фразе "ассемблер изжил себя" - вобщем то без него никуда - любой компилятор транслирует программу в асм, но на асме писать хреново.

Но ты то на асме не пишешь при этом (если только очень не надо), а автор прямо использует HTML.

>И у скольки реально отключен JScript? (кроме красноглазых с лора). Да, у те кто ставят NoScript могут его включать на этом сайте. И да, можно проовать генрировать JScript на "сервере" и отдавать статику (урезанную).


Юзабилити это такая штука, я тебе скажу…

А потом говорят, мол, это у тебя во вкладках сайт с тяжёлым js, а не Firefox тормозит…

Deleted
()
Ответ на: комментарий от theos

> Пригляделя к лэйауту калькулятор. Да он у вас ручной о_О Скажите, а нельзя что бы было просто - сказал GridLayout 8х5 а потом навставлял в цикле кнопок - и они бы правильно расставились?

Можно, я даже думал так и сделать, но потом решил оставить как есть, чтоб показать аналогию с ресурсом. Калькулятор --- это редкий пример, когда виджеты можно расставить в цикле. GridLayout возможно интересная мысль, она не реализована, и я сходу пока не могу придумать, как её "эргономично" вписать в общий апишный контекст.

> Так вы и не выражаете такую конструкцию.

Более конкретно, я имел в виду возможность послать сигнал так:

mySignal.send( arg1, arg2, arg3, whatever );

и получить все эти аргументы на входе подписавшихся функций.

> Рефакторинг, валидация, комплишн идут найух. А всё это очень нужно, особенно для тех, кто не автор этого фреймворка.

Не могли бы вы пояснить, каким именно образом фреймворк препятствует всему этому? (если на секунду предположить, что он уже достаточно полный для продакшна и прилогается вся необходимая документация по апи)

Про валидацию --- в ядре гелиоса я сделал небольшой лог, куда отправляются сообщения об отсутствующих модулях, о циклических зависимостях и прочем. Этот лог можно потом прочитать, кажется, через heliosKernel.errorLog, хотя могу ошибаться. Это описано в туториале на сайте проекта. У меня была мысль приспособить этот лог каким-то образом и к поимке исключений в коде. Например, сейчас если подписать на сигнал несуществующую функцию, тогда, при попытке послать сигнал, в лог JS ошибок броузера вывалится какое-то сообщение из серии signal.listeners[ 0 ][ i ] is undefined, это действительно очень усложняет отладку. Пока такая валидация (если я правильно понял, что Вы подразумеваете под валидацией) не реализована, и основная здесь причина даже не в том, что я не успел ещё это сделать, а в том, что при разработке мне пришлось столкнуться с некоторыми вещами, в которых я, увы, слабо разбираюсь. Иногда для обеспечения некоторой функциональности мне приходится полагаться на интуицию, а через некоторое время я обнаруживаю, что этот вопрос уже давно решён, а моя реализация примитивна и вообще некорректна. Это относится к валидации, и, вероятно, к рефакторингу.

Комплишн --- это тот вопрос, который должен решаться редактором кода?

Про MPS почитал на сайте, с их концепцией Language-oriented programming я и вовсе не знаком, поэтому пока ничем подобным заниматься не планирую. Но Вы можете портировать туда код, исходники ведь открыты ;)

Ещё хотел бы в очередной раз пару слов сказать о тёрке вокруг ХТМЛ. Мне довольно часто приходится идти на компромиссы между функциональностью/скоростью, функциональностью/портируемостью и функциональностью/ясностью апи. Сейчас helios представляет собой то, что показано на демке с калькулятором. Вопрос о поддержке того же самого, но с отключенным JS как минимум не корректен. Роль HTML & DOM в helios (точнее, в реализации движка для heliwidgets) была зафиксирована довольно давно. Ничто не мешает сделать движок для heliwidgets, который будет рендерить виджеты, скажем, в какой-нибудь апплет с флешом, сообщаясь по LocalConnection. Я выбрал один способ, который наиболее удобен или интересен лично мне, и сейчас развиваю его. Гелиос просто предоставляет возможность логически связать модули друг с другом, разделить код на части. Тулкит heliwidgets определяет только лишь логику виджетов и их апи. Остальное --- задача движка, который отслеживает, что происходит с виджетом как объектом в JS и применяет соответствующие изменения на экране.

xpostman___
() автор топика
Ответ на: комментарий от Deleted

> а автор прямо использует HTML.

неправда :) я использую домовский апи, он из JS юзабельнее:

var newLayer = document.createElement( "div" );
newLayer.style.bla = "bla";
newLayer.style.bla2 = "bla2";
...
someExistingLayer.appendChild( newLayer );

хотя сути это, конечно, не меняет =)

xpostman___
() автор топика
Ответ на: комментарий от xpostman___

>я использую домовский апи

А он, по вашему, что ли через астрал работает? Это и есть прямое использование HTML'а — создание его элементов :) Вот если бы создавалось что-то другое…

Я не document.write() имею в виду, естественно.

Deleted
()
Ответ на: комментарий от Deleted

> Вот если бы создавалось что-то другое…

Что другое? у Вас есть идеи? Я уже упоминал в постах выше, что у меня была мысль сделать один огромный канвас и рисовать на нём без хтмл. Я даже написал небольшую либу, которая добавляет в канвас поддержку слоёв и ловет мышиные евенты, определяя слой. В принципе, думаю, за пару вечеров можно переписать движок под него. Но, видимо, сейчас хтмл гораздо лучше в броузерах оптимизирован, чем canvas. Только по этой причине дефолтный и единственный движок для heliwidgets использует хтмл. а вообще он здесь не принципиален, никаких хтмльных фич (типа табличного лейаута) не используется. Я даже может быть кого-нибудь удивлю, но вся произвольно задаваемая геометрия для виджетов считается и конвертится в абсолютные координаты "top-left-width-height" внутри JS кода, такая нотация гарантированно однозначно воспринимается самыми копризными эксплорерами.

xpostman___
() автор топика
Ответ на: комментарий от xpostman___

>Не могли бы вы пояснить, каким именно образом фреймворк препятствует всему этому?

Этому припятсвует язык и способ его использования. Логи - это хорошо. Но с учётом того, что нормально простро AST невозможно, то всё то что я написал - то же невозможно, за исключением нескольких тривиальных случаев. Подскажите хоть один редактор, который позволяет всё это с вашей библиотекой.

>Но Вы можете портировать туда код, исходники ведь открыты ;)

Это бессмысленно. Работа в LOP очень сильно меняет сам процесс разработки и то что получается.

theos ★★★
()
Ответ на: комментарий от xpostman___

>mySignal.send( arg1, arg2, arg3, whatever );

Ещё раз, вы делаете "так чтоб работало", а не так, что бы компилятор понял что вы написали. Он этого не понимает.

>Калькулятор --- это редкий пример, когда виджеты можно расставить в цикле.

Дело не "в цикле" а вообще в нормальных лэйаутах. Именно человеческих лэйаутов и хочется - вы же планирует писать "вёб-_приложения_".

theos ★★★
()
Ответ на: комментарий от Deleted

> Вот если бы создавалось что-то другое…

Лично я бы был очень доволен прикрученным плагином к бразеру Qt с Declarative UI. Мне кажется это было бы очень круто.

theos ★★★
()
Ответ на: комментарий от xpostman___

Внезапно

>Что другое? у Вас есть идеи?

Я быть может кого-то удивлю, но фразу «хтмл уже изжил себя» сказали здесь вы.

Deleted
()
Ответ на: комментарий от xpostman___

>Я уже упоминал в постах выше, что у меня была мысль сделать один огромный канвас и рисовать на нём без хтмл.

Выделение текста не будет работать? Такое в вебе не нужно́.

>а вообще он здесь не принципиален, никаких хтмльных фич


DIV и style это тоже не из астрала.

Deleted
()
Ответ на: комментарий от theos

> Лично я бы был очень доволен прикрученным плагином к бразеру Qt с Declarative UI. Мне кажется это было бы очень круто.

Если я правильно понимаю, Вы имеете в виду делегировать рисование виджетов броузеру? У меня была такая мысль, это кстати легко делается. Броузер просто должен предоставть свой движок (как джаваскриптовый объект с необходимым интерфейсом), а программист --- разрешить его использовать, в случае если таковой есть. Тогда можно рендерить виджеты на чём угодно, хоть на gtk/qt.

theos, я вижу что Вы знакомы с некоторыми интересными концепциями, с которыми не знаком я, и поэтому я иногда не понимаю, что Вы имеете в виду. Моя позиция заключается в том, что есть фреймворк с либами на js для броузера, Вы имели возможность с ним ознакомится. Понятно, что и броузер, и язык накладывают всевозможные ограничения, но давайте всё-таки будем исходить из того, что имеем. Конструкции языка добавлять на лету, увы, не получится. Это наверное минус и всё же. Я попытался сделать максимально удобный/функциональный апи, при этом я исходил из своих субъективных соображений. Наверняка я что-то упустил. Если у Вас есть идеи, относительно того, как можно улучшить или сделать более удобным этот фреймворк, я буду очень благодарен, если Вы эти идеи выскажете. Я имею в виду, конечное, идеи помимо смены платформы =)

xpostman___
() автор топика
Ответ на: комментарий от xpostman___

Ну вот собственно тогда z бы хотел что бы вы посмотрели QML - http://labs.trolltech.com/blogs/2009/05/13/qt-declarative-ui/

Было бы здорово натыреть оттуда разных фич, потому как у вас есть с ним схожесть - только он работает на базе Qt, а вы - на базе браузера. ПО крайней мере мне там вкусно следующие:

1)Лэйауты 2)MVC, где модель может быть как кастомная, так и (вот это меня очень пропёрло) создаваемая из XPath запросов на XMLном источнике. 3)State Machine + custom transform - автоматы очень удобны для программирвания UI

theos ★★★
()
Ответ на: комментарий от xpostman___

Ну вот собственно тогда z бы хотел что бы вы посмотрели QML - http://labs.trolltech.com/blogs/2009/05/13/qt-declarative-ui/

Было бы здорово натыреть оттуда разных фич, потому как у вас есть с ним схожесть - только он работает на базе Qt, а вы - на базе браузера. ПО крайней мере мне там вкусно следующие:

1)Лэйауты
2)MVC, где модель может быть как кастомная, так и (вот это меня очень пропёрло) создаваемая из XPath запросов на XMLном источнике.
3)State Machine + custom transform - автоматы очень удобны для программирвания UI

theos ★★★
()
Ответ на: комментарий от theos

> Ну вот собственно тогда z бы хотел что бы вы посмотрели QML

спс, посмотрел видео, в ближайшее время постараюсь почитать про эти технологии. предварительно, я думаю, что если эта функциональность может быть реализована поверх Geometry (точно так же как Table поверх него реализована), тогда я покамест на это забью и м.б. займусь позже. сейчас для меня главное определить актуальность проекта и если она достаточная, тогда привлечь ещё народ. с актуальностью самое сложное: я девелопил гелиос практически один, и среди моих знакомых прогеров толково разбирающихся в вопросе нет. я ещё иногда получал комментарии из серии "О! офигительно! мега круто!", от такого фидбэка, понятное дело, тоже никакого толку нет :) а моё личное мнение слишком уж субъективно.

думаю сегодня-завтра запостю новость о проекте.

>> include( "combintation.js" );

> Для подключения модулей в js есть своя спецификация

спасибо, не слышал, почитал, не понравилось почему-то :) я старался сделать как можно более аналогичным образом с обычным инклюдом, по-моему в моём варианте всё куда проще. и ещё:

> var inc = require('increment').increment;

чересчур многословно, если нужна всего одна функция из модуля, то да, так удобнее. а если больше - каждый раз писать require придётся и создавать новую переменную. имхо, какая-то недопродуманная спецификация.

xpostman___
() автор топика
Ответ на: комментарий от xpostman___

А на хабре запостить не хочешь? Там аудитория немаленькая, вёб-девелоперов много.

theos ★★★
()
Ответ на: комментарий от xpostman___

И да, вам нужно лучше продавать свою разработку. Фразами типа "хтмл нинужен" никого не привлечешь. Стоит чётко писать для какой аудитории, для работы с чем у вас будут какого рода профиты. Потому как в вашем описании это совершенно не читается, а народу лишний раз вникать в многабукафф просто так (не ожидаю для себя профита) неохота.

theos ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.