Comments 56
6. Для того, чтобы дать пользователю возможность выбирать даты есть отличный компонент jcalendar
Он не отличный. JDateChooser меня разочаровал следующим:
1. не поддерживает выравнивание по базовой линии (baseline)
2. есть проблемы с обнулением даты внутри него
3. нет возможности дать пользователю ввести 1.02.12 и чтобы JDateChooser интерпретировал это как 1.02.2012; такое можно вылечить самому, но это дополнительная подпорка.
4. плохо дружит с различными темами; в частности, у меня были проблемы с Nimbus и substance.
9. Для того, чтобы изменить компоненты swing из другого потока нужно использовать посредника:
Есть базовый механизм запуска произвольного кода в потоке GUI — invokeLater. А всякие SwingWorker'ы — это уже механизмы поверх.
В целом разработка под swing парадовала обилием документации и примеров на все случаи жизни. Если интересно могу еще в том же духе поподробней рассказать про фишки JTable.
В целом Swing разочаровывает. Такое ощущение, что его писали какие-то стоумовые ребята, которые сели, выдумали концепцию, а потом всё это им осточертело на стадии реализации и они сделали всё тяп-ляп, для галочки. А местами просто ужасно перемудрили (например, как с Action'ами и привязкой их к кнопкам и клавиатуре). Про JTable я вообще молчу — на каждую тривиальную штуку приходится городить серьёзные костыли. Ну и сама Java местами подводит — например, в языке нет механизма для лаконичной подписки на события. Или вот swing делался в те времена, когда ещё не было enum'ов, потому всякие флажки и перечисления сделаны числовыми константами — это просто ужасно.
С последним абзацем полностью согласен. Ни enum ни generic в swingе нету (печально).
Для событий, чтобы не мораться с Action и листенерами можно попробовать event bus из google guava использовать. Я только начал ее внедрять, пока что показывается себя не плохо.
Для событий, чтобы не мораться с Action и листенерами можно попробовать event bus из google guava использовать. Я только начал ее внедрять, пока что показывается себя не плохо.
А каковы альтернативы? Есть SWT, который меня ужасает почти всем, кроме своего внешнего вида и есть Qt, который непонятно, развивается, но по крайней мере всем остальным хорош.
Чем именно ужасает SWT? (Надеюсь, вы не забыли про существование JFace)
Не забыл. Первое — кошмарный способ задавания свойст (C-style), второе — отсутствие груплэйаута. Третье — я работаю с RCP и кнопки на тулбаре — полный песец. Вообща вся эта концепция — тихий ужас.
1. Ну стили это да, но можно вытерпеть, они не такую уж большую часть кода занимают.
2. На базе GridLayout можно построить 95% всех нужных форм. Если не получается — есть ещё FormLayout. Ну и свой менеджер написать никто не запрещает на самый крайний случай (и они уже есть).
3. Что с кнопками? Не знаю, что за у вас оконная система, но мне кажется, выглядят они не ужаснее, чем в Firefox, например.
Ну и эмоции — это не совсем хорошо.
2. На базе GridLayout можно построить 95% всех нужных форм. Если не получается — есть ещё FormLayout. Ну и свой менеджер написать никто не запрещает на самый крайний случай (и они уже есть).
3. Что с кнопками? Не знаю, что за у вас оконная система, но мне кажется, выглядят они не ужаснее, чем в Firefox, например.
Ну и эмоции — это не совсем хорошо.
1. Безусловно.
2. Не нравятся они мне. Мне нравится свинговый GroupLayout, все остальные не так мощны.
3. Нет выглядят они нормально. Но как они задаются…
2. Не нравятся они мне. Мне нравится свинговый GroupLayout, все остальные не так мощны.
3. Нет выглядят они нормально. Но как они задаются…
2. Не нравятся они мне. Мне нравится свинговый GroupLayout, все остальные не так мощны.Мне тоже нравился вначале GroupLayout. Но вообще, там внутри концепция мозгоразрывная. А единственный вменяемый дизайнер из Netbeans тоже имеет ряд глюков и иногда перекашивает весь layout, и ничего не поделаешь. Так что теперь склоняюсь к GridBagLayout. Хотя, layout'ы в AWT/Swing кривоваты. Например, у GridBagLayout нельзя задавать промежутки между ячейками (insets — это несколько другое).
Есть такая флэшка — totally gridbag называется. Стоит посмотреть.
Теперь кроме нетбинсовского матиса есть еще гугловский WindowBuilder Pro. Работает намного адекватнее и код красивее получается.
Теперь кроме нетбинсовского матиса есть еще гугловский WindowBuilder Pro. Работает намного адекватнее и код красивее получается.
WindowBuilder Pro пишут люди, которые живут со мной в одном городе. Свинговым дизайнером для GroupLayout они не заморачивались, а взяли оный из матиса. Говорят, что у них от GroupLayout разорвало мозг.
Как минимум он работает более гибко. Но в принципе, я не встречал случаев, когда матис работает некрасиво. просто код изящнее получается у WindowBuilder. А что за город?
Липецк. Люди, которые сделали WindowBuilder изначально тут жили. Потом их программу купил instantiations, а потом — гугл. Сейчас вроде поразъехались кто куда (в том числе, зарубеж).
Ну, со времен instantiations windowBuilder несколько изменился. Хотя я давно уже не пользовался, если честно.
Основное отличие от Netbeans — это парсинг живого кода и создание модели из него. В нетбинсе модель хранится в xml, причём с ограничениями: не все плюшки GL поддерживаются (какие — уже не помню). Ну и кодогенератор малость подкрутил, вот и все отличия. ;)
Пардон, комментарии раз в пять минут.
Пардон, комментарии раз в пять минут.
>отсутствие груплэйаута
Пользуйтесь на здоровье: code.google.com/a/eclipselabs.org/p/windowbuilder-extras/source/browse/
Пользуйтесь на здоровье: code.google.com/a/eclipselabs.org/p/windowbuilder-extras/source/browse/
Вот что вспомнилось навскидку:
1. Хотя бы своим классом SWT с кучей констант.
2. А есть ли в SWT вообще понятие baseline (вроде бы у меня с этим какие-то проблемы возникали)?
3. Таблица в SWT не менее убогая, чем в Swing.
4. Загрузить иконку из ресурсов — нужен дополнительный велосипедный костыль.
5. Неудобная обработка событий клавиатуры. Нет аналога event bubbling из DOM Events, события обрабатываются только тем контролом, который в фокусе.
1. Хотя бы своим классом SWT с кучей констант.
2. А есть ли в SWT вообще понятие baseline (вроде бы у меня с этим какие-то проблемы возникали)?
3. Таблица в SWT не менее убогая, чем в Swing.
4. Загрузить иконку из ресурсов — нужен дополнительный велосипедный костыль.
5. Неудобная обработка событий клавиатуры. Нет аналога event bubbling из DOM Events, события обрабатываются только тем контролом, который в фокусе.
Baseline я пытался поддержать, получилось более-менее сносно только под Linux Gtk и MacOS X Cocoa. Windows — almost no way, только аппроксимация.
1. Многие из кучи этих констант трудно было бы отнести к какому-то отдельному классу, поэтому они универсальные. Ну с точки зрения «православного» ООП, стили в виджеты следовало бы передавать через java.util.Set, но это довольно тяжеловесный объект, да и создавать его достаточно многословно. А EnumSet в те времена ещё не существовал.
2. Понятия baseline у стандартных виджетов и layout managers нету, но при необходимости можно реализовать такой менеджер. Свойства для baseline в базовом классе Control не предусмотрено, но к каждому контролу можно прилеплять метаинформацию через setData().
3. Не убогие таблицы есть только в Excel :), но там они не являются нативными контролами.
4. Загрузка иконки стандартными методами
При помощи самописного класса:
5. Глобальный обработчик событий клавиатуры можно повесить на Display методом addFilter().
2. Понятия baseline у стандартных виджетов и layout managers нету, но при необходимости можно реализовать такой менеджер. Свойства для baseline в базовом классе Control не предусмотрено, но к каждому контролу можно прилеплять метаинформацию через setData().
3. Не убогие таблицы есть только в Excel :), но там они не являются нативными контролами.
4. Загрузка иконки стандартными методами
ImageRegistry registry = new ImageRegistry(display);
registry.put(APP_ICON_32, ImageDescriptor.createFromFile(MyMainWindow.class, "images/icon-32.png"));
Image icon = registry.get(APP_ICON_32);При помощи самописного класса:
CustomImageRegistry registry = new CustomImageRegistry(display, MyMainWindow.class, "/images/");
Image icon = registry.load("icon-32.png");5. Глобальный обработчик событий клавиатуры можно повесить на Display методом addFilter().
расскажи, как получить baseline у контролов под Windows? ;)
Получить — видимо, нельзя. Можно «придумать» и поддерживать где надо.
Вот интересно, а как тогда винформовский дизайнер умел этот baseline показывать?
Там тоже аппроксимация. Вычисляют приблизительно положение baseline исходя из text alignment и text extent. Далее значение уточняется в instance of ControlDesigner, который навешан на каждый контрол.
Ну да, скорее всего через WinAPI у контролов нельзя получить baseline. Но взять DC и получить у него FontMetrics для того шрифта, которым нарисован контрол, всегда можно. Плюс взять theme API и добавить всякие отступы контрола. Тогда получится примерное положение вещей. Другое дело, что если такая штука не зашита в сам фреймворк (коим является SWT), то её сбоку не прикрутишь — придётся для разных платформ разный код писать. В Swing такой проблемы нет, потому что контролы рисуются не системой, а Java'ой. Так что тот факт, что у SWT нет baseline — ещё один камень в огород.
1. Многие из кучи этих констант трудно было бы отнести к какому-то отдельному классу, поэтому они универсальные. Ну с точки зрения «православного» ООП, стили в виджеты следовало бы передавать через java.util.Set, но это довольно тяжеловесный объект, да и создавать его достаточно многословно. А EnumSet в те времена ещё не существовал.
Ну вообще, никуда константы не надо относить. Под константы, сгруппированные по общему признаку, надо выделять отдельный enum. А то, что проблемы SWT во многом благодаря старой Java — это да.
Понятия baseline у стандартных виджетов и layout managers нету, но при необходимости можно реализовать такой менеджер. Свойства для baseline в базовом классе Control не предусмотрено, но к каждому контролу можно прилеплять метаинформацию через setData().
Ну т.е. допиливание. А из коробки не может. В итоге каждый плодит свой велосипед. Кстати, мне кажется, что setData для этого не очень хорошо подходит. Тем более, что baseline может много от чего меняться.
3. Не убогие таблицы есть только в Excel :), но там они не являются нативными контролами.
Ну не надо так передёргивать. Я понимаю, что юзера с его хотелками можно только excel'ем порадовать. Но когда отсутствуют базовые простейшие вещи и приходится ради них допиливать — это ужас.
4. Загрузка иконки стандартными методами
ой, как многословно-то…
При помощи самописного класса:
Опять велосипед, опять допиливание. Из коробки не может.
Глобальный обработчик событий клавиатуры можно повесить на Display методом addFilter().
Нет, нужен event bubbling, а не глобальный обработчик. Обработка событий одного контрола или всех сразу — очень неудобный подход. Мой опыт показывает, что лучше всего тут работает паттерн chain of responsibility.
А, еще SWT вроде бы дружит с unity global panel. Но динамические меню там не работают. Хотя это все равно больше, чем может нам предоставить свинг.
А никаких. Взять и застрелиться. И проклинать тех, кто делал SWT и Swing. Или написать свою мегабиблиотеку, без всех недостатков. Но последнее никому не нужно, ибо миллионы индусов уже привыкли писать говнокод и со Swing'ом. А ещё можно писать веб-приложения, где придётся столкнуться либо со всеми прелестями JSF (вторая версия в принципе такое же говно, как и первая), либо со всеми прелестями HTML. Ох, зря я в программисты пошёл…
Ну, если говорить про веб, то, на мой взгляд, писать надо на GWT (internet) или Vaadin (Intranet). есть еще всякие щтуки типа Echo2, но когда я их смотрел, они были не так развиты. и к ним не было плагинов специяльных.
А мне лично свинг более-менее нравится. Особенно в контексте Application Platform.
А мне лично свинг более-менее нравится. Особенно в контексте Application Platform.
Проблема Swing в том, что его писали на базе и для совместимости с AWT. В результате — огромное количество методов, в которых легко потеряться.
Всё верно (ну по мелочам замечания уже сделали выше), только это можно отнести не только к разработке апплетов. В принципе — разницы между апплетами и полноценными приложениями на Java достаточно мало. Скорее есть некоторые нюансы, которые стоит учитывать при написании апплетов. К примеру то, что на все нетривиальные вещи придётся прописывать дополнительные пермиссии апплету и спрашивать «дозволение» у пользователя. Также дополнительная морока с подписыванием jar'ов для апплетов…
Я вот так подписываю :-)
<signjar alias="akvel" jar="${dist_jar}" keystore="myKeyStore1" storepass="123456"/>
Я и не спорю что это дело можно автоматизировать :)
Просто говорю о том, что это дополнительная задача при работе с апплетами.
А если в целом об апплетах — они конечно могут быть использованы в некоторых отдельных случаях, но мне кажется что они себя практически изжили. Их конечно продолжать поддерживать браузеры, как и многие сайты до сих пор поддерживают древний IE6, но это скорее из уважения к немногим пользующимся. Дело даже не в самих апплетах, а в том, что намного проще сейчас написать приложение со схожей функциональностью на html/js, ведь их возможности уже давно перешли за грань «простых скриптиков». Подобное приложение будет работать на порядок быстрее чем апплет и не будет зазря грузить браузер и ресурсы компьютера, а так же не будет иметь проблем со совместимостью с разными платформами.
Возможно единственный более-менее востребованный вариант применения — быстрый перенос своего Swing-приложения в онлайн. Впрочем там есть свои подводные камни…
Просто говорю о том, что это дополнительная задача при работе с апплетами.
А если в целом об апплетах — они конечно могут быть использованы в некоторых отдельных случаях, но мне кажется что они себя практически изжили. Их конечно продолжать поддерживать браузеры, как и многие сайты до сих пор поддерживают древний IE6, но это скорее из уважения к немногим пользующимся. Дело даже не в самих апплетах, а в том, что намного проще сейчас написать приложение со схожей функциональностью на html/js, ведь их возможности уже давно перешли за грань «простых скриптиков». Подобное приложение будет работать на порядок быстрее чем апплет и не будет зазря грузить браузер и ресурсы компьютера, а так же не будет иметь проблем со совместимостью с разными платформами.
Возможно единственный более-менее востребованный вариант применения — быстрый перенос своего Swing-приложения в онлайн. Впрочем там есть свои подводные камни…
В практической жизни апплеты используются в клиент-банковском софте.
Собственно, о чём я и говорил — в некоторых отдельных случаях действительно есть смысл пользоваться апплетами. Да и то, думаю, это больше зависит скорее от предпочитаемых разработчиками технологий, а также от поставленных им задач.
Наскольку я понимаю js плохо подходит для банковского софта изза простоты разбора. Апплет тоже можно декомпилировать и разобрать, но сложнее, ибо платные обфускаторы работают очень сложно и хитро. Круче Java здесь только NaCl, но его умеет только хром. Можно делать плагины, но их надо поддерживать для трех операционных систем минимум, что не просто.
Сомневаюсь что из-за простоты разбора. Если только на этом базируется выбор апплетов — банковские разработчики весьма недалёкие люди.
Да, действительно, некоторые платные обфускаторы (которыми мы тоже пользуемся в своих проектах) и даже бесплатные умеют прилично запутать код, обрезать все названия, слить классы в одну большую кишку и сделать множество прочих пакостей для любителей покопаться в исходниках. Но проблемы это не решает — код по прежнему можно разобрать при должной усидчивости и терпении, коими «серьёзные» взломщики, уверен, обладают. Именно поэтому делать ставку на то, что в обфусцированном коде никто ничего не поймёт и можно воротить всё что нравится — крайне неверно. Поймут, найдут и сломают, если для них из этого будет профит (а может даже и просто из любопытства).
При корректной реализации любых банковских операций и должной защите на серверной стороне, как мне кажется, не важно какой будет клиент. Ну увидят исходники и что дальше? Если лазеек в серверной стороне нет — злоумышленники ничего и не смогут сделать.
Если какие-то взломы и происходят, то скорее по вине пользователей (увели логин/пароль от аккаунта, к примеру). От этого сложно защититься. Впрочем именно для этого и созданы различные подтверждения операций через sms, привязка к IP/машине и прочие средства защиты от постороннего доступа/проведения операций.
Не буду спорить, что многие вещи будет проще/быстрее реализовать в апплете, обладающем практически всеми возможностями полноценного десктоп-приложения на Java. Остальные же преимущества апплетов я считаю весьма необоснованными или, как минимум, спорными.
P.S. Или может я не о тех банковских клиентах думаю?..
Да, действительно, некоторые платные обфускаторы (которыми мы тоже пользуемся в своих проектах) и даже бесплатные умеют прилично запутать код, обрезать все названия, слить классы в одну большую кишку и сделать множество прочих пакостей для любителей покопаться в исходниках. Но проблемы это не решает — код по прежнему можно разобрать при должной усидчивости и терпении, коими «серьёзные» взломщики, уверен, обладают. Именно поэтому делать ставку на то, что в обфусцированном коде никто ничего не поймёт и можно воротить всё что нравится — крайне неверно. Поймут, найдут и сломают, если для них из этого будет профит (а может даже и просто из любопытства).
При корректной реализации любых банковских операций и должной защите на серверной стороне, как мне кажется, не важно какой будет клиент. Ну увидят исходники и что дальше? Если лазеек в серверной стороне нет — злоумышленники ничего и не смогут сделать.
Если какие-то взломы и происходят, то скорее по вине пользователей (увели логин/пароль от аккаунта, к примеру). От этого сложно защититься. Впрочем именно для этого и созданы различные подтверждения операций через sms, привязка к IP/машине и прочие средства защиты от постороннего доступа/проведения операций.
Не буду спорить, что многие вещи будет проще/быстрее реализовать в апплете, обладающем практически всеми возможностями полноценного десктоп-приложения на Java. Остальные же преимущества апплетов я считаю весьма необоснованными или, как минимум, спорными.
P.S. Или может я не о тех банковских клиентах думаю?..
К сожалению, я не знаю, как работает банковский клиент-серверный софт. Но обычно бывает так, что в клиенте после, скажем ввода пароля и использования какого-нить сертификата открывается некоторый путь для общения с сервером. Теперь, после получения этого ключика и сертификата я делаю свое приложение с этими же данными и выкладываю его на гитхаб. И все кто не лень начинают лезть в этот самый сервер и рано или поздно находят дыру — защищенных систем не существует, по крайней мере я в них не верю.
Ну так вот при использовании джаваскрипта достать этот ключик и сертификат куда проще.
Ну так вот при использовании джаваскрипта достать этот ключик и сертификат куда проще.
Полностью защищённых систем может и нет, но достаточный уровень защиты на серверной стороне обеспечить вполне реально (без критических дыр, открывающих доступ ко всему и вся).
В любом случае, я всё веду к тому, что стоит разумно ограничивать себя при защите приложения, а так же разумно подходить к выбору платформы/языка на котором оно пишется, основываясь не только на защищённости клиента от той же декомпилляции. Всегда есть множество вариантов и защиты и взлома приложения — от всего не уберечься.
Впрочем я лично не занимаюсь написанием банковского софта и точно не знаю как у них принимаются подобные решения. Возможно причина вообще не в том, о чём мы думаем…
В любом случае, я всё веду к тому, что стоит разумно ограничивать себя при защите приложения, а так же разумно подходить к выбору платформы/языка на котором оно пишется, основываясь не только на защищённости клиента от той же декомпилляции. Всегда есть множество вариантов и защиты и взлома приложения — от всего не уберечься.
Впрочем я лично не занимаюсь написанием банковского софта и точно не знаю как у них принимаются подобные решения. Возможно причина вообще не в том, о чём мы думаем…
Я вот не пойму зачем до сих пор юзают апплеты, если их можно легко заменить на вебстарт + десктоп-приложение.
Небольшие глюки апплетов можно таким образом обойти. И не мучать браузер.
Небольшие глюки апплетов можно таким образом обойти. И не мучать браузер.
Почему-то никто не упомянул мой любимый MigLayout, который IMHO заруливает все остальные вместе взятые и поддерживает как swing так и swt.
public Component getTableCellEditorComponent(JTable a, Object b, boolean c, int d, int e) { selectedRow = row; selectedColumn = column; setFocusable(false); return this; }
IMHO, компилироваться не будет :-)
Sign up to leave a comment.
Swing. Десять полезных простых вещей