Последнее изменение: 22 сентября 2007г.

"Мышекликательное программирование" или почему я не люблю визуальные редакторы

Термин "мышекликательное" – не мой. Он возник в форуме и очень мне понравился, ибо как нельзя более точно подходит для описания процесса, о котором пойдет речь в этой статье. А именно – визуального проектирования пользовательского интерфейса. Статья, как можно догадаться из ее названия, посвящена в основном недостаткам этого процесса. О преимуществах я тоже скажу, правда, всего пару слов.

Все нижеследующее – всего лишь мое личное мнение.

• Предисловие ко второй версии статьи
• Введение
• Ставим задачу и реализуем ее
  • NetBeans 5.0
  • Eclipse 3.2
  • Borland JBuilder 2005 Foundation
  • IntelliJ IDEA 6.0
  • JFormDesigner 3.0.4
• Обещаные комментарии по поводу JBuilder 2007 и IntelliJ IDEA 7
• Анализ реализаций
• Анализ и сравнение возможностей IDE
• Размышления и выводы
  • Последствие 1. Привязка к среде разработки
  • Последствие 2. Ограничение в используемых средствах
  • Последствие 3. Изучение IDE вместо изучения языка
• Несколько слов в защиту визуальных редакторов GUI
• Подводя итоги
• Вместо послесловия
• Вместо послесловия – 2

Предисловие ко второй версии статьи

Я долго думал – писать ли новую статью, в качестве дополнения, или же расширять эту. В планах был обзор JFormDesigner-а, про который мне давно говорили, JBuilder 2007, выпущенного недавно, и уже не Borland, а CodeGear, а также IntelliJ IDEA 7, в которой обещался быть импорт произвольного дизайна через анализатор исходного кода. Однако после более тщательного изучения выяснилось, что предмета исследования в двух случаях из трех просто нет. Потому я решил расширить уже имеющуюся статью.

Итак, в статью добавлена информация по JFormDesigner 3.0.4. Помимо этого в некоторых местах изменены формулировки, сделаны дополнительные замечания, комментарии и т.п. О JBuilder 2007 и IntelliJ IDEA 7 сказано всего несколько слов.

Введение

Когда-то, давным-давно, я программировал не только на Java, но на некоторых других языках, в число которых входил и Delphi. Хотя справедливости ради надо сказать, что язык там Object Pascal, а Delphi – система разработки. Ну неважно.

И вот как-то раз пришлось мне писать консольное приложение – упрощенный аналог sendmail. Задал в качестве параметров адрес, обратный адрес, тему и текст, запустил – письмо отправлено. Ну понадобилось нам такое на работе. И вот обнаружил я такую вещь. Работа с сетью может быть реализована в Delphi двумя путями – через имеющуюся компоненту (кажется, TSocket), либо через Win32 API. Однако для того, чтобы использовать компоненту – нужна форма, на которую эту компоненту нужно положить. Иначе она выпадает из цикла событий приложения и неработоспособна. Т.е. в случае консольного приложения ее применять нельзя. Всё, пишите письма. Наш путь – в Win32 API. Об удобстве его применения распространяться не буду. Либо придется самому организовывать цикл обработки сообщений – повторять то, что уже по идее сделано. Либо – искать компоненту, которая умеет то, что нам надо.

К сожалению, приходится сделать отступление.

Дорогие поклонниики Delphi! Прежде чем вы опять броситесь писать мне письма с обвинениями в непрофессионализме – а такое происходит постоянно! – я настоятельно прошу вас принять во внимание следующее. Основной моей претензией к Delphi является сильная привязка к компонентам и резкое усложнение работы без них. А потому – все письма из разряда "ты дурак, надо просто взять компоненту ХХХ" – они только подтверждают то, что я пишу. От тех же, кто все-таки захочет меня в чем-нибудь обвинить, вместе с обвинениями я жду решения вышеуказанной задачи (посылка письма; SMTP-сервер, from/to/subject/body – все это указывается в качестве параметров командной строки) при следующих условиях:

а) не использовать внешние компоненты – решение должно быть только средствами, имеющимися в Delphi. Это распространяется и на Indy, которых в описаный момент в Delphi не было.
б) не использовать Win32 API и не создавать собственный цикл обработки сообщений – оба эти метода я упомянул и для обвинения меня в непрофессионализме они не годятся.

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

С тем, кто действительно решит эту задачу, – с ним мы поговорим о моем профессионализме 9 лет назад в непрофильной для меня области. Всех прочих я настоятельно прошу оставить свое мнение при себе.

Отвлекаясь от описаной ситуации, задумайтесь вот над чем. Как вообще происходит разработка приложения на Delphi? Кликнули – создали форму. Кликнули – положили на нее меню. Кликнули – создали набор action-ов. Кликнули несколько раз – создали сами action-ы (и все кликами – и картинку им выбрать, и обработчик создать, пока что пустой). Кликнули несколько раз – накидали элементов в меню. Каждому элементу сопоставили action – тоже кликами. Кликнули – ... Кликнули – ... Кликнули – ... ... ...

Вот этот процесс я и называю мышекликательным программированием. Он создает ощущение легкости и удобства разработки. И именно ввиду этого ощущения разработчик-то и не задумывается над тем, что именно он теряет. Он может решить практически любую задачу. Главное – найти нужную компоненту. И именно потому компонент под Delphi написано какое-то умопомрачительное количество. А если компонента не найдена – можно написать свою. И кинуть ее на форму.

Жизнь, однако, складывается так, что Delphi постепенно отмирает. Многие проекты переводят с него на другие языки, ибо поддерживать их нет смысла. Многие разработчики переходят с Delphi в другие области. Кто-то приходит в мир Java. И первое, на что он обращает внимание – это отсутствие такого же мощного кликательного аппарата, как в Delphi. Да и многие из тех, кто не видел Delphi, но программирует на Java, непрочь бы облегчить себе жизнь.

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

Ставим задачу и реализуем ее

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

Для начала я эту задачу реализовал руками, просто чтобы иметь перед глазами образец. Как раз это окошко и показано слева. Чтобы получить изображение в полный размер, кликните на нем. Реализация отняла минут 15, учитывая и два контрольных запуска для устранения ошибок. Код, который у меня получился, находится вот тут: DirectoryDialog.java.

Теперь главное – в чем создавать это окошко визуально. Я остановился на пяти наиболее серьезных инструментах: NetBeans 5.0, Eclipse 3.2, Borland JBuilder 2005 Foundation, IntelliJ IDEA 6.0 и JFormDesigner 3.0.4.

Сразу комментарии:

• Почему NetBeans 5.0, а не 5.5? Потому что версия 5.5 отличается от 5.0 в основном enterprise-добавками. JavaEE 5, веб-сервисы, EJB 3.0 и прочая. Подробнее можно посмотреть тут. Изменения в области GUI тоже есть, но небольшие – интернационализация, локализация, просмотр формы в различных LnF, поддержка раскладок Java 6 и еще несколько мелочей. Учитывая, что версия 5.0 у меня уже стоит, я счел, что для данной статьи ее более чем хватит.

  Надо сказать, что при пересмотре этой статьи я проделал все то же самое в версиях 5.5.1 и 6.0M10. Результат не изменился. Так что, оглядываясь назад, можно признать, что версии 5.0 действительно было достаточно.

• По поводу Eclipse смогу сказать следующее. Несмотря на довольно внушительный размер, eclipse умеет не так уж много, практически на каждый чих требуя плагин. Визуальный редактор пользовательского интерфейса – тоже плагин. Называется он VE (Visual Editor), и взять его можно тут: http://www.eclipse.org/vep/. Он требует установленных плагинов EMF и GEF, впрочем, ссылки на них там есть. В общем, у меня были установлены VE v1.2, GEF v3.2, EMF v2.2.0.

  Почему я в статье вместо "плагин" говорю "Eclipse"? Исходя из тривиальной логики. Мне понадобился визуальный редактор, я зашел на www.eclipse.com и взял его. Соответственно, у меня есть все основания считать VE официальным визуальным редактором Eclipse.

• Почему JBuilder 2005, а не 2006. Потому как последняя версия Foundation – 2005. А получать trial-версию 2006 – утомительно.

• Замечания по поводу IDEA. Изначально в этой статье я рассматривал beta-версию. И впечатление она произвела, прямо скажем, не очень. Однако с выходом финальной версии ситуация сильно изменилась¹. И потому я решил пересмотреть свои выводы относительно ее визуального редактора.

• JFormDesigner я взял той версии, которая имелась на момент его исследования – 3.0.4. С тех пор вышла 3.1, но изменения там косметические. Я использовал для исследования самостоятельную версию, хотя в работе использую плагины к Eclipse и IDEA. Разница исключительно в мелочах, которые я упомяну, когда буду говорить об использовании нестандартных компонент.

В случае каждой из IDE создавался новый проект, в котором реализовывалось требуемое окно. Где-то допускались ошибки, которые потом приходилось исправлять, словом – обычная работа. И поведение IDE в таких ситуациях тоже весьма интересно, т.к. влияет на удобство ее использования.

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

NetBeans 5.0

С идеологией NetBeans в плане пользовательского интерфейса я был, в общем-то, знаком (я довольно долго работал с Sun Forte CE, построенной на основе NetBeans, причем занимался именно пользовательским интерфейсом). Однако это было давно, и создание необходимого окна заняло минут 40. Какое-то время потребовалось, чтобы вспомнить, где настраивается layout (это не очевидно с первого взгляда – я ожидал увидеть настройки в таблице свойств компоненты, как это практикуется в других редакторах). Какое-то время понадобилось, чтобы исправить ошибку. Но в общем и целом впечатления положительные. NetBeans создает два файла – исходник (DirectoryDialog.java) и файл формы (DirectoryDialog.form). Результат в точности идентичен написаному руками. Единственная модификация в коде – в конструктор добавлена строка setSize(400,300). Да и то, я помню, что есть возможность задавать генерацию размера в визуальном режиме (позже я ее нашел за считаные минуты).

При обновлении статьи я понял, почему у меня столько времени заняло создание простого окна. Дело в том, что визуальный редактор NetBeans – единственный из всех исследованных, который не имеет координатной сетки в режиме GridBagLayout. Компоненты там кладутся на форму одна за другой, gridwidth/gridheight у них выставлены в RELATIVE, и на то, чтобы разложить этот паровоз так, как необходимо, уходит некоторое время.

Eclipse 3.2

С визуальным редактором Eclipse я работал впервые. Немного странным показалось, что закладка со свойствами расположена в нижней части, редактора, вследствие чего она широкая и низкая (привычнее наоборот). Перетаскивание ее вбок много не дало – ширина колонок не подстроилась под оптимальный размер. Мелочь, но все-таки. Палитра компонентов, которая постоянно прячется, тоже не добавляет удобства. Ну ладно, это, возможно, придирки, наверное все можно настроить один раз и не возвращаться. Хотя у меня, честно сказать, заставить палитру быть открытой постоянно так и не получилось.

При использовании GridBagLayout форма красиво расчерчивается на прямоугольники, горит подсветка по x- и y-координатам. Это плюс. Процесс создания формы, однако, преподнес сюрприз, причем неприятный. Дело в том, что для полей gridwidth и gridheight класса GridBagConstraints невозможно использовать предопределенные константы RELATIVE и REMAINDER. В принципе, манипуляциями с gridx/gridy и gridwidth/gridheight можно добиться того же эффекта, но тем не менее – это уже ограничение. Может быть именно поэтому сделан такой визуальный акцент на x- и y-координаты.

Задать значения для выпадающего списка дисков мне тоже в визуальном режиме не удалось. Потому результат по внешнему виду идентичен необходимому, однако список дисков пустой. Eclipse создает единственный файл – DirectoryDialog.java, других замечено не было. Весь процесс занял чуть меньше часа.

Borland JBuilder 2005 Foundation

С JBuilder-ом я раньше если и работал, то только с кодом. Интерфейс визуального редактора внешне никаких нареканий не вызвал – все так, как принято. При использовании на форме GridBagLayout пространство формы расчерчивается цветом фона. Тот факт, что для gridwidth и gridheight невозможно использовать RELATIVE и REMAINDER удивления уже не вызвал. Хотя странно – для настройки GridBagConstraints у JBuilder вроде отдельная форма, на которой гораздо проще организовать редактируемый выпадающий список, чем в случае унифицированного окна свойств, как у Eclipse (хотя у NetBeans и это проблем не вызвало). Еще один неудобный момент – при задании свойств layout-а (а они задаются в отдельном окне) фокус с окна свойств регулярно уходил. Почему-то всегда выделялось меню "File".

Как мне подсказал коллега, выставить RELATIVE/REMAINDER в JBuilder все-таки можно. В документации даны численные значения, которые для этого надо подставить. При ближайшем рассмотрении эти значения оказываются значениями констант RELATIVE/REMAINDER – -1 и 0 соответственно. Недостаток такого подхода очевиден: в случае изменения этих значений при использовании непосредственно констант достаточно будет только лишь перекомпилировать класс, при использовании чисел – будут проблемы.

Совсем уж гнетущее впечатление произвела операция простейшего переноса компонент из одного контейнера в другой. Я изначально ошибся – надо было создать основную панель, чтобы у нее установить необходимую рамку в 5 точек. А я вспомнил про нее только когда все компоненты уже были на форме. Казалось бы, чего проще? Добавил еще одну панель, установил на ней тот же layout, выделил все остальные компоненты, а дальше – cut/paste. Во всяком случае такой подход работал в NetBeans. Мечты, мечты... После операции paste JBuilder ТАКОЕ сотворил с параметрами layout-а, что минут 15 ушло только на то, чтобы привести форму в божеский вид. Компоненты были расположены аккуратной лесенкой, координаты по х были в районе 5,6,7 (при том, что изначально – 0 и 1).

Модель для списка дисков задать не удалось. Не помогло даже создание модели в коде, как поля класса (была у меня тайная надежда, что редактор ее после этого увидит). Так что внешне окно такое, как должно быть, но список дисков пустой. JBuilder создает два файла – исходник (DirectoryDialog.java) и какой-то файл с расширением jbx (DirectoryDialog.jbx). Я затрудняюсь определить, какую он играет роль. С учетом времени, потраченного на перераскладку формы, весь процесс занял больше часа. Сыграло роль и то, что невозможно выделить несколько компонент и одновременно выставить им какое-нибудь свойство. Нет, выделить можно, но свойство выставляется только последней выделенной.

IntelliJ IDEA, как я уже писал выше, я рассматривал снова через полтора месяца после выхода первой версии этой статьи.

IntelliJ IDEA 6.0

Редактор у IDEA на вид неплохой. Не перегруженый компонентами, как тот же JBuilder (однако, много и отсутствует, например, все компоненты, связаные с меню). При использовании на форме GridBagLayout она расчерчивается пунктиром, причем симпатичнее, чем у Eclipse – пунктир не пересекает компоненты.

Начинаем создавать форму. В первый раз у меня это вызвало достаточно серьезные затруднения, ибо параметры GridBagLayout, применявшиеся в beta, не имели ничего общего с обычными. В случае с релизом ситуация намного лучше. Правда, отсутствуют такие параметры как gridx/gridy/gridwidth/gridheight, но они отвечают за положение компоненты в контейнере, которое можно задать визуально. Однако не без сюрпризов: при создании простейшей тестовой формы – три метки слева, три текстовых поля справа – текстовые поля никак не хотели становиться в одну колонку. По крайней мере до того момента, как одному из них поставишь weightx=1, так что колонка растянется. Также при растяжении компоненты на несколько ячеек наблюдается странный эффект – все остальные компоненты сбиваются в кучу. Перестаешь растягивать – все возвращается в норму. В первый раз это несколько пугает.

С остальными настройками ситуация тоже лучше. По сравнению с бета-версией стали доступны insets/ipadx/ipady/weightx/weighty. Это не может не радовать, т.к. позволяет точно воспроизвести требуемую форму (в бета-версии это не удалось). Немного непривычно выглядят настройки Vertical align/Horizontal align, которые есть ничто иное как совмещение fill и anchor, хотя логика тут прослеживается легко – если компонента растянута по горизонтали, то ее horizontal align значения не имеет. Аналогично по вертикали.

Поскольку я был уже ученый – больше проблем у меня не было. Форму я создал минут за 10. Общее впечатление финальная версия оставила гораздо лучшее, нежели бета. Субъективно – где-то на уровне NetBeans.

Хочу, однако, поделиться парой моментов, возникших при работе. Первое – исходный код. IDEA приподнесла мне сюрприз. Я нарочно сделал снимок экрана, чтобы вы могли представить степень моего шока, когда я увидел этот код в первый раз.

Да. ЭТО ВСЁ.

Более того. Изначально в этом коде не присутствовала даже строка private JPanel mainPanel;. То есть в классе было только 6 компонентов, не инициализированных, никуда не добавленых. Непонятно решительно ничего, в первую очередь – а как эту форму создать??? Как выяснилось при попытке сгенерировать метод main, я не дал имя основной панели, на которой укладывались компоненты.

После исправления этой ошибки IDEA милостиво сгенерировала main. Вот как стал выглядеть код:

package ru.skipy.test.ide.idea6;

import javax.swing.*;

public class DirectoryDialog{

    private JComboBox chooseDriveComboBox;
    private JButton okButton;
    private JButton cancelButton;
    private JTree chooseDirectoryTree;
    private JButton createNewButton;
    private JButton projectRootButton;
    private JPanel mainPanel;


    public static void main(String[] args) {
        JFrame frame = new JFrame("DirectoryDialog");
        frame.setContentPane(new DirectoryDialog().mainPanel);
        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        frame.pack();
        frame.setVisible(true);
    }
}

Всмотритесь в код внимательно. Сразу после создания DirectoryDialog его поле mainPanel (которое нигде не инициализировано, весь код перед вами!) добавляется в форму в качестве contentPane. Согласно исходному коду JavaSE это должно вызвать исключение:

public void setContentPane(Container content) {
    if(content == null)
        throw new IllegalComponentStateException("contentPane cannot be set to null.");
    ...

А самое непонятное для меня, что этот код работает как надо.

Разобраться в ситуации помог только дизассемблер². Оказалось, визуальный редактор IDEA при компиляции добавляет в класс синтетический метод $$$setupUI$$$, вызов которого осуществляется сразу после вызова конструктора суперкласса. В этом методе все компоненты создаются, добавляются в контейнер, и т.п. Таким образом, в тот момент, когда наступает возможность использования переменной panel, она уже инициализирована. Чего по коду не видно, разумеется.

Справедливости ради надо отметить, что дело обстоит не совсем так, как кажется сначала. После выхода первого варианта этой статьи я получил несколько писем по поводу этого материала, в том числе и от участника конференции по имени seQuira, за что я ему очень признателен. Он показал мне способ сделать так, чтобы метод $$$setupUI$$$ генерировался в явном виде. Для этого надо только поменять настройку у визуального дизайнера IDEA, как показано на снимке экрана. Если выбран вариант Binary class files – метод добавляется непосредственно в байткод, во время сборки проекта, как это и происходит по умолчанию. Если же выбрать вариант Java source code – метод добавляется в исходник, но тоже во время сборки (возможно, это можно сделать как-то явно, я не искал). Таким образом, способ получить сгенерированный код все-таки есть. А то было как-то совсем грустно.

В итоге, немного обработав полученный класс молотком и напильником, я получил окончательный полный код – DirectoryDialog.java. Ну и, разумеется, файл формы: DirectoryDialog.form. О полном времени работы говорить смысла нет, ибо я довольно много возился с GUI-редактором IDEA к тому моменту, как взялся за финальную версию.

JFormDesigner я рассматривал отдельно, существенно позже. Не в последнюю очередь благодаря ему я вообще решил обновить эту статью.

JFormDesigner 3.0.4

Непосредственно с JFormDesigner-ом до этого обзора я был знаком, причем неплохо. Так получилось, что его используют у меня в проекте. Потому никакой оценки времени я не проводил.

JFormDesigner интересен тем, что он умеет работать как в виде отдельного приложения, предназначенного исключительно для дизайна форм, так и в виде плагина к IDE. Встраиваться он умеет в Eclipse, IDEA и JBuilder 2005/2006 (вот тут показаны все варианты). Я с ним изначально работал именно в Eclipse, хотя отличий от встроенного в IDEA варианта и от самостоятельной версии не нашел.

У JFormDesigner-а наблюдается то же самое решение, что я видел в IDEA, а именно – совмещение полей anchor и fill – h align/v align. Спорно, хотя я понимаю, чем продиктовано. В остальном проблем никаких – форма в дизайнере хорошо прорисована, ориентироваться легко. Ради эксперимента я даже сначала сконструировал окно прямо в JFrame, а потом через Cut/Paste перенес все элементы в панель, чтобы сделать рамку. Как вы, наверное, помните, в JBuilder-е это вызвало проблемы. Здесь – нет. Хотя я совершенно точно видел проблемы в аналогичной операции при использовании другого layout-а – FormLayout из JGoodies.

Форма получилась идентичной необходимой. В качестве результата имеем два файла: исходник – DirectoryDialog.java, – и форму – DirectoryDialog.jfd. Дополнительно я еще дописал тривиальный класс для создания формы – Runner.java.

Обещаные комментарии по поводу JBuilder 2007 и IntelliJ IDEA 7

Пару лет назад, еще во времена JBuilderX, прошла информация, что следующая версия JBuilder будет сделана на основе Eclipse. Но с тех пор появились JBuilder 2005 и JBuilder 2006, причем Eclipse там и не пахло. Моя уверенность насчет того, что Borland откажется от собственной платформы, начала таять... до того момента, когда я пошел на сайт JFormDesigner-а, чтобы скачать его. И в разделе плагинов увидел такую любопытную информацию – для JBuilder 2006 плагин вот тут, а для 2007 – берите тот, что для Eclipse. Путешествие на сайт JBuilder – и, вуаля! JBuilder 2007 ДЕЙСТВИТЕЛЬНО сделан на платформе Eclipse. Естественно, я сразу скачал версию Turbo, бесплатную. Памятуя о том, что визуальный редактор у JBuilder всегда был относительно приличным, я был весь в нетерпении – что они сделали при переходе на другую платформу? Особенно мне было интересно сравнить дизайнер JBuilder с имеющемся в Eclipse Visual Editor.

... ... ...

Сделали.

Как говорил мужик в мультфильме "Падал прошлогодний снег" – "Уж послала, так послала!"

С первых же секунд меня не покидало ощущение, что я вижу старый, хорошо знакомый плохой сон. Дежавю. Я честно старался найти хотя бы пару отличий от VisualEditor 1.2 for Eclipse, рассмотренного мною в этой же статье год назад. Не нашел. А потом я посмотрел список плагинов и понял, что и не смогу найти. В качестве визуального редактора у JBuilder 2007 используется VisualEditor 1.2.1. Разница с тем, что рассматривал я, меньше трех месяцев. А некоторые куски этого плагина у меня были даже более поздних версий, чем у JBuilder.

Неутешительный итог. Визуальный редактор JBuilder, похоже, канул в лету. А ведь это был, пожалуй, единственный редактор, завязаный на анализ исходного кода. И достаточно качественно реализованый, надо сказать. О реализации VE я уже тоже писал год назад. Она была сырой, и такой осталась в JBuilder 2007.

А потому – рассматривать JBuilder 2007 смысла не было. Никакого. Жаль.

Предупреждая возможные вопросы – использование Visual Editor не есть следствие версии Turbo. В Enterprise та же картина, я не поленился и скачал ее.

Что же касается IDEA 7, которая сейчас в версии milestone 2 – анализатора кода у нее пока не появилось. А отличий от 6.0 в плане реализации визуального редавтора я пока не нашел. Потому рассматривать ее в данный момент тоже смысла нет.

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

Анализ реализаций

На основании имеющихся файлов можно проанализировать поведение визуальных редакторов. Чем мы и займемся.

• NetBeans. Дизайн как таковой хранится в соответствующем form-файле. В соответствии с дизайном в классе генерируется метод initComponents. С одной стороны, это позволяет застраховаться от отсутствия IDE (визуальную форму все равно удастся скомпилировать), с другой – от изменений в классе, которые могут привести к ошибкам и неправильному распознаванию визуального дизайна в случае, если бы производился разбор исходника. Визуальные элементы создаются в начале initComponents. При использовании GridBagLayout используется одна переменная gridBagConstraints, причем экземпляр пересоздается для каждого элемента дизайна. Соответственно, при загрузке визуальной формы редактор читает form-файл.

• Eclipse. Создается множество методов getXXX – собственно, по одному на каждый компонент визуального дизайна. Для каждого элемента создается своя переменная типа GridBagConstraints, причем в том методе, который отвечает за создание лежащего уровнем выше контейнера. Каждый визуальный элемент инициализируется при первом обращении к его методу getXXX. Соответственно, визуальный редактор опирается на анализ кода.

• JBuilder. Все визуальные элементы инициализируются в момент их объявления. Создается метод jbInit, который содержит код, выставляющий заголовки, параметры и осуществляющий раскладку компонентов. Переменных типа GridBagConstraints не создается вовсе – в setConstraints передается экземпляр, создаваемый прямо там, через вызов страшного конструктора с 11-ю (!) параметрами. Визуальный редактор при загрузке формы опирается, опять таки, на анализ кода.

  Надо сказать, что такой подход имеет и плюсы. На это мне указал в обсуждении товарищ phenx и я, пожалуй, склонен с ним согласиться. Если графический дизайн создается путем анализа кода, то достаточно придерживаться определенных стандартов в написании этого самого кода, чтобы безболезненно править его и не нарушать при этом работу визуального дизайнера. Теоретически в Eclipse можно делать то же самое, но на практике – из-за используемой дизайнером стратегии отложенной инициализации (и, главное – из-за реализации этой стратегии) могут возникать конфликты, о которых я напишу ниже.

• IDEA. Вся информация находится в form-файле. Формат, разумеется, не совпадает с форматом NetBеans, хотя бы потому, что IDEA использует собственные параметры для настройки раскладок – вместо gridx/gridy/gridwidth/gridheight в form-файле присутствуют column/row/col-span/row-span, fill и anchor тоже заменяются. Редактор читает form-файл и на его основе создает форму для дизайна. Исходный код, если он есть, генерируется заново при каждой сборке.

• JFormDesigner. Информация, опять-таки, находится в form-файле. Формат, опять-таки разумеется, не совпадает ни с NetBeans, ни с IDEA. Исходный код генерируется. Более того, это даже не всегда делается автоматически – в standalone-версии присутствует специальная кнопка Generate Java Code.

Что из этого всего следует? А то, что форматы, равно как и поведение редакторов при загрузке кода, не совпадают даже приблизительно. А, следовательно, ни один редактор не сможет с налета понять формат (и, следовательно, загрузить проект) другого.

Единственная надежда – возможно, есть шанс импортировать проект, созданый в одном редакторе, в другой. Как обстоят дела с этим?

Неважно обстоят. Может, с помощью очередного плагина Eclipse это и умеет. Но я такой возможности не нашел. JBuilder даже не стоит подозревать в способности что-либо импортировать (а тем более теперь). NetBeans – теоретически у него заявлена способность импортировать проекты Eclipse и JBuilder 2005, с помощью плагинов, которые за несколько минут ставятся через Update Center. Проверил. Ставятся. Результат следующий – плагин для импорта проектов JBuilder валится, даже не начав работу. (Кстати, попытка сообщить об этом баге встречает такое количество препятствий, что непонятно, кому это нужно больше – мне или им.) Плагин для импорта проектов Eclipse радостно заявляет – похоже, этот проект создавался плагином Eclipse, сделаю что смогу – и, естественно, визуальную форму не понимает, импортируя только код.

При пересмотре статьи я проверил ситуацию в версии 5.5. Чуть лучше – импорт проекта JBuilder не валится. Но и только. Открыть импортированный дизайн в визуальном режиме не получается, импортируется только исходный код.

Что же касается IDEA – импорт проектов заявлен для JBuilder, но на практике импортируется только код. Визуальных форм из него не получить.

У IDEA 6 есть еще одно умение. В ней можно запустить любое Java-приложение, имеющее визуальную форму, после чего запустить т.н. form snapshot, который проанализирует открытое окно и даст возможность любой имеющийся в форме контейнер импортировать как визуальную форму. Ради эксперимента я сделал это с изначальным окном, скомпонованым вручную. Долгое время ничего хорошего из этого не получалось. Разработчики объяснили, что там есть баг, который будет исправлен в 6.0.2. После выхода этой версии я снова попробовал – и результат был идентичен исходному. Респект. На других окнах результат меня более чем удовлетворял и раньше. Так что когда эта функциональность будет окончательно доведена до ума – импортирование элементов интерфейса, сделаных в других редакторах, будет достаточно простым делом.

У JFormDesigner заявлен импорт форм NetBeans и IDEA. И самое интересное – работает. :) Не без тонкостей, правда. При импорте формы NetBeans JFormDesigner заявил, что у формы нет свойства minimumSize (при том, что он работает на JRE 1.6.0, с включенной опцией совместимости кода с версией JRE). Соответственно, это свойство JFormDesigner убрал, после чего перегенерировал весь исходный код, который был создан NetBeans. Но форма хоть показывалась нормально.

С IDEA получилось хуже. В исходном коде, сгенерирвоанном IDEA, JFormDesigner не распознал объявлений переменных и добавил их еще раз. С теми же именами. Ну и свой метод initComponents, до кучи к уже имеющемуся $$$setupUI$$$, причем вызов последнего не убрал. В общем, полученный исходник даже не скомпилировался. Когда имеется один такой файл – это поправимо. Когда их 100...

Анализ и сравнение возможностей IDE

В этой части мы посмотрим на вышеупомянутые IDE с точки зрения их потенциальных возможностей в визуальном дизайне. Я сделал снимки палитр компонентов, на которые вы можете посмотреть при желании: NetBeans 5 (вся палитра), Eclipse 3.2 + VE 1.2 (компоненты, контейнеры, меню), JBuilder 2005 (компоненты, контейнеры), IDEA 6 (вся палитра), JFormDesigner 3.0.4 (палитра компонентов, остальные палитры). Дальше я просуммирую то, что на них видно.

За основу я взял компоненты, фигурирующие в Java SE 5, пакет javax.swing (AWT я не буду рассматривать, имхо, это уже сильно устаревший подход). Часть компонентов поддерживается всеми пятью IDE, потому я их просто перечислю: JButton, JCheckBox, JComboBox, JEditorPane, JLabel, JList, JPanel, JPasswordField, JProgressBar, JRadioButton, JScrollBar, JScrollPane, JSlider, JSplitPane, JTabbedPane, JTable, JTextArea, JTextField, JTextPane, JToolBar, JTree. Оставшаяся часть вынесена в таблицу.

Components	NetBeans	Eclipse	JBuilder	IDEA	JFD
Box
JApplet
JColorChooser
JDesktopPane
JDialog
JFileChooser
JFormattedTextField
JFrame
JInternalFrame
JLayeredPane
JMenuBar
JOptionPane
JPopupMenu
JSeparator
JSpinner
JToggleButton
JToolBar.Separator
JWindow

Надо сказать, что в этом списке присутствует довольно много компонентов. И некоторые из них, такие как JDesktopPane, JFormattedTextField, JLayeredPane, JMenuBar, JSpinner, JToggleButton, весьма полезны и довольно активно используются.

Перейдем теперь к поддерживаемым раскладкам (layouts). Опять-таки, я сделал снимки экрана, на которых видны все поддерживаемые раскладки: NetBeans, Eclipse, JBuilder, IDEA, JFormDesigner. Ниже приведена суммирующая таблица.

Layout	NetBeans	Eclipse	JBuilder	IDEA	JFD
BorderLayout
BoxLayout
CardLayout
FlowLayout
GridLayout
GridBagLayout				*	*
SpringLayout

^* Замечания. Как я уже писал выше, GridBagLayout поддерживается IDEA, правда, с некоторыми оговорками/ограничениями – в списке свойств нет настроек gridx/gridy/gridwidth/gridheight плюс совмещение fill/anchor. Такое же совмещение наблюдается у JFormDesigner. Менеджер раскладки GridLayout у IDEA свой, стандартного в списке нет. JFormDesigner же поддерживает как стандартный GridLayout, так и вариант IDEA (в меню присутствует IntelliJ IDEA GridLayout).

Как видите, если сравнивать со стандартным набором раскладок, доступным в JavaSE (http://java.sun.com/docs/books/tutorial/uiswing/layout/visual.html), то тут тоже не все гладко. Для меня остается загадкой, почему разработчики визуальных редакторов дружно игнорируют SpringLayout, хотя он существует с версии 1.4.

Ответ на этот вопрос удалось получить опять-таки от разработчиков IDEA. SpringLayout используется крайне редко, однако достаточно сложен в реализации режима визуального дизайнера.

Помимо стандартных раскладок NetBeans, JBuilder и IDEA имеют несколько собственных. Это AbsoluteLayout у NetBeans, XYLayout, PaneLayout, VerticalFlowLayout, BoxLayout2 и OverlayLayout2 – у JBuilder, Form (JGoodies) и GridLayoutManager(IntelliJ) – у IDEA, FormLayout (JGoodies) и TableLayout – у JFormDesigner.

Непоследок – о визуальном редактировании меню.

У NetBeans в палитре присутствует только JMenuBar, который, будучи положеным на форму, отображается как положено. На этом его визуальная компоновка (в смысле, в том же окне, что и компоновка основной формы) закончена. Все действия производятся в Object Inspector-е (вот тут это видно наглядно).

Eclipse позволяет визуально редактировать меню, но только верхний его уровень. Т.е. те меню, которые находятся в menubar-е. Все, что находится в них, уже не видно. При этом меню отображается в Object Inspector-е, в который и можно кидать мышкой все нужные компоненты.

JBuilder содержит содержит отдельный редактор меню (как это было сделано в Delphi, кстати, весьма удобно), однако, не без сюрпризов. Сделать меню второго уровня мне не удалось – в редакторе соответствующая кнопка просто запрещена. Возможно, это следствие версии Foundation, потому недостатком считать не буду. Нажатие же одной из кнопок просто убило IDE. Она исчезла с экрана без объявления войны.

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

У JFormDesigner с редактированием меню все в порядке. Все делается в том же окне, что и редактирование формы, меню можно делать любого уровня вложенности.

Вот мы и дошли до последней части, а именно –

Размышления и выводы

Итак. К каким негативным последствиям может привести использование визуальных редакторов. Я вижу три основных, на которых остановлюсь.

Последствие 1. Привязка к среде разработки

Как я уже говорил выше, на текущий момент миграция визуального дизайна из одной IDE в другую невозможна (опять-таки подчеркиваю – плагинов к Eclipse я не искал, но мне почему-то кажется, что если они и есть, то картину не изменят). Следовательно, при ориентации на визуальный дизайн вы автоматически привязываетесь к средству разработки. Возможно, в меньшей степени это касается IDEA, имеющей form snapshot. Да и то, на неё перейти, может быть, и просто, а вот c неё...

Кроме этого, многие компании предлагают в своих IDE дополнительные возможности. Особенно этим любит заниматься Borland, достаточно взглянуть на список палитр JBuilder. Разумеется, все эти компоненты реализованы Borland. И их нет больше нигде. Как только вы начинаете их использовать – вы еще сильнее привязываетесь к JBuilder. А в будущем вас может ожидать неприятный сюрприз, например, когда проект уже разработан до конца, с использованием таких замечательных компонентов, а потом оказывается, что при использовании в коммерческих приложениях эти компоненты платные. СИЛЬНО платные. Прецеденты были.

Почему привязка плоха? Ну, во-первых, ограничение в гибкости – это плохо всегда. Прекратится разработка IDE, или же пойдет не в ту сторону, в которую вам нужно – и вы будете вынуждены оставаться на ней, ибо затраты на переход на другую IDE могут быть очень и очень существенны. Прежде всего потому, что вы потеряете весь визуальный дизайн, на который ориентируетесь. То есть вам придется просто восстановить все визуальные формы в другой IDE. Фактически, перерисовать их заново. При этом, возможно, сталкиваясь с конфликтами.

Пример такого конфликта. Eclipse не позволяет назвать полосу меню именем menuBar. Знаете, почему? Потому что там используется отложенная инициализация всех визуальных компонентов, соответственно, для каждого из них генерируется метод getXXX. Я об этом уже говорил, когда анализировал реализацию. Так вот, поскольку у Frame уже есть метод getMenuBar, Eclipse не может создать такой метод, потому и запрещает это имя.

Кстати, я вас призываю отнестись к моим словам о возможном прекращении разработки во всей серьезностью. Ибо пример перед вами. Называется он – JBuilder 2007. С этой IDE я сталкивался еще в 2001-м году. Когда-то JBuilder был в лидерах, и, смею вас уверить, кода с его помощью написано немало. И визуальных форм – в том числе. А если вы думаете, что CodeGear предусмотрела миграцию – вы жестоко ошибаетесь. Передо мною JBuilder 2007 Migration Guide, раздел JBuilder Project Migration Overview, Unsupported Properties. И в этом разделе черным по белому – jbInit() Method. При миграции он остается в коде (в смысле, его не вырезают – как это любезно!), но и только. Анализировать его Visual Editor не в состоянии. Таким образом, ВСЕ визуальные формы, скомпонованные в JBuilder, остаются в версии 2006.

Чем еще плоха привязка к IDE? Тем, что есть...

Последствие 2. Ограничение в используемых средствах

Посмотрите на таблицы в разделе Анализ и сравнение возможностей IDE. Я не случайно сделал их именно таблицами, так нагляднее. По ним ясно видно, что возможности IDE различаются, и нет такой, которая бы перекрывала все остальные. Теоретически можно выбрать, например, NetBeans или JFormDeigner, поскольку их возможности, похоже, наилучшие среди всех рассмотренных IDE. Но это всего лишь чуть-чуть выправит ситуацию, и то только в плане стандартных компонентов.

Практика же показывает, что стандартных компонентов чаще всего недостаточно. Что делать в этом случае? Ну ладно, например, компоненты, которые распространяются как отдельные библиотеки – JFreeChart, JReport и иже с ними – их можно подключить как внешние библиотеки. IDE это позволяют и даже дадут использовать эти компоненты в визуальном режиме. Но очень много компонентов пишется самостоятельно. Часто – как внутренние классы, сильно связанные с включающими их классами, использующие данные этих классов. Разделять их в данном случае только муторно и ничего больше. Ибо отдельный компонент – это public API, к которому относиться надо куда более строго. Это другие решения в плане дизайна, доступа к компонентам, к данным и т.п. Очень часто дело того не стоит и гораздо проще сделать компоненты сильно связанными. И в этом случае добавление их в палитру IDE может стать проблематичным.

В теории в рассмотренных IDE есть возможность выбрать по полному имени класса JavaBean и использовать его в дизайнере. На практике – множество ограничений. Для Eclipse и JFormDesigner необходимо, чтобы класс, который мы хотим использовать, был в classpath. Т.е. он должен быть скомпилирован. Учитывая, что в standalone-режиме JFormDesigner компилировать исходный код не умеет – там такую возможность как "нарисовать компоненту, а потом положить ее на другую" использовать просто не получится. Если он подключен как плагин к IDE – тогда пожалуйста. Да и то, достаточно сбросить все скомпилированные ресурсы, а потом переоткрыть IDE – и вместо компонент JFormDesigner показывает красные прямоугольники. Плюс к этому, я сталкивался с ситуацией, когда JFormDesigner не воспринимал как контейнер наш собственный компонент, унаследованный от JPanel, соответственно, не давая выставить ему раскладку. Приходилось вставлять в дизайне JPanel, а потом преобразовывать (morph в терминах JFormDesigner) в то, что нам надо. NetBeans позволяет выбрать только класс из подключенного jar-файла (возможность использовать компоненты из текущего проекта появилась только в версии 6.0). IDEA позволяет использовать как классы, так и формы.

Помимо уже описаной возможности IDEA, например, позволяет еще и написать метод, в котором создание компонент можно реализовать вручную. Однако тут кроется большое "но", о котором чуть ниже.

Кроме того, ни у одной IDE я не видел способа добавить в визуальный режим собственный менеджер раскладки. В теории GridBagLayout может покрыть почти что³ все случаи, на практике же может быть гораздо удобнее использовать свою собственную раскладку.

В прошлой версии статьи в конце предыдущего абзаца было две фразы: Хотя будем справедливыми – а кто хоть раз писал свой менеджер компоновки? Потому считать это таким уж большим минусом не буду. На текущем месте работы я столкнулся с ситуацией, когда у разработчиков собственные менеджеры компоновки. Так что прецедент есть.

Оба вышеуказаных последствия в конечном итоге приводят к...

Последствие 3. Изучение IDE вместо изучения языка

Чем больше разработчику возможностей предоставляет IDE, тем меньше ему нужно думать. Достаточно всего лишь взять нужную компоненту и кинуть ее на форму. Особенно это проявляется при работе с JBuilder, у которого с Delphi – помните, с чего начиналась статья? – один разработчик. Взгляните еще раз на список палитр. При работе с базой данных просто чешутся руки открыть палитры dbSwing, More dbSwing и dbSwingModels. Там же есть все, что нужно для счастья. И откроют. И используют. И привяжутся намертво. А самое неприятное – это ответ на вопрос "как работать с базой?". "Взять компоненту..." Компоненты полностью скрывают от разработчика происходящее. Да, это удобно. Но не ценой незнания этого самого происходящего. Потому что кто-нибудь может несколько лет писать приложения для работы с базами данных и при этом не иметь ни малейшего представления о JDBC.

И это относится не только к базам данных и JBuilder. Новичок может взять IDEA и использовать ee GridBagLayout, с ee настройками. В IDEA он сможет много. Но при переходе на любую другую IDE с визуальным редактором неизбежно возникнут вопросы:

• А где тут Vertical align? Horizontal align?
• А что такое gridx/gridy/gridwidth/gridheight? fill? anchor?

И ровно противоположные вопросы возникнут при переходе, скажем, с NetBeans на IDEA:

• А что такое Vertical align? Horizontal align?
• А где тут gridx/gridy/gridwidth/gridheight? fill? anchor?

И так далее, и так далее, и так далее. Использование IDE вообще резко понижает планку необходимого количества знаний. Визуальные же редакторы только усугубляют ситуацию. Очень хорошим тестом является следующий – дать разработчику сделать визуальный дизайн, но без кликательного редактора. Недавно выдал такую задачу одному из коллег. В визуальном режиме он накидал бы эту компоненту за пару часов (там порядка 30 элементов было, и раскладка не очень простая). Реально он потратил на дизайн практически два дня. Еще одному коллеге я такую задачу давать просто боюсь.

Теперь, пожалуй, можно сформулировать ответ на вопрос – почему же я не люблю визуальные IDE?

Я не люблю визуальные IDE потому что:

1. ...они обеспечивают привязку к себе
2. ...они несколько ограничивают разработчика в используемых средствах
3. ...они подменяют изучение языка на изучение возможностей IDE. Тем самым они понижают как объем полученных в процессе работы знаний, так и скорость их получения, что в конечном итоге сказывается на уровне профессионализма.

Несколько слов в защиту визуальных редакторов GUI

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

Так вот, я хорошо осознаю все плюсы визуальных редакторов GUI. Во-первых, они действительно способны сильно упростить разработку. И чем лучше человек знает среду, с которой работает – тем сильнее. Правда, тем сильнее и попадает от этой среды в зависимость.

Во-вторых, при использовании визуальных редакторов гораздо проще разобраться в чужом дизайне в визуальном режиме, нежели по исходному коду. Тут тоже есть свое "но" – придется использовать ту же самую среду, в которой создавался этот дизайн. В этой связи мне видится очень многообещающим направление дальнейшего движения IDEA – утверждается, что в следующей версии собираются сделать полноценный анализатор исходного кода, который позволит перейти на IDEA с любой другой среды. Если и остальные разработчики сделают что-то подобное – такой минус визуальных IDE как привязка к ним уйдет в историю.

В третьих – с учетом интереса Sun к продвижению Java на стороне клиента вполне возможен рост числа standalone-приложений, написаных на Java. А значит, появится такая ниша, как создание GUI на Javа. И в этой нише визуальные GUI-дизайнеры будут инструментом номер один.

По большому счету, вся моя нелюбовь относится даже не к GUI-редакторам, а к... как бы это выразить... отношению разработчиков к процессу разработки, что ли. Как визуальные редакторы, так и IDE в целом провоцируют разработчиков на лень. Естественно, проще кликнуть мышью одну кнопку, чем написать команду в командной строке. Или нажать Ctrl+Q и получить справку по функции, нежели открыть API в браузере. И кликают. И нажимают. Потому что больше делать – лениво. А в результате, поработав с IDE несколько месяцев (!), так и не знают, что такое classpath. И информация, которая могла бы попасться на глаза при поиске ответа по API – не попадется.

Разумеется, это выбор каждого. Можно с тем же успехом рисовать формы в визуальных редакторах и при этом отлично знать всю теоретическую основу. Но многие ли это выберут, если дизайнер все сделает за них сам? Только перетащи компоненту. Отсюда вырастает непрофессионализм. А вот его я не люблю ОЧЕНЬ сильно. И считаю провокацию на лень главным аргументом против использования визуальных редакторов GUI. Во всяком случае до тех пор, пока человек не научится делать все то же самое руками.

Подводя итоги

Хочу подвести небольшой итог проведенному обзору IDE. Для прямой свой задачи – создания GUI в визуальном режиме – пригодны все пять. Да, есть некоторые ограничения, но они, за редким исключением, на конечный результат влияют несильно. По возможностям и степени удобства я бы распределил их так (этакий субъективный рейтинг):

1. JFormDesigner
2. NetBeans
3. IDEA
4. JBuilder 2005
5. Visual Editor for Eclipse

Однако с недостатками, которые я озвучил выше – с ними за прошедший с момента появления первой версии статьи год лучше не стало. Привязка к IDE так и остается фактом. Переходы если и возможны, то только в одном направлении. Нет ни одной пары IDE, которые бы позволяли корректно импортировать проекты друг друга с учетом визуальных форм. Использовать сторонние менеджеры компоновки по-прежнему нельзя, собственные компоненты – с определенными ограничениями. И не везде. Ну и от изучения IDE тоже никуда не деться. А следовательно, увы, – я все еще не люблю визуальные редакторы. И всю работу по созданию визуальных компонент, которой у меня сейчас, прямо скажем, немало, выполняю вручную.

* * *

Напоследок хочу выразить благодарность Дмитрию Джемерову (Dmitry Jemerov) из компании JetBrains – за интерес к статье, ответы на многие мои вопросы и особенно – за аргументацию, побудившую меня в конечном итоге пересмотреть некоторые свои выводы как относительно IDEA, так и относительно визуального дизайна как явления.

* * *

Еще раз хочу подчеркнуть – все вышесказаное есть всего лишь мое мнение. Оно субъективно по определению. Как и в других статьях, я опираюсь исключительно на собственный опыт. И еще хочу предупредить сразу – в священные войны между сторонниками как различных IDE, так и различных подходов к разработке я ввязываться не собираюсь! И прошу даже не пытаться их развязать на основании данной статьи.

Всем дочитавшим до конца – спасибо!

* * *

Вместо послесловия

Буквально через пару дней после публикации этой статьи наткнулся на форуме Vingrad на один вопрос. Лучшую иллюстрацию к сделаным чуть выше выводам представить сложно. Вопрос звучал так:

Вот решил попробовать NetBeans IDE 5.0 после JBuilder2005
Но возник небольшой вопрос:
Как создать GUI приложение без редактора GUI?

И дальше:

Меня интересует такой вопрос в NetBeans
Вот открываем программу.
Начинаем создавать приложение
Выбираем File-New Projects. Открывается форма. В форме предлагается выбрать каккого вида проект будет создаваться
Я выбираю в категории Java Application. Создаю проект. После создания проекта того типа я не могу пользоваться дизайнером, даже если я на пишу в главном классе class Main extends JFrame (как например в JBuilder появляется дизайнер), а в NetBeans так нельзя.
А вот если в проекте выбрать New JFrame Form только после этого можно работать с дизайнером. Но в проекте уже два главных класса с двумя методами main, что очень неудобно, приходиться первый созданный класс без JFrame удалять. Можно создавать классы с JFrame Form без создания Java Application не имеющего JFrame или нет.

Комментарии, как говорится, излишни...

* * *

Вместо послесловия – 2

Не рассчитывал добавлять что-либо в эту статью в течение ближайшего времени. Но вот от ТАКОГО примера удержаться не смог. Цитата из одного форума, вопрос-ответ-вопрос. Речь о создании визуального интерфейса в IDEA, самые характерные места выделены мной.

спасибо, по твоему совету получилось связать форму с классом (оказывается очень просто, тяжело когда среду не знаешь), но появились еще problems. Как добавить компонент который мне надобно из библиотек?
Добавляю компонент так: Настройки=> ГУИ Дизайнер=> Добавить компонент => указываю класс добавляемого компонента (выбираю класс из добавленных библиотек (jdom.jar и xerces.jar)). Компонент добавляется, но в палитре компонентов он у меня не активен, не пойму почему, и нельзя его использовать.

С каких это пор JDOM и Xerces содержат визуальные компоненты?

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

Вдумайтесь в суть вопроса. Как можно использовать библиотеку, если она не содержат визуальных компонент, которые можно добавить в палитру и потом кинуть на форму?! Мне лично даже сказать нечего.

---

^1. Я не совсем понимаю, что побудило разработчиков IDEA выпустить в качестве beta-версии недоработанный продукт. Причем недоработанный как раз в той части, где обещались серьезные изменения. Общеизвестно, что ожидаемые продукты, к коим относится и IDEA, оценивают преимущественно по beta-версиям. Дабы по выходе финальной уже знать, что из себя представляет этот продукт, и стоит ли на него переходить. И если в beta-версии есть серьезные недоработки – маловероятно, чтобы пользователь вернулся к рассмотрению этой функциональности в финальной версии. Честно сказать, я бы и не подумал пересматривать свои выводы после выхода релиза. Мне в голову не могло придти, что от беты до релиза может измениться функциональность. Для меня бета – это окончательный вариант, возможно содержащий ошибки. Хотелось бы верить, что в следующий раз JetBrains будет более осмотрительна.

^2. JClassLib компании ej-technologies, очень удобный визуальный дизассемблер. Что немаловажно – бесплатный (лицензия GPL). Взять можно вот тут: http://www.ej-technologies.com/products/jclasslib/overview.html.

^3. Почему почти что. Дело в том, что GridBagLayout – сеточный. В смысле, он раскладывает компоненты в прямоугольных областях, размеченых по прямоугольной же сетке. Если раскладка такова, что прямоугольной сетки не предусматривает – GridBagLayout неприменим. Скажем, FlowLayout вы им просто не смоделируете.

В начало

Copyright © 2004-2013 Евгений Матюшкин aka Skipy (e-mail: skiрyskipy.ru)
Копирование и воспроизведение материалов этого сайта возможно только с согласия автора!