Forms nie tylko dla Oracle

Niemal każdy spotkała się z problemem tworzenia formularzy umożliwiających edycję zawartości bazy danych w prosty i intuicyjny sposób niewielkim nakładem pracy. Często do tego celu wykorzystywane są różnego rodzaju Framework dla aplikacji Web.

Chciałbym zwrócić uwagę na nieco inną możliwość – mianowicie generator formularzy bazujący na silniku baz danych. Koncepcja znana i zdominowana dotychczas przez narzędzie Oracle Forms znalazła swoich zwolenników w świecie Open Source.

W efekcie czego najlepszy projekt relacyjnej bazy danych open source – PostgreSQL doczekał się narzędzia, które raczej przesadnie można nazwać odpowiednikiem Oracle Forms dla PostgreSQL. Mowa tu o projekcie Postgres Forms (http://pgfoundry.org/projects/pfm) powstałym w 2006 roku i od tego czasu rozwijanym, a ostatnio została wypuszczona wersja 2.0.3 o której kilka słów więcej.

Postgres Forms raczej nie przytłacza ogromem funkcji, a interfejs użytkownika raczej nie słyszał o ergonomii, w takim razie po co to? Myślę, iż jest to dobra ciekawostka, i w takim kontekście będę to traktował, choć wydaje mi się, iż znajdzie się i praktyczne, być może i produkcyjne zastosowanie dla tego produktu.

Po zainstalowaniu i uruchomieniu aplikacji za wiele nie zobaczymy:

Za to zobaczymy bardzo dużo… komunikatów błędu przy próbie zaimportowania przykładowego schematu, o ile nie mamy klienta psql w ścieżce plików wykonywalnych, lub wcześniej nie skonfigurujemy aplikacji.

Po zaimportowaniu przykładowego schematu (mamy dwa do wyboru: bazę klientów lub książkę adresową) możemy zacząć wykorzystywać możliwości pfm. Oczywiście możemy stworzyć własny projekt, co sprowadza się do zaimportowania podstawowego schematu w który będą przechowane definicje formularzy, relacji i atrybutów.

Aplikacja pozwala na tworzenie formularzy powiązanych, jak również definiowanie sposobu wprowadzania wartości dla poszczególnych pól, czy to przy wykorzystaniu combobox, czy zewnętrznego formularza wyboru.

Postgres Froms pozwala również na raportowanie wykorzystywanych struktur oraz relacji między nimi:

Małe uzupełnienie w formie rozluźnienia:
http://www.joemonster.org/art/9374/Jak-napisac-dobre-sprawozdanie-z-trudnego-projektu

Na koniec jeszcze kilka zrzutów:

Sposób na polskie ślaczki by Oracle

Dziś miałem do czynienia z dość niespodziewanym, jednak bardzo pozytywnym zachowaniem bazy danych Oracle. Mianowicie w odróżnieniu od pozostałych (większości) baz danych, Oracle w bardzo prosty, a zarazem ciekawy sposób radzi sobie z różnicą kodowania znaków pomiędzy klientem, a serwerem. Większość systemów RDBM w takich sytuacjach dostarcza różnego rodzaju ślaczki, tak Oracle zamienia je na ich odpowiedniki z standardowego zbioru ASCII. Oczywiście pisze tutaj o domyślnym rozwiązaniu konfiguracyjnym nie określającym kodowania znaków, na szczęście zmiana zachowania bazy danych to ustawienie tylko jednej zmiennej, chodź i ta może przyjmować nieco egzotyczne wartości, i tak znane:

  • WIN1250 (CP1250) odpowiada EE8MSWIN1250, czy bardziej pełna wersja POLISH_POLAND.EE8MSWIN1250
  • LATIN2 (ISO-8859-2) - POLISH_POLAND.EE8ISO8859P2

Zmienne te ustawiamy dla PHP poprzez funkcje putenv();

Rozwiązanie to ma jedną moim zdaniem wadę- “ładna” konwersja znaków mniej “rzuca” się w oczy, co utrudnia wykrycie ewentualnych błędów związanych z tą funkcją.