Thursday, December 27, 2007

Jaki domyślnie jest kolor tła textFielda?

Problem jest taki:
Użyszkodnik wpisał coś do w textfielda i wpisał coś co się nie parsuje. Można mu jakiegoś popupa wyśwletlić, ale ja na przykład nie lubie popupów. Moje domyślne rozwiązanie jest takie że kiedy w polu jest coś bezsensu to jego tło staje się czerowne. Kiedy jest coś OK to tło wraca do domyślnej wartości. Tylko jaka jest ta domyslna wartość?

W zasadzie biały. Ale ja pare lat temu miałem ustawiony domyślny kolor tła na jasnoszary.

Na szczęście panowie z Suna pomyśleli (oni często myślą co wychodzi programistom javy na zdrowie) i zrobili coś takiego jak:
UIManager.getDefaults().

Czyli zwykłą Haszmapę<Object, Object> która zawiera wszystkie domyślne wartości wszystkiego.

Tylko jak sie do tego dobrać? Bo zgadywać klucz jakoś głupio...

Pierwsze podejście:
public class UIDefaultsPrint {
private static final java.util.logging.Logger log =
jbzdak.common.StuffFactory.make();

public static void main(String[] args) throws IOException {
Frame fr =new JFrame();
fr.add(new JTextField());
fr.setVisible(true);
UIDefaults defaults = UIManager.getDefaults();
File f = new File(".", "defaults.values");
BufferedWriter buffwr = new BufferedWriter(new FileWriter(f));
for(Map.Entry entry : defaults.entrySet()){
System.out.println(entry.getKey() + " " + entry.getValue());
buffwr.append("" + entry.getKey() + " " + entry.getValue() + "\n");
}
buffwr.close();
fr.dispose();

}
}


Nie zadziałało bo jakoś te defaulty są inicjalizowane leniwie, nie wiadomo kiedy.

Drugie podejście:
Google wypluły mi strone: http://dn.codegear.com/article/29991. No i tam jest program co pozwala to sobie łatwo te wartości znaleźć.
PS. Piszą tam że tzreba się za darmo zarejestrować żeby pobrać, ale zabezpieczenie działa na javaskrypcie (wyłączony) albo na jakimś Windzianym haku.

Friday, September 14, 2007

Baza danych.

Baza danych w programie i metody nią zarządzające służą tylko do dostępu do danych. Tylko i wyłącznie.

Nie powinno się w tych częściach aplikacji implementować czegokolwiek innego, w szczególności złymi pomysłami jest wrzucanie tam jakiejkolwiek logiki biznesowej, bezpieczeństwa, czy weryfikacji poprawności danych. Te rzeczy mają miejsce o poziom wyżej.

Pomysł podawania metodzie odczytującej z bazy danych danych użytkownika by ta sobie sama sprawdziła jego przywileje, wydaje sie sensowny.... do momentu w którym chcesz te dane przeczytać w miejscu w którym nie ma użytkownika. Np. podczas nocnej weryfikacji danych z bazy.

Pomysł tego żeby logika biznesowa była w bazie danych też jest poroniony. Jeśli twoja metoda robi coś więcej niż 'zwraca wszystkie dane spełniające dane kryterium', 'zwraca dane o unikalnym id', robi już zbyt dużo. To podejście jest złe na przykład dlatego że zmiany w logice biznesowej wprowadzane na bazę danych są widoczne od razu w całym systemie (i jak developer coś spieprzy, to aplikacja padnie u wszystkich podpiętych do tej bazy).

Pomysł na to żeby dostęp do bazy danych sprawdzał ich poprawność jest fajny jak się o nim myśli. Tylko co baza ma zrobić jak wykryje ową niepoprawność? Rzygnąć wyjątkiem, ot co. Ale kto ten wyjątek złapie? Właśnie często nikt --- czyli złapie go użytkownik.

W jednym projekcie ktoś wpadł na zajebisty pomysł wykonania takiego selecta:
SELECT * FROM umowa WHERE umowaId = id AND cośtam = id2

Dodam że umowaId była już unikalna. AND powodował że jeśli kontrahent był nie ustawiony select zwracał pusty set, a metoda rzygała wyjątkiem. Kiedy pani sbie skasowała kontrahenta wiodącego z umowy, potem oglądała piękny ekran o błędzie. Gdyby nie było tej weryfikacji, pani mogła by sobie tą umowę poprawić ręcznie. A tak musieli to robić developerzy na bazie danych...