Сходство, скажем так, условное. Но если доработать напильником то можно добиться такого же внешнего вида как на первом скриншоте. Т.е. можно сравнивать MigLayout и Layoutless:
функционал — почти совпадает. Исключение — в MigLayout невозможно накладывать один компонент на другой т.е. сделать фоновую картинку с ключами непосредственно в определении компоновкой нельзя.
читабельность — так же как и у JGoodies FormLayout из предидущих каментов, догадаться что делает, скажем, «0[]7[]7[]push[]0» нельзя без чтения документации.
возможность допустить ошибку — также как и в JGoodies FormLayout легко ошибиться в константах и ошибка проявится только в рантайме
Итого
у MigLayout по сравнению с Layoutless меньше возможностей, хуже читабельность кода, больше вероятность допустить ошибку.
вооот. Уже лучше. Есть волшебное слово «ИМХО». Осталось привести код который компонует такую простую форму как на скриншоте и сравнить, насколько работа с привязкой к границам контейнера проще и логичней.
к сожалению сначала я запостил статический скриншот и большинство подумало что в примере просто заданы константные координаты. Сейчас скриншот показывает как меняются размеры и положение контролов в зависимости от размера формы.
Если кто-то считает что знает компоновщик позволяющий для такой небольшой формы сделать более простой и читабельный код (см. текст исходника) то просьба запостить пример реализации такого же окошка сюда для сравнения. И только потом делиться своими оценками.
ну, это у же софистика. Конечно если контейнер управляет расположением дочерних компонентов то он выполняет примерно те же функции что и копмоненты имплементирующие интерфейс LayoutManager.
На счёт хуже — выше есть сравнение с тем же FormLayout. Функционал немного отличается но читабельность и отказоустойчивость выше. Что и было конечной целью создания библиотеки.
Mozilla Fireаox — вызвать диалог настроек. Все компоненты жёстко привязаны. Например кнопки ОК, Отмена, Справка привязаны к правому нижнему углу диалога. Также как в моём примере кнопка привязана к нижнему краю.
Не хотите изучать layout manager-ы в Java? Смените род занятий и не занимайтесь больше UI.
— мне кажется из текста и из кода видно что я очень хорошо знаю что такое layout manager-ы в Java. Те кто предпочитают MigLayout могут использовать его. Те кому не нравится концепция компоновщиков в принципе могут использовать мой вариант.
FormLayout layout = new FormLayout(
"max(60dlu;p), 3dlu, p:grow", // columns
"p, 3dlu, p, 3dlu, p" // rows
);
CellConstraints cc = new CellConstraints();
builder.add(jTextField1, cc.xy(3, 1));
Читабельность
FormLayout — что делает код непонятно без изучения документации. Что такое, скажем, «3dlu» предположить сложно.
Layoutless — даже постороннему с первого взгляда ясно что у компонента задаются размер и положение (x/y они и в Африке x/y, для ширины там вполне читабельное математическое выражение).
Возможность ошибок
FormLayout — что будет если в текстовой строке спецификации указать просто «blablabla»? Что будет если указать 2 колонки по 2 компонента но добавить 5 компонентов? Причём проблемы вылезут в рантайме а не при компиляции а значит их трудней обнаружить.
Layoutless — подобные ошибки внести нельзя. Колонок нет, строк нет, текстовых описаний компоновки тоже нет. Есть только простые как штопор координаты с размерами.
Простота модификации
FormLayout — предположим что у первого текстового поля понадобилось добавить кнопку для вызова диалога выбора файла. Нужно переделать описание столбцов и рядов на каком-то миниязыке типа «max(60dlu;p), 3dlu, p:grow» (или как они это называют comma separated encoded specifications).
Layoutless — нужно уменьшить ширину поля:
getContentPane().add(jTextField1, new AbsoluteConstraints(110, 8, 100, -1));
— тут заданы константные координаты
.item(new ComponentBox()
.component(jTextField1)
.width(layoutless.width().minus(labelsWidth).minus(16))
.height(22)
.x(labelsWidth+8)
.y(8+25*0)
)
— тут ширина поля меняется при изменении размеров окошка. Из кода layoutless.width().minus(labelsWidth).minus(16) понятно что это
ширина — отступ — 16
это не декларативное описание в XML. Это чистая Java со всеми минусами и плюсами. Просто благодаря некоторым финтам выглядит как декларация. Для Java код выглядит непривычно но есть наглядность, простота и с первого взгляда понятно что где задаётся.
есть выбор — можно изучать менеджеры компоновки, можно сразу начинать работать. Тем кто часто и много рисует формы эта библиотека, вероятно, упростит часть работы.
Что такое локализация с точки зрения общего случая:
это набор значений которые зависят от одного переключателя. Необязательно это язык. Например это могут быть настройки режимов видимости полей/кнопок
— Продвинутый — видно всё
— Для начинающих — видно только основное а остальное в меню
Для таких вещей в библиотеке есть класс Fit
Пример public static void main(String[] a) {
System.out.println("\nFit\n");
Fit‹String› g = new Fit‹String›()
.item("English", "w1", "First")
.item("English", "w2", "Second")
.item("English", "w3", "Third")
.item("Spain", "w1", "Primero")
.item("Spain", "w2", "Segundo")
.item("Spain", "w3", "Tercera");
Note s1 = new Note().bind(g.find("w1"));
Note s2 = new Note().bind(g.find("w2"));
Note s3 = new Note().bind(g.find("w3"));
Note s4 = new Note().bind(g.find("w4"));
System.out.println("/set English");
g.selector().value("English");
System.out.println(s1.value() + ", " + s2.value() + ", " + s3.value() + ", " + s4.value());
System.out.println("/set Spain");
g.selector().value("Spain");
System.out.println(s1.value() + ", " + s2.value() + ", " + s3.value() + ", " + s4.value());
}
Вычислительные затраты минимальны по сравнению, скажем, с выполнением запроса к базе данных или парсингом XML. Вряд ли можно говорить о хоть каком-то влиянии на производительность.
Сходство, скажем так, условное. Но если доработать напильником то можно добиться такого же внешнего вида как на первом скриншоте. Т.е. можно сравнивать MigLayout и Layoutless:
функционал — почти совпадает. Исключение — в MigLayout невозможно накладывать один компонент на другой т.е. сделать фоновую картинку с ключами непосредственно в определении компоновкой нельзя.
читабельность — так же как и у JGoodies FormLayout из предидущих каментов, догадаться что делает, скажем, «0[]7[]7[]push[]0» нельзя без чтения документации.
возможность допустить ошибку — также как и в JGoodies FormLayout легко ошибиться в константах и ошибка проявится только в рантайме
Итого
у MigLayout по сравнению с Layoutless меньше возможностей, хуже читабельность кода, больше вероятность допустить ошибку.
Если кто-то считает что знает компоновщик позволяющий для такой небольшой формы сделать более простой и читабельный код (см. текст исходника) то просьба запостить пример реализации такого же окошка сюда для сравнения. И только потом делиться своими оценками.
На счёт хуже — выше есть сравнение с тем же FormLayout. Функционал немного отличается но читабельность и отказоустойчивость выше. Что и было конечной целью создания библиотеки.
Не надо преувеличивать.
— мне кажется из текста и из кода видно что я очень хорошо знаю что такое layout manager-ы в Java. Те кто предпочитают MigLayout могут использовать его. Те кому не нравится концепция компоновщиков в принципе могут использовать мой вариант.
Код Layoutless:
Код FormLayout:
Читабельность
FormLayout — что делает код непонятно без изучения документации. Что такое, скажем, «3dlu» предположить сложно.
Layoutless — даже постороннему с первого взгляда ясно что у компонента задаются размер и положение (x/y они и в Африке x/y, для ширины там вполне читабельное математическое выражение).
Возможность ошибок
FormLayout — что будет если в текстовой строке спецификации указать просто «blablabla»? Что будет если указать 2 колонки по 2 компонента но добавить 5 компонентов? Причём проблемы вылезут в рантайме а не при компиляции а значит их трудней обнаружить.
Layoutless — подобные ошибки внести нельзя. Колонок нет, строк нет, текстовых описаний компоновки тоже нет. Есть только простые как штопор координаты с размерами.
Простота модификации
FormLayout — предположим что у первого текстового поля понадобилось добавить кнопку для вызова диалога выбора файла. Нужно переделать описание столбцов и рядов на каком-то миниязыке типа «max(60dlu;p), 3dlu, p:grow» (или как они это называют comma separated encoded specifications).
Layoutless — нужно уменьшить ширину поля:
и добавить на освободившееся место кнопку
Итого:
У Layoutless по сравнению с FormLayout лучше читаемость, меньше возможностей допустить ошибку, проще (ну, или очевидней) модификация кода.
Логично?
— тут заданы константные координаты
.item(new ComponentBox()
.component(jTextField1)
.width(layoutless.width().minus(labelsWidth).minus(16))
.height(22)
.x(labelsWidth+8)
.y(8+25*0)
)
— тут ширина поля меняется при изменении размеров окошка. Из кода layoutless.width().minus(labelsWidth).minus(16) понятно что это
ширина — отступ — 16
это набор значений которые зависят от одного переключателя. Необязательно это язык. Например это могут быть настройки режимов видимости полей/кнопок
— Продвинутый — видно всё
— Для начинающих — видно только основное а остальное в меню
Для таких вещей в библиотеке есть класс Fit
Пример
public static void main(String[] a) {
System.out.println("\nFit\n");
Fit‹String› g = new Fit‹String›()
.item("English", "w1", "First")
.item("English", "w2", "Second")
.item("English", "w3", "Third")
.item("Spain", "w1", "Primero")
.item("Spain", "w2", "Segundo")
.item("Spain", "w3", "Tercera");
Note s1 = new Note().bind(g.find("w1"));
Note s2 = new Note().bind(g.find("w2"));
Note s3 = new Note().bind(g.find("w3"));
Note s4 = new Note().bind(g.find("w4"));
System.out.println("/set English");
g.selector().value("English");
System.out.println(s1.value() + ", " + s2.value() + ", " + s3.value() + ", " + s4.value());
System.out.println("/set Spain");
g.selector().value("Spain");
System.out.println(s1.value() + ", " + s2.value() + ", " + s3.value() + ", " + s4.value());
}
Результат
Fit
/set English
First, Second, Third, null
/set Spain
Primero, Segundo, Tercera, null