Не мастак я придумывать красивые заголовки, но в этом случае придумал бы с удовольствием. Потому как опять про Qooxdoo.
Я, наверное, потихоньку влюбляюсь в этот продукт и этих ребят. Первый раз их увидел когда еще писал на PHP (да, я раньше был извращенцем, но я исправился). Тогда я повосхищался их кнопочками и менюшечками, показал знакомым программерам... В общем знакомство состоялось. Второй раз я за них взялся уже более-менее всерьез, скачал дистрибутив, поковырялся и написал мини-обзор о том как состыковать Qooxdoo и Ruby on Rails (его даже проанонсировали в официальном блоге Qooxdoo). Однако, при попытке создать более-менее рабочее приложение, я наткнулся на весьма неприятный баг с отправкой POST-форм (я об этом писал в старой версии журнала, которая лежит где-то на Majordomo). И вот, наконец, я в третий раз прихожу к ним - и как раз к моменту выхода Qooxdoo 0.7 alpha2.
Здесь, наверное, стоит завершить лирику и перейти к сути. Приближающаяся версия 0.7 несет нам ряд нововведений, которые я бы назвал знаковыми. Самое знаковое - это переработка механизма ООП и работы с классами. Прямо скажем, это нечто. При работе с Qooxdoo версии 0.6 меня сильно смутила некоторая громоздкость структур и нетривиальность работы с классами. Т.к. опыт работы с JavaScript у меня на тот момент был практически нулевой, вьехать в систему прототипов было ой-ой-ой как непросто. Собственно, этим не только Qooxdoo грешит. Я, например, до сих пор с трудом въезжаю в устройство классов Prototype, хотя пользуюсь им можно сказать каждый день.
В новой версии разработчики Qooxdoo планируют достаточно сильно упростить работу с классами. Предполагается что структура класса будет выглядеть примерно так:
qx.Class.define("my.cool.Class", {
/* Наследование от класса */
extend : my.great.SuperClass,
/* Интерфейсы а-ля Java*/
implement : [my.cool.IInterface, my.other.cool.IInterface],
/* Миксины а-ля Ruby */
include : [my.cool.MMixin, my.other.cool.MMixin],
/* Конструктор */
construct : function() {
this.base(arguments, x);
...
},
/* Деструктор */
destruct : function() {
...
},
/* Статичные методы класса */
statics :
{
PI : 3.141,
bar : function() {}
},
/* Методы экземпляра класса */
members:
{
foo : VALUE,
circumference : function(radius) {
/* Вызов статичного метода класса */
return 2 * this.self(arguments).PI * radius;
},
bar : function(x) {
/* Вызов метода родительского класса */
this.base(arguments, x);
},
_protectedMember: function(x) { ... },
__privateMember: function(x) { ... },
browserSpecific: qx.Variant.select("qx.client",
{
"mshtml|opera": function() {
// Internet Explorer or Opera
},
"default": function() {
// All other browsers
}
})
},
/* События */
events :
{
/* Вызывается при кликепо объекту */
"click": "qx.event.type.MouseEvent"
}
});
Это сборная солянка из сравнения возможностей ООП в Qooxdoo 0.6 и 0.7. Мило, не правда ли? Вполне себе читаемо и поддается осмыслению без выворачивания мозгов наизнанку. Прямо как в номральных языках программирования. Особенно две примечательных вещи - это интерфейсы и миксины. Интерфейсы, насколько я понимаю, предполагаются по аналогии с Java (однако зачем они нужны - для меня пока загадка, я в джаве не силен). Миксины - как попытка затащить в JavaScript частичку мощи Ruby, а именно разработку абстрактного функционала, который может быть подключен к любому классу. Едва взглянув на эту задумку, я готов преклонить голову перед разработчиками за смелость и заботу о прогрессивном человечестве.
В новой версии предполагается еще много разных фич, о которых стоило бы написать отдельно. С нетерпением ждем выхода новой версии. Может быть, я еще чего-нибудь успею написать до релиза 0.7.

Да будет прикольно если они это сделают, можно будет использовать как ОО фреймворк, который можно будет использовать с другими JS приложениями
Знаете что! Опять что-ли захотелось вернуться в зло#$учую дельфу и перетаскивать стандартные контролы на форму? Когда веб дает такие возможности для дизайна действительно user-frindly интерфейсов? Имхо им бы сделать контролы design-ready, тогда они по праву смогут считаться “The new era of web development”, ну или почти “The new era of web development”.
По поводу интерфейсов (IInterface) - фактически интерфейс определяет набор функций, которые должен поддерживать данный класс, но реализации функций там нет. Например интерфейс “IЕда” - определяет, что у класса должна быть (он её реализует) функция “Съесть”, а интерфейс “IПереключатель”, опредяет, что должны быть функции “Включить”/”Выключить”. И соотв. при определении какого либо класса поддерживающим интерфейс(ы), можно не зная, что это за класс вообще, работать с ним как с объектом данной природы используя функции определенные в интерфейсе.
Т.е. цель интерфейсов - дать информацию разработчику (и программе), по возможным поведениям (использованиям) класса.
Я думаю это полезно при разработке сложных систем (при OOD), насколько это оправдано при небольших системах не знаю.
Лось Бульвинкль, инструменты подобные Qooxdoo хороши для реализации действительно сложных программных интерфейсов, ориентированных на функциональность, скорость работы и привычность, а не на красоту. А перетаскивание кнопочек - не самый плохой вариант для разработки подобного уровня интерфейсов.
Кстати, Delphi for PHP использует Qooxdoo как вариант для разработки Ajax-оирентированных интерфейсов
DEkart> Отличный блог, кстати сказать.
По поводу delphi, имхо парвильный подход к быстрой разработке интерфейсов, проще такого конструктора придумать сложно. Однако я считаю что интерфейс вещь особенная, и виндовс не может служить образцом usability-goodness. Сам пользоваться подобным не стану, именно из-за того что веб предоставляет гигантские возможности по дизайну clean-n-beautiful интерфейсов.
Спасибо :)
Так-то оно так. Однако подавляющее большинство пользователей привыкло к оконно-кнопочным интерфейсам и привыкание к особенностям интерфейса очередного сайта или, не дай боже, программного продукта - просто адские муки. Чем привычнее интерфейс, тем проще его освоить неискушенному потребителю.
В особенности это критично для сложных продуктов, например, корпоративных баз данных или сервисных приложений. Тут фантазия и попытки открыть Америку в usability могут привести к весьма плачевным результатам - сложностям во внедрении, обучении персонала, низкой продуктивности работы пользователей, частые обращения в службу поддержки. В этом случае лучше пожертвовать красотой во имя продуктивности, мне так кажется.
Как бы то ни было, Qooxdoo найдет своё применение. Юзеры действительно привыкли к стандартным серым кнопкам (и в России больше чем где либо).
Однако общую картину я воспринимаю таким образом: при появлении AJAX и развитии javascript, имплементация устаревших (предыдущих) течений в дизайне на новой технологии не могла не появиться , но будущее, все равно, за новыми интерфейсами.
Пользователи за рубежом уже понимают, что работа должна быть не только эффективной , но и приятной (еще раз повторю виндовс, имхо, не образчик эффективности). Будем надеяться, что в России тоже поймут это как можно скорее.