Jestem zagorzałym przeciwnikiem designerów. Ale możliwe, że nie mam racji. Wczoraj zabawiałem się warcabami. Kod wyświetlający poniższe okno napisałem w 20 minut (w notepad++, musiałem więc dopisać wymagane importy). Plik źródłowy ma 1300 bajtów i po pominięciu pustych wierszy i wierszy z jedną klamerką ma 29 wierszy. Czy mógłby ktoś wyklikać podobne okno oraz porównać czas pracy i rozmiar pliku?
Nie mam zbyt dużego doświadczenia w Javie, ale jeśli o mnie chodzi to staram się pisać ręcznie. Jeśli nie wiem jak coś zrobić wspomagam się designerem, sprawdzam jaki kod wygenerował i próbuję to przepisać po swojemu ;)
Przede wszystkim przykład jest "specyficzny".
Idealnie pasuje na pisanie z ręki, ponieważ jest schematyczny i powtarzający się.
W takim wypadku wydawałoby się, że builder się nie nadaje a jednak...
Niestety albo stety musiałem to rozbić na klasy bo inaczej bym się zaklikał :)
Stworzyłem sobie 5 klas(klasa dziedzicząca po JLabel(16 niepustych linijek), klasa z rzędem zaczynającym się od białego pola(40 linijek), analogicznie od czarnego(40), klasa główny panel(61) oraz klasa z metodą main(11)).
Łącznie żródła zajmują ok. 27kB(najwięcej formy generowane przez NetBeansy).
Zrobiłem przykład w ok. 10 min.
Plusem buildera jest to, że panel można podejrzeć bez odpalenia aplikacji.
Przykład faktycznie jest specyficzny, dlatego że tło formularza jest bardzo proste i powtarzalne; Gdybym sam musiał stworzyć takie okienko, to albo położyłbym komponent na formularz i go oprogramował, albo malował bezpośrednio na kanwie okna; Najgorszym rozwiązaniem było by użycie 8x8 komponentów - najwięcej klikania i bawienia się z rysowaniem dwóch kolorów, choć i to można bardzo łatwo skrócić do minimum;
Ja nie znam się na Javie, jednak designery istnieją do wielu języków, także do tego w którym pracuję; Jeśli tworzę jakikolwiek program okienkowy, w którym formularze posiadają różnie porozrzucane komponenty, to nie wyobrażam sobie tworzenia komponentów ręcznie (implementując wszystko w kodzie); Z drugiej strony, jeśli elementy powtarzają się, układając w jakąś logiczną całość, to w takim przypadku można posłużyć się wyłącznie kodem;
Przede wszystkim trzeba zwrócić uwagę na to, że wszelkie edytory formularzy mają nas zwolnić z pisania kodu, na rzecz poklikania, à la WYSIWYG; Mocno upraszcza to pracę, bo nie trzeba kompilować kodu i uruchamiać aplikacji, aby zobaczyć jak będą wyglądały okna; No i dochodzi też to, że w kodzie można się walnąć, a przy złym ustawieniu komponentów czy formularza, wszystko widać od razu;
Ja od zawsze byłem fanem designerów, ale staram się z nich korzystać tak, aby nie dokładać sobie roboty; Jeśli wyklikanie ma mi pójść szybciej, to sobie klikam po formularzu i w OI, a jeśli nie - piszę kod.
@garai, czasowo wygrałeś, za to kodu masz dużo więcej i chyba nie nadaje się on do dalszej rozbudowy. Ja mam 64 pola typu JButton, dodanie do planszy pionków to kilka wierszy jeśli pionki narysuje w jakimś gimpie, 0koło 40 wierszy jeśli pionki rysuję w kodzie Javy (klasa dziedzicząca po klasie Icon i metoda setIcon przycisków). Ponieważ są 64 komponenty, to łatwo się rozpoznaje w co kliknął użytkownik.
@furious programming
bo nie trzeba kompilować kodu i uruchamiać aplikacji, aby zobaczyć jak będą wyglądały okna;
chyba nie pracowałeś z żadnym IDE do Javy. Tam się nie kompiluje - zapisanie pliku jest równoznaczne ze skompilowaniem. W programie jak wyżej, zajmuje to ułamek sekundy.
chyba nie pracowałeś z żadnym IDE do Javy.
Zgadza się i o tym nie wiedziałem; Jednak nie zmienia to faktu, że w przypadku normalnych aplikacji okienkowych, z reguły komponenty nie są układane w logiczną całość, a są w różnych miejscach i o różnych rozmiarach, więc o wiele szybciej i wygodniej jest sobie interfejs wyklikać;
Ja osobiście mam takie zdanie, że designer ma skrócić czas projektowania formularzy, jednak przy dużej ilości komponentów, które są powtarzalne i identyczne (lub dzielone na grupy), napisanie kodu jest szybsze i wygodniejsze; W zależności od formularza i jego zawartości, trzeba sobie wybrać odpowiedni sposób.
za to kodu masz dużo więcej
Nie bój się kodu :)
chyba nie nadaje się on do dalszej rozbudowy
Kod jest taki sam jak Ty masz. Zwykłe GUI.
W programie jak wyżej, zajmuje to ułamek sekundy.
Zgadza się, ale nie każdy program jest tak trywialny. Wyobraź sobie aplikację, która np. wstaje ok 1 min. Strata czasu, aby sprawdzać za każdym razem zmianę układu komponentów
Ja osobiście mam takie zdanie, że designer ma skrócić czas projektowania formularzy, jednak przy dużej ilości komponentów, które są powtarzalne i identyczne (lub dzielone na grupy), napisanie kodu jest szybsze i wygodniejsze; W zależności od formularza i jego zawartości, trzeba sobie wybrać odpowiedni sposób.
Zgadzam się od początku do końca.
a teraz weź jakiekolwiek okienko aplikacji typowo biznesowej - edycja kontrahenta. W zależności od ilości danych możesz mieć na jednym widoku i kilkadziesiąt RÓŻNYCH kontrolek. Słowo różnych (różne typy/rozmiary) jest tu słowem kluczem. Do tego dochodzi grupowanie "podobnych logicznie" elementów np. w groupboxach. W IDE widzisz efekt od razu, możesz wklepać przykładowe dane do kontrolki aby zobaczyć czy taki rozmiar wystarczy, poklikać sobie w ustawienia koloru/czcionki żeby było "pięknie".
To jest idealny przykład na robienie formy w kodzie ("dolna granica").
Prawie każdy inny przykład będzie pokazywał że projektowanie formy w kodzie jest nieefektywne.
Tu inne przykłady (też kontrolki w kodzie):
http://www.java-gaming.org/index.php?topic=15399.0
Tworzyłem dość złożone GUI w Delphi - po kilka zakładek, na każdej po kilka grup kontrolek. Czasami wizualnie jest problem żeby to wszystko ogarnąć. W wersji code-only w ogóle sobie tego nie mogę wyobrazić.
Jeśli masz do czynienia z ekranami typu Tcl/Tk, Mathplotlib to można robić w kodzie. Przy bardziej złożonych ekranach powstaje tyle zależności że w kodzie to jest nie do ogarnięcia (także w Javie).
Dlatego do Javy używam Netbeans - jedyny sensowny designer GUI.
Ale już do WWW mam bardziej podejście nie-wizualne.
Chociaż warto zrobić czasami wygląd HTML-owy wizualnie a potem ew. to oczyścić z wszelkiego nadmiaru.
chodzi wam o komponenty, robienie GUI? To w czym problem wstawiać buttony i inne rzeczy ręcznie? Wygodne to, efekt widać od razu bez odpalania programu, nie trzeba się bawić, oszczędza to czas. Równie dobrze możecie pisać w Assemblerze programy, ale po co skoro w c++ lub w javie i w innych językach jest łatwiej i szybciej i wiedzy takiej nie trzeba? Świat się rozwija, to, że coś teraz można zrobić szybciej i prościej, nie oznacza, że to jest gorsze. Sporo gier w Unreal Engine i w Unity powstało i powstaje, bo te silniki gier mają gotową fizykę, wiele rzeczy można wyklikać, modele 2d lub 3d drag & dropować, edytor terenu też jest. Oszczędza to czas ludziom, nie trzeba pisać specjalnie silnika do gry swojego, bo gotowe rozwiązania są dość profesjonalne i sprawdzają się dobrze.
Zresztą nie samym wyglądem program lub gra żyją. Co z tego, że ktoś wyklika GUI programu lub wyklika teren w Unity i przeciągnie modele 3d skoro taki program i gra są bezużyteczne bez oprogramowania tego. Button musi coś robić, podobnie jak model 3d w grze. Nadal programista pozostaje programistą i nadal ma masę roboty do zrobienia.
Ciekawe jak za 200 lat będzie wyglądało programowanie.
I ciekawe, czy za tysiąc lat w końcu będzie prawdziwa sztuczna inteligencja, wtedy to SI mogłaby pisać programy dla ludzi, ale na razie trudno mi sobie wyobrazić by SI ogarnęła pisanie programów i gier skoro bajecznie bogaty Google nie potrafi zrobić rozpoznawania mowy na youtube i w większości filmików w każdym zdaniu są błędy. Ten sam Google nie potrafi napisać lepszego Google Translate. Dlatego nie spodziewam się prędko prawdziwej sztucznej inteligencji, bo ta potrafiłaby mi przetłumaczyć tekst angielski na polski równie dobrze co zawodowi tłumacze i tego tłumaczenia zwykłego tekstu prędko się nie doczekamy.
Wizzie napisał(a):
Dlatego do Javy używam Netbeans - jedyny sensowny designer GUI.
Jak na tym tle wypada JavaFX Scene Builder?
Nie wiem, nie pracowałem z Java FX. Dotychczas mało spotykałem aplikacji biznesowych w tym środowisku, ale niedawno widziałem całkiem ładną i chyba się przekonam.
W tym specyficznym przypadku pewnie bym tez rysowal recznie po canvasie albo jakims paintboxie, ale generalnie preferuje przeklikiwanie od pisania. Zalezy co szybciej sie robi. Jakbym mial ustawiac przyciski i labele jakiegos formularza to recznie (piszac kod) by mi sie nie chcialo. Jak powtarzalny schemat to raczej pisalbym kod.
http://www.formdev.com/ a JFromDesigner dla Intellij IDEA?
Od NetBeans to juz wole eclipse...
Java 
