Здравствуйте, __SPIRIT__, Вы писали:

__S>Здравствуйте, Mamut, Вы писали:

M>>То-то нет ни одной библиотеки, которая полностью .s повторяла поведение офисных контролей. А те, которые повторяют, стоят, как сама среда разработки

__S>Плохо искал. Мой друг довольно шустро нашел оч симпотичные контролы... У меня на проекте тоже нефиговый интерфейс... Сто пудов не хуже чем в офисе если не лудше...

Ссылку можно?

Здравствуйте, Дьяченко Александр, Вы писали:

ДА>Здравствуйте, __SPIRIT__, Вы писали:

__S>>Здравствуйте, Mamut, Вы писали:

M>>>То-то нет ни одной библиотеки, которая полностью .s повторяла поведение офисных контролей. А те, которые повторяют, стоят, как сама среда разработки

__S>>Плохо искал. Мой друг довольно шустро нашел оч симпотичные контролы... У меня на проекте тоже нефиговый интерфейс... Сто пудов не хуже чем в офисе если не лудше...

ДА>Ссылку можно?

Спроси у него сам чтоп я не забыл ник Taft

Здравствуйте, Imatic, Вы писали:

I>Значит, хорошая идея, если она не только одному мне в голову пришла.

Конечно хорошая, если в брузерах придумали как динамически компоновать страничку в зависимости от размера окна — почему бы код не reuse, если позволит скорость. опять же теоретически решается вопрос выбора интерфейса Graphics/Text/Voice. Чтобы пообщаться с поддержкой человек может послать ссылку на конкретную форму и получить ссылку на конкретную кнопку (в принципе никто это не мешает сделать в например delрhi или MS Office, но как правило не делают).

А поведения используют не только mozilla (XML binding Language если не ошибаюсь), но и Microsoft (HTML Components).
HTML Applications в виндах уже давно, особенно начиная с Win2000, частично (вид папок) — начиная с IE4.

WebForms туда же.


Это вполне себе интересная идея. Особенно для терминальных серверов, там где слишком примитивный X Window System гоняет трафик по любому чиху, а в HTML можно скрипт встроить.

опять же, программу можно (по крайней мере легче) будет по частям апгрейдить — тем кто с этим справится. Я бы не рискнул, но воможностей больше становится.

А если это станет мейнстримом — вылезут принципиалные траблемы и маятник качнется обратно в сторону hard coded компонент — и пусть.

Здравствуйте, c-smile, Вы писали:

CS>Any ideas of how such DSTL (dom state transition language) should look
CS>like? My personal experience with htmlayout where each input control and
CS>their subparts are plain styleable DOM elements shows that it can be
CS>surprisingly simple language. Sort of SQL with triggers.

CS>WHEN selector IS GETTING/LOOSING state
CS> SET ...
CS>and so on...

CS>Andrew

Я правильно понимаю, что скоро в htmlayout появится нечто подобное? Или это только задумка?

Здравствуйте, kliff, Вы писали:

K>Здравствуйте, c-smile, Вы писали:

CS>>Any ideas of how such DSTL (dom state transition language) should look
CS>>like? My personal experience with htmlayout where each input control and
CS>>their subparts are plain styleable DOM elements shows that it can be
CS>>surprisingly simple language. Sort of SQL with triggers.

CS>>WHEN selector IS GETTING/LOOSING state
CS>> SET ...
CS>>and so on...

CS>>Andrew

K>Я правильно понимаю, что скоро в htmlayout появится нечто подобное? Или это только задумка?

В htmlayout (внутри) этого не будет точно.
Я позиционирую htmlayout как core engine — HTML/CSS + events/behaviors.
Т.е. никаких особых фич такого рода и смены API не планируется.

Но это не означает что скажем кто-то не сделает модуль xforms или
скажем нечто типа DSTL. Но это скорее всего будет какой другой продукт со встроенным htmlayout.

Одна команда сделала на мой взгляд интересную, эффективную и простую имплементацию actions
для htmlayout. Нечто типа:

<button onClick="action:somefunction(someparameters)" >... </button>

Т.е. они ловят все events на root и проверяют наличие атрибутов типа onMouseUp, onClick.
Плюс простой парсер строки somefunction(someparameters) и таблица "имя функции"->указатель.
Это все занимает как мне сказали 400 строк кода (C++,stl).
Плюс конечно набор таких функций реализующих логику приложения.

Команда делает что-то связанное с AutoCAD в строительстве — как я понял wizards разного рода —
много всяко разных форм в силе inductive UI.

----------
Я же делаю сейчас нечто под названием sciter — thin smart client.
Это mono exe с htmlayout и tiscript внутри. Там transitions обрабатываются все тем же механизмом
behaviors:

<script type=tiscript>
var MyBehavior = {}; // empty object, so far

function MyBehavior.onMouseDown(evt) // method attached to MyBehavior
{
  this.text = "Got Mouse Down"; // this here is the element this bhv attached to.
  return true;
}
function MyBehavior.onKeyDown(evt)
{
  ....
  return false;
}

</script>

Назначение DOM элементам таких behaviors — все также через CSS:

div.myclass {
  border: ....;
  behavior: MyBehavior;
}

Но это не будет компонент — end user application.