Siemka.
Piszę aplikację okienkową i chcę uzyskać następujący layout:
w oknie głównym mają być trzy panele, na których sobie umieszczę inne komponenty. Panele mają być jeden pod drugim (sugeruje GridLayout), ale chcę aby pierwszy i ostatni panel (nagłówek i stopka) miały ustaloną wysokość, a środkowy aby się dopasowywał do wielkości okna.
Pozdrawiam i dzięki za odpowiedź.
BorderLayout + własne komponenty. Można wtedy nadawać im wielkości i nie ma obawy, że coś się obsunie.
Koziołek napisał(a)
BorderLayout + własne komponenty.
Co masz na myśli mówiąc własne komponenty?
Masz na przykład trzy panele. Niech każdy z nich będzie osobną i nie zależną od innych klasą zawierająca poszczególne elementy, czyli właśnie "własnym komponentem" graficznym. Termin trochę nie fortunny, ale zapatrzyłem się na "Dephinów". Napisałem o tym, bo częstym błędem jest próba umieszczenia wszytkich elementów na siłę w jednej klasie.
Aha, spoko :) Właśnie tak robię. Dwa z tych paneli zawierają kilka przycisków, a trzeci będzie dość skomplikowany, więc już stworzyłem dla niego osobną klasę. Pytałem dlatego, że jestem na etapie Inżynierii Programowania i jak widzę słowo "komponent" to od razu mi się nasuwa "component design model" :P
Pozdrówka!
A może by tak null:
setLayout(null)
Wówczas każdemu komponentowi nadajesz współrzędne oraz rozmiar
setBounds(x, y, width, height)
@jacobus2k, za takie coś na jdn.pl chcieli mnie żywcem spalić.
setLayout(null) to zło!
Powodem jest to co napisałeś poniżej. Musisz ręcznie dbać o rozłożenie elementów. Niestety powoduje to potworne problemu przy zmianie rozmiarów okna.
@baterman, wbrew pozorom oba pojęcia mają dość dużo wspólnych cech. Nie jest to może tak widoczne na pierwszy rzut oka, ale poczytaj o wstrzykiwaniu zależności (Dependencies injection). Objawi ci się wtedy nowe podejście do tworzenia aplikacji "zorientowanych na komponenty". Zresztą na aplikacjach okienkowych najfajniej to widać.
Można zawsze zrobić odpowiedniego ComponentListener'a. Generalnie świetnie się nadaje do okien o niezmienialnych rozmiarach lub stałym układzie komponentów.
jacobus2k:
null layout'u wolę uniknąć właśnie z tego powodu, o którym pisał Koziołek. W sumie właśnie po to zrobiono w Javie layouty, aby nie bawić się w ręczne ustawianie komponentów i trzeba nauczyć się z tego dobra korzystać :)
Koziołek:
znam dość dobrze wstrzykiwanie zależności (kontener IoC w Spring'u), ale ta aplikacja nie potrzebuje zmiany używanych komponentów. Tak na dobrą sprawę to GUI jest tu drugorzędne, a cały projekt dotyczy certyfikacji metodą RSA
pozdro!
Mówiąc o IoC miałem na myśli raczej sposób zarządzania poszczególnymi cegiełkami. Zresztą jeżeli GUI jest sprawą drugorzędną to można i na sztywno wszytko pozaszywać.
Koziołek:
a masz może jakieś przykłady używania IoC w aplikacjach GUI? Bo szczerze Ci powiem, że nigdy się nad tym nie zastanawiałem, a może to być ciekawe :D
Ech.... w końcu mnie mają. Przykład w bólach tworzy się na potrzeby warszawskiego juga.
Aplikacje GUI to nie tylko okienka, ale też cała masa innych elementów. Załóżmy, że mamy prostą aplikację do obsługi domowej biblioteki. Aplikacja jest napisana według zaleceń mvc. Jako bazy danych używamy HSQLDB, jednak po pewnym czasie chcemy wymienić bazę na JavaDB + Hibernate. Jak widać wystarczy trzeba na nowo klasy DAO. Jeżeli teraz mamy mechanizm podobny do springowego wstrzykiwania zależność to wdrożenie nowych implementacji ograniczy się do zmian w pliku xml.
Wymiana elementów GUI może przebiegać w podobny sposób. Dzięki mechanizmowi wstrzykiwania zależności można wymieniać poszczególne elementy ekranów. Można też, i to jest chyba najlepszy przykład, wymieniać Listynery dla poszczególnych komponentów. Jeżeli chcemy zmienić zachowanie jakiegoś np. przycisku to wystarczy podmienić tylko klasę Listynera w pliku konfiguracyjnym bez konieczności grzebania w kodzie klas. Oczywiście nie można wtedy ustawiać zachowań jako klas anonimowych lub prywatnych, ale to nała cena za swobodę konfiguracji.
OK, to wydaje się być logicznym. Ale czy to na prawdę przynosi tak dobre rezultaty? Mam na myśli to, że raczej rzadko kiedy zmienia się zachowanie poszczególnych komponentów (to à propos Listenerów), aby nie wkurzać końcowego użytkownika. Zmienianie DAO to faktycznie super zaleta, ale dotyczy bardziej warstwy modelu wspomnianego przez Ciebie MVC. Myśląc trochę nad tym wszystkim wpadłem na lepszy pomysł - pluginy. Tutaj IoC sprawdzi się chyba znakomicie. Wystarczy dociągnąć nowe klasy i jeden plik *.xml i wszystko gra! :) Brak rekompilacji kodu!
Hm... pluginy to nie najlepszy pomysł tak "sam w sobie" jeżeli będzie dużo pluginów to zacznie się wszytko mulić. Taki problem był ze starszymi wersjami Eclipsa. Obecnie popularność zyskuje OSGi, czyli takie magiczne cudo do zarządzania "bundlami". Pozwala na częściowe załadowanie klas. ograniczając się tylko do tych niezbędnych. Najciekawsze jest to, że OSGi pozwala mieć w jednej aplikacji dwa jary różniące się tylko wersją, ale pracujące w tej samej przestrzeni nazw. Co zaś tyczy się wymiany listenerów to można dodawać funkcjonalności "w tle" takie jak sprawdzanie ergonomii czy statystyki kliknięć. Użyszkodnik nie zauważy różnicy, a programista dostanie informacje konieczne przy planowaniu układu gui. Inne zastosowanie to wdrażanie poprawek do już istniejących funkcjonalności.
To troszeczkę odbiegliśmy od tematu ;-) No ale może się komuś ta dyskusja wyda przydatną! Jeśli o mnie chodzi to poświęcę trochę czasu na głębsze analizowanie funkcjonalności IoC i technologii OSGi!
Dzięki i pozdro! :)
Btw. Co do mojego początkowego pytania - BorderLayout działa jak marzenie :)