> Значит ли это, что порядок подключения модулей играет роль?
Модули инициализируются в порядке зависимостей. Если Вы указываете, что модуль c.js требует a.js и b.js, тогда ядро гелиоса гарантирует, что init() в a.js и b.js будет запущен раньше, чем init() в c.js, но не более того. Предполагается, что в a.js и b.js Вы определяете какие-то объекты, которые используются в c.js. Конечно, инициализирующие функции в модулях a и b вызываются по очереди, я даже могу сказать, что в простом случае они будут вызваны в том порядке, в котором они инклудятся. Но не нужно этот факт использовать для всяких хитростей. Честно говоря, я не вижу смысла в упомянутых Вами манипуляциях (с практической точки зрения). И, кроме того, если модуль b.js был подключен (востребован) где-то ранее, и уже был инициализирован, то он не будет инициализироваться повторно. Таким образом порядок может нарушиться.
> Но как быть с отложенной загрузкой модулей в такой ситуации?
Я здесь не писал, но в гелиосе есть поддержка динамической загрузки (и, кстати, выгрузки) модулей по требованию. Для этого используются функции load() и unload(). В какой-то момент Вы говорите load(a.js) и ядро подключает этот модуль (вместе с его новыми зависимостями) и так же инициализирует. unload() действует в обратную сторону, но при этом оставляет загруженными те модули, которые используются где-то ещё. Об этом подробно написано в туториале по ядру на домашней страничке.
>> Есть так называемые «свойства стиля», которые наследуются по виджетам и зависят ещё и друг от друга.
> Как описывается это взаимодействие? Явно (constraints) или неявно (destructive update)?
Я не знаком с такими понятиями и не очень понимаю, что значит «явно» и «неявно», так что приведу пример. Но прежде скажу пару слов о том, как устроена библиотека heliwidgets. Сам тулкит содержит объекты (Button, Label, etc) для виджетов, которые обладают некоторым интерфейсом. В этот интерфейс входят т.н. свойства виджетов (надпись на кнопке, ориентация «селектора» — горизонтальный или вертикальный, геометрия — обратите внимание, что она относится не к «свойствам стилей», о которых ниже), различные сигналы, извещающие о том, что, например, кнопка нажата, и некоторые методы (например, добавить новый элемент в селекторе). Никакого кода по отображению виджетов на экране и по взаимодействию с броузером (поимка сообщений о нажатии кнопки мыши, например), в этих объектах нет. Такими вещами занимается движок (rendering engine), который полностью отделён от логики виджетов. Сейчас единственный существующий движок использует canvas для отрисовки виджетов на экране, это то что Вы видели на демке с калькулятором. В принципе, ничто не мешает сделать движок, который будет рендерить виджеты, например, во флэш-апплете, сообщаясь через LocalConnection. Или даже можно написать плагин для фаерфокса, который будет предоставлять некоторый js объект с интерфейсом движка для heliwidgets, который будет рендерить виджеты используя десктопный тулкит, хоть тот же GTK, это наверняка будет работать быстрее. Так вот на самом деле, упомянутые свойства стиля (StyleProperty) — это сущность, которая относится к движку. Совокупность свойств стиля можно воспринимать как «скин» для конкретного движка. Движок сам определяет, какие свойства стиля у него есть. Например, в helianthus (это так называется единственный пока написанный движок) есть свойства стиля, которые определяют основной цвет, цвет подсветки, цвет тени (которые зависят от основного, но их можно переопределить), и есть ещё, например, «извратное» свойство стиля cornerRoundness, которое определяет радиус закругления углов во всех прямоугольных объектах. Вот почему геометрия не относится к свойствам стиля, а относится к самому тулкиту. Наследование по виджетам нужно вот для чего. Например, есть виджет Frame (прямоугольная рамка с виджетами внутри). И если ей установить какое-нибудь свойство стиля, например цвет тени, то это изменение будет так же применено и ко всем внутренним виджетам, потому что это логично, и это поведение, которое ожидает получить программист.
> Только вот пока документации нет, заставлять читать код было бы нехорошо. :)
В архиве с калькулятором (линк на дом.страничке) есть ридми, в котором кое-что сказано, а вообще калькулятор писался как codecast, то есть это с одной стороны реально работающее приложение, которое можно запустить, а с другой — если открыть исходник, то комментарий представляет собой по сути документацию, где есть описание с самого начала всего, что происходит, и где подробно объяснён каждый вызов, что он делает и какие у него параметры. Так что рекомендую всё же.
В IE нету canvas'а, через который виджеты рендерятся в единственном существующем движке для heliwidgets. Планируется оформить гугловский excanvas в виде модуля для гелиоса, чтоб обеспечить эмуляцию через VML или Silverlight. Пока не сделано.
> > The main idea of the project is to provide a way for creating rich web applications with client and server code being completely split (forget that painful javascript inside html inside php).
> Хорошая идея, но такое уже есть в qooxdoo. :)
Кстати, qooxdoo на мой взгляд самый близкий проект к тому, чем я занимаюсь. На самом деле, узнал о нём совсем недавно :) Но вот хоть будет с кем поконкурировать, надеюсь это пойдёт обоим на пользу. И, да, в qooxdoo есть настоящий безсерверный инклюд, как у меня? ;) Тут же:
> А как же оно тогда работает?
Оно работает полностью на клиенте, в этом то и фишка. Можете загрузить кодкаст с калькулятором, раззипить и открыть в броузере index.html у себя на локальной машине без всяких серверов. В самом index.html нет ничего, кроме реквеста подгрузить kernel.js. Это ядро, и единственный скрипт, не являющийся модулем для гелиоса. там происходит много всяких таинственных вещей, но вкратце — первым делом подключается main.js (где программер начинает свой код). в каждом модуле есть набор инклюдов в шапке, и функция init(). ядро сначала подключает все эти скрипты (создавая объект <script> в ДОМе), составляет граф зависимостей, а потом в обратном порядке вызывает инициализаторы для каждого модуля. Но это очень упрощённо, на самом деле там ещё есть всякие навороты потипу динамической загрузки/выгрузки модуля и всех зависимостей, отслеживание циклических зависимостей и пр.
> Qooxdoo, YUI, Dojo+Dijit, jQuery UI.
Про куксду сказал выше, про остальное — честно, я не специалист по этим вещам, только лишь читал некоторые описания. Знаю, что, например подходы GWT и Eclipse RAP предлагают юзать джаву в IDE со всеми наворотами языка и фичами среды разработки, а потом всё это транслируется в HTML+JS+CSS+PHP+чтоугодно. Eclipse RAP, кстати, использует тот же куксду для виджетов в клиенте.
Ещё хочу сказать про DOM. Это — наполовину ответ на вопрос выше, и наполовину — на следующий:
> Как обстоят дела с модульностью и аддитивностью? Хочется, чтобы, например, CSS можно было бы задавать для каждого виджета *отдельно*…
Взаимодействие с DOM я постарался исключить полностью. Наличие как такового «документа» накладывает существенные ограничения. Возможно, чересчур опрометчиво с моей стороны, но с точки зрения разработчика на гелиосе — нет ни CSS, ни DOM. Лучше всего это увидеть, посмотрев код. Есть так называемые «свойства стиля», которые наследуются по виджетам и зависят ещё и друг от друга. Например, можно поменять цвет тени для какого-то фрейма, тогда он поменяется и у дочерних виджетов. Вот ещё пример: поменяв свойство primaryColor у виджета rootWidget на #112233 в калькуляторе, можно заставить его выглядеть так:
об этом есть на дом. страничке, но повторюсь ещё раз — покуда нет документации и покуда я не умею «грамотно составлять рекламные проспекты» :) лучше всего читать код, чтоб понять идею.
> В CSS бывает так, что, наложив один хак, ломается что-нибудь совсем в другом месте. И в JS тоже бывает. Как с этим быть? :)
Одна из задумок как раз в том и заключается, что программист должен писать программу, а не придумывать очередной хак, а потом пытаться сделать так чтоб всё остальное не поломалось :) по идее, это всё должны взять на себя библиотеки гелиоса.
я не думал над этим. пока никакого экспорта библиотек на что-то другое не планируется. я не думаю, что когда-то этим займусь, здесь процесс разработки несколько иной. сейчас в вебе на клиенте всё завязано на DOM. здесь же предполагается, что программист имеет дело только лишь с интерфейсом объектов из библиотек. DOM относится к концепции «документа», а не приложения. с его помощью и с помощью известных фреймворков легко и элегантно решаются задачи из серии «возьмём все чётные ячейки таблицы и поменяем у них фон». здесь же предлагается более системный подход. почитайте кодкаст калькулятора, там продемонстрирован процесс разработки приложения для helios (линк на домашней страничке). я пытаюсь приблизить веб-разработку к системному программированию и к решению действительно интересных задач, и уйти от траты времени на решением проблем с css и межброузерной совместимостью.
Я попытался реализовать некоторые мои идеи, которых, на мой взгляд, очень не хватало для толковой разработки. На домашней страничке есть подробный дескрипшн. Вкратце: основная идея — это разделение клиентской и серверной части веб-приложения. Юзер один раз загружает целиком приложение, которое по мере надобности общается с сервером посредством ajax. На сервере кто-то отвечает, например набор пхп-скриптов, но эти скрипты уже не занимаются генерацией лейаута, а просто передают необходимую информацию. Классический клиент-сервер.
Helios относится как раз к клиентской части, это то, что будет юзеру выдаваться в начале сессии. Heliwidgets как таковой немножко не относится ко всем этим делам между клиентом и сервером, наверное это скорее даже отдельный проект, библиотека виджетов для helios. Но пока я их не разделяю.
Документация естественно планируется, пока не успел.
Само ядро фреймворка содержит только то, что мне нужно — возможность делать include. Всё остальное — библиотеки.
С Heliwidgets у меня тоже связано много разных идей, которые я постепенно буду воплощать. Эта демка ещё далека до продакшна и даже до альфы, имеет своей целью привлечь тех, кому это м.б. интересно.
Модули инициализируются в порядке зависимостей. Если Вы указываете, что модуль c.js требует a.js и b.js, тогда ядро гелиоса гарантирует, что init() в a.js и b.js будет запущен раньше, чем init() в c.js, но не более того. Предполагается, что в a.js и b.js Вы определяете какие-то объекты, которые используются в c.js. Конечно, инициализирующие функции в модулях a и b вызываются по очереди, я даже могу сказать, что в простом случае они будут вызваны в том порядке, в котором они инклудятся. Но не нужно этот факт использовать для всяких хитростей. Честно говоря, я не вижу смысла в упомянутых Вами манипуляциях (с практической точки зрения). И, кроме того, если модуль b.js был подключен (востребован) где-то ранее, и уже был инициализирован, то он не будет инициализироваться повторно. Таким образом порядок может нарушиться.
> Но как быть с отложенной загрузкой модулей в такой ситуации?
Я здесь не писал, но в гелиосе есть поддержка динамической загрузки (и, кстати, выгрузки) модулей по требованию. Для этого используются функции load() и unload(). В какой-то момент Вы говорите load(a.js) и ядро подключает этот модуль (вместе с его новыми зависимостями) и так же инициализирует. unload() действует в обратную сторону, но при этом оставляет загруженными те модули, которые используются где-то ещё. Об этом подробно написано в туториале по ядру на домашней страничке.
>> Есть так называемые «свойства стиля», которые наследуются по виджетам и зависят ещё и друг от друга.
> Как описывается это взаимодействие? Явно (constraints) или неявно (destructive update)?
Я не знаком с такими понятиями и не очень понимаю, что значит «явно» и «неявно», так что приведу пример. Но прежде скажу пару слов о том, как устроена библиотека heliwidgets. Сам тулкит содержит объекты (Button, Label, etc) для виджетов, которые обладают некоторым интерфейсом. В этот интерфейс входят т.н. свойства виджетов (надпись на кнопке, ориентация «селектора» — горизонтальный или вертикальный, геометрия — обратите внимание, что она относится не к «свойствам стилей», о которых ниже), различные сигналы, извещающие о том, что, например, кнопка нажата, и некоторые методы (например, добавить новый элемент в селекторе). Никакого кода по отображению виджетов на экране и по взаимодействию с броузером (поимка сообщений о нажатии кнопки мыши, например), в этих объектах нет. Такими вещами занимается движок (rendering engine), который полностью отделён от логики виджетов. Сейчас единственный существующий движок использует canvas для отрисовки виджетов на экране, это то что Вы видели на демке с калькулятором. В принципе, ничто не мешает сделать движок, который будет рендерить виджеты, например, во флэш-апплете, сообщаясь через LocalConnection. Или даже можно написать плагин для фаерфокса, который будет предоставлять некоторый js объект с интерфейсом движка для heliwidgets, который будет рендерить виджеты используя десктопный тулкит, хоть тот же GTK, это наверняка будет работать быстрее. Так вот на самом деле, упомянутые свойства стиля (StyleProperty) — это сущность, которая относится к движку. Совокупность свойств стиля можно воспринимать как «скин» для конкретного движка. Движок сам определяет, какие свойства стиля у него есть. Например, в helianthus (это так называется единственный пока написанный движок) есть свойства стиля, которые определяют основной цвет, цвет подсветки, цвет тени (которые зависят от основного, но их можно переопределить), и есть ещё, например, «извратное» свойство стиля cornerRoundness, которое определяет радиус закругления углов во всех прямоугольных объектах. Вот почему геометрия не относится к свойствам стиля, а относится к самому тулкиту. Наследование по виджетам нужно вот для чего. Например, есть виджет Frame (прямоугольная рамка с виджетами внутри). И если ей установить какое-нибудь свойство стиля, например цвет тени, то это изменение будет так же применено и ко всем внутренним виджетам, потому что это логично, и это поведение, которое ожидает получить программист.
> Только вот пока документации нет, заставлять читать код было бы нехорошо. :)
В архиве с калькулятором (линк на дом.страничке) есть ридми, в котором кое-что сказано, а вообще калькулятор писался как codecast, то есть это с одной стороны реально работающее приложение, которое можно запустить, а с другой — если открыть исходник, то комментарий представляет собой по сути документацию, где есть описание с самого начала всего, что происходит, и где подробно объяснён каждый вызов, что он делает и какие у него параметры. Так что рекомендую всё же.
> Хорошая идея, но такое уже есть в qooxdoo. :)
Кстати, qooxdoo на мой взгляд самый близкий проект к тому, чем я занимаюсь. На самом деле, узнал о нём совсем недавно :) Но вот хоть будет с кем поконкурировать, надеюсь это пойдёт обоим на пользу. И, да, в qooxdoo есть настоящий безсерверный инклюд, как у меня? ;) Тут же:
> А как же оно тогда работает?
Оно работает полностью на клиенте, в этом то и фишка. Можете загрузить кодкаст с калькулятором, раззипить и открыть в броузере index.html у себя на локальной машине без всяких серверов. В самом index.html нет ничего, кроме реквеста подгрузить kernel.js. Это ядро, и единственный скрипт, не являющийся модулем для гелиоса. там происходит много всяких таинственных вещей, но вкратце — первым делом подключается main.js (где программер начинает свой код). в каждом модуле есть набор инклюдов в шапке, и функция init(). ядро сначала подключает все эти скрипты (создавая объект <script> в ДОМе), составляет граф зависимостей, а потом в обратном порядке вызывает инициализаторы для каждого модуля. Но это очень упрощённо, на самом деле там ещё есть всякие навороты потипу динамической загрузки/выгрузки модуля и всех зависимостей, отслеживание циклических зависимостей и пр.
> Qooxdoo, YUI, Dojo+Dijit, jQuery UI.
Про куксду сказал выше, про остальное — честно, я не специалист по этим вещам, только лишь читал некоторые описания. Знаю, что, например подходы GWT и Eclipse RAP предлагают юзать джаву в IDE со всеми наворотами языка и фичами среды разработки, а потом всё это транслируется в HTML+JS+CSS+PHP+чтоугодно. Eclipse RAP, кстати, использует тот же куксду для виджетов в клиенте.
Ещё хочу сказать про DOM. Это — наполовину ответ на вопрос выше, и наполовину — на следующий:
> Как обстоят дела с модульностью и аддитивностью? Хочется, чтобы, например, CSS можно было бы задавать для каждого виджета *отдельно*…
Взаимодействие с DOM я постарался исключить полностью. Наличие как такового «документа» накладывает существенные ограничения. Возможно, чересчур опрометчиво с моей стороны, но с точки зрения разработчика на гелиосе — нет ни CSS, ни DOM. Лучше всего это увидеть, посмотрев код. Есть так называемые «свойства стиля», которые наследуются по виджетам и зависят ещё и друг от друга. Например, можно поменять цвет тени для какого-то фрейма, тогда он поменяется и у дочерних виджетов. Вот ещё пример: поменяв свойство primaryColor у виджета rootWidget на #112233 в калькуляторе, можно заставить его выглядеть так:
home.gna.org/helios/helioscalc_dark/
об этом есть на дом. страничке, но повторюсь ещё раз — покуда нет документации и покуда я не умею «грамотно составлять рекламные проспекты» :) лучше всего читать код, чтоб понять идею.
> В CSS бывает так, что, наложив один хак, ломается что-нибудь совсем в другом месте. И в JS тоже бывает. Как с этим быть? :)
Одна из задумок как раз в том и заключается, что программист должен писать программу, а не придумывать очередной хак, а потом пытаться сделать так чтоб всё остальное не поломалось :) по идее, это всё должны взять на себя библиотеки гелиоса.
> PS используйте кнопку «ответить», удобно ведь. :)
я с утра на хабре, ещё не сориентировался :)
Helios относится как раз к клиентской части, это то, что будет юзеру выдаваться в начале сессии. Heliwidgets как таковой немножко не относится ко всем этим делам между клиентом и сервером, наверное это скорее даже отдельный проект, библиотека виджетов для helios. Но пока я их не разделяю.
chiaroscuro, каких конкурентов вы имеете в виду?
Само ядро фреймворка содержит только то, что мне нужно — возможность делать include. Всё остальное — библиотеки.
С Heliwidgets у меня тоже связано много разных идей, которые я постепенно буду воплощать. Эта демка ещё далека до продакшна и даже до альфы, имеет своей целью привлечь тех, кому это м.б. интересно.