GroupLayout: Стоит ли учиться?

Ответ 1

Я бы сказал, что стоит потратить некоторое время на понимание GroupLayout, хотя бы потому, что всегда полезно понять, что делает ваша IDE. Знание того, что происходит за кулисами, на самом деле делает вас более гибким, потому что, если вы завершаетесь в ситуации, когда у вас нет доступа к Netbeans, вы узнаете, как реплицировать макет, который он подготовил для вас. Кроме того, после того, как вы приобретете приличный опыт, вы, вероятно, закончите экономить время в целом. Вы можете часто разрабатывать простой графический интерфейс быстрее вручную, чем с помощью визуального редактора, особенно учитывая время, необходимое для копирования и вставки кода из Netbeans в Eclipse.

И, конечно же, научиться использовать GroupLayout вручную также упростит переход на любой из других менеджеров макетов Java-предложений, что, в свою очередь, может привести к более простому коду и еще более экономить время.

Ответ 2

GroupLayout не был предназначен для ручного кодирования; это намного, много более подробный, чем любой другой менеджер компоновки (кроме, возможно, GridBagLayout). Поскольку вы говорите, что вы новичок в Swing, я предлагаю начать с основных менеджеров макетов (BorderLayout и FlowLayout); вы можете использовать их в NetBeans, щелкнув правой кнопкой мыши панель или фрейм и выбрав "Установить макет". После того, как вы знакомы с ними, я предлагаю вам проверить MiGLayout.

Чтобы ответить на другой вопрос: я думаю, что дизайнер форм NetBeans похож на калькулятор; это замечательный инструмент, если вы уже знаете основы, но вы никогда не узнаете ничего, если просто используете его как костыль.

Ответ 3

GroupLayout стоит учиться использовать программно.

Я использую GroupLayout как мой макет по умолчанию на почти каждой панели, которую я создаю, которая использует стандартные компоненты Swing. Я считаю, что результаты всегда очень приятны для глаз и очень сильно изменяются. Я всегда задавал следующие параметры:

groupLayout.setAutoCreateGaps(true);
groupLayout.setAutoCreateContainerGaps(true);

Использование этого макета неоднократно давало мне не просто красивые макеты, но это дает мне опыт низкого уровня, необходимый для того, чтобы собрать несколько сложных панелей с рядом компонентов, которые неизвестны во время компиляции. Я также обнаруживаю, что когда число компонентов является динамическим, я могу выложить все компоненты, а затем включить и выключить их с помощью setVisible(boolean) без воссоздания горизонтальной и вертикальной групп.

Ответ 4

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

Я считаю, что этим менеджерам макетов не стоит учиться. GridBagLayout хуже всего. У него больше вариантов, чем вы можете понять, и они никогда не делают того, что, по вашему мнению, они делают. MiGLayout очень мощный, разумно интуитивно понятный и в основном делает то, что, по вашему мнению, он делает, но я все же буду спорить, что он слишком мощный и слишком сложный для него, а программист - хороший. GroupLayout не такой мощный, а не интуитивный, и не стоит проблем.

Мой совет с лет разработки Java GUI и его поддержки состоит в том, чтобы изучить и использовать самый мощный менеджер макетов, который вы можете освоить за два часа, и что вы никогда не забудете, а затем планируйте свой графический интерфейс с вложенными контейнерами с помощью этого менеджера макетов и базовый BorderLayout/GridLayout/FlowLayout/BoxLayout.

Ответ 5

Если вы склонны к стилю VB, вы тратите время на GroupLayouts. В противном случае попробуйте понять GridBagLayout Manager с подходящими примерами. Это лучшее для тех, кто хочет, чтобы каждый компонент gui находился под контролем пера (мы должны писать, а не IDE). Хороший разработчик Java должен тратить время на объекты gui и бизнес-объекты и должен знать, как их разделить. L.Sankaranarayanan.