Openoffice- formularze
Tomek
Czy OO ma podobne możliwości jak Access. Czy da się robic podformularze?
Czy wreszcie stworzyć z tego jakąś aplikację a nie tylko osadzić w
dokumencie?
maciek kanski
> Czy OO ma podobne możliwości jak Access.
Tomek
> http://www.inf.sgsp.edu.pl/lab/OOo/OOo_and_DMBS_vs_Access.html
Mi chopdziło o stworzenie aplikacji klienckiej, więc z tego dokumentu
wynika, że nie. Access 2000 jest chyba jedynym narzędziem, za pomoca
którego można szybko stworzyć formularze i ustawić je jako samodzelne
aplikacje.
Jamnik
1. Wszystko zależy od tego, co rozumiesz pod pojęciem "formularze".
2. A tak w ogóle, to o jakim systemie jest mowa? Odnoszę wrażenie, że pytasz
o windows.
Jeśli będziesz zainteresowany aplikacjami pod linuksa, to daj znać, coś się
znajdzie.
--
Wojtek
LFC
Access ma własny format bazy .mdb, w której są tworzone tabele, kwerendy i
formularze, natomiast to, co opisał kolega polega na stworzeniu w
dokumencie tekstowym formularza i poprzez odbc albo jdbc operowanie na
danych z serwera mysql.
W tym sensie można by porównywać w jakiś sposób możliwości OO i Accessa, ale
porównanie jest zdecydowanie na niekorzyść OO.
OO ma własna aplikację bazową Adabas, ale nie pracowałem w tym i nie wiem,
co potrafi.
lFC
maciek kanski
> Access ma własny format bazy .mdb, w której są tworzone tabele, kwerendy i
> porównanie jest zdecydowanie na niekorzyść OO.
potem okazują się takie kwiatki, że migracja jest _faktycznie_ cztery razy
droższa od zakupu kolejnego apgrejdu. Mamy różny punkt widzenia na to co jest
korzystne.
Pozdrawiam
--
http://www.pajacyk.pl - czy już dzisiaj kliknąłeś dla dzieciaków?
LFC
> On Thu, 22 Apr 2004 07:44:32 +0200, LFC wrote:
>> Access ma własny format bazy .mdb, w której są tworzone tabele, kwerendy
>> i W tym sensie można by porównywać w jakiś sposób możliwości OO i
>> Accessa, ale porównanie jest zdecydowanie na niekorzyść OO.
> uzależnianie użytkownika od zamkniętego standardu przechowywania danych...
> i potem okazują się takie kwiatki, że migracja jest _faktycznie_ cztery
> razy droższa od zakupu kolejnego apgrejdu. Mamy różny punkt widzenia na to
> co jest korzystne.
>
Tak, owszem. Ja porównuję podstawowe możliwości i prostotę realizacji
niektórych funkcji - i tu Access bije na głowę OO. Piszę tak, choć jestem
zwolennikiem Linuksa. Nie zajmuję się konwersją do innych standardów.
Porównuję prostą metodę - tworzę złożony formularz w Accesie oparty o
kwerendy z bazy mysql poprzez odbc i mogę w nim wprowadzać dane,
modyfikować, usuwać i jest to z automatu przenoszone na tabele objęte
relacjami. Spróbuj tak samo łatwo to wykonać w OO. Jeżeli sobie radzisz z
tym, szczególnie z polami kombo, to jesteś dla mnie guru i poproszę
receptę...
LFC
Jamnik
> Tak, owszem. Ja porównuję podstawowe możliwości i prostotę realizacji
> niektórych funkcji - i tu Access bije na głowę OO. Piszę tak, choć jestem
> zwolennikiem Linuksa. Nie zajmuję się konwersją do innych standardów.
> Porównuję prostą metodę - tworzę złożony formularz w Accesie oparty o
> kwerendy z bazy mysql poprzez odbc i mogę w nim wprowadzać dane,
> modyfikować, usuwać i jest to z automatu przenoszone na tabele objęte
> relacjami. Spróbuj tak samo łatwo to wykonać w OO. Jeżeli sobie radzisz z
> tym, szczególnie z polami kombo, to jesteś dla mnie guru i poproszę
> receptę...
Tak się nieszczęśliwie(?) składa, że Access jest dołączony do M$Office i
większość porównań, to M$Office - OOo. Ale jeśli już ma być porównanie
pakietów biurowych, to patrząc od strony baz danych lepiej popatrzeć na
KOffice. Powstaje właśnie projekt Kexi
http://www.kexi-project.org/screenshots.html, który wzorowany jest
Accessie. Na razie jeszcze w wersji Beta, więc nie wiadomo ile jeszcze wody
upłynie zanim będzie w pełni funkcjonalny. Jednak nie można powiedzieć, że
w linuksie nie ma nic do baz danych.
Drugi problem, że Access jest "zintegrowanym" serwerem baz i jednocześnie
klientem. Więc teraz powstaje pytanie, czy zarzuty dotyczą linuksowych
serwerów baz, czy ich klientów? Jeśli weźmiemy pod uwagę silniki baz i
porównujesz MySQL i Accessa, to masz rację, Access jest lepszy. Ale jeśli
porównasz go z PostgreSQL, to silnik Accessa wypada blado przy
elastyczności i możliwościach PostgreSQL.
Rozumiem jednak, że Tobie chodzi raczej o klienta do szybkiego tworzenia
formularzy. Widziałeś http://knoda.sourceforge.net/ lub
http://www.rekallrevealed.org/ (jeśli strona byłaby niedostępna, to można
pooglądać na http://www.thekompany.com/products/rekall/)?
W Accessie piszę od wersji 1.0 od 93 r. Po zmianie systemu stwierdziłem, że
jestem bezradny, bo nie znam żadnego ludzkiego języka programowania. Do tej
pory VBA (Access) i VB w zupełności do szczęścia mi wystarczały.
Dwa w/w projekty mają dla mnie jedną wadę - trzeba znać Pythona i płynne
przejście z Accessa jest raczej niemożliwe.
Okazuje się, że nie jest tak źle. Znalazłem Gambasa
http://gambas.sourceforge.net/ i w linuksie poczułem się jak w domu. ;-)
Gambas do szybkiego tworzenia formularzy, PostgreSQL jako silnik bazy.
Owszem, czuję się jakbym przepisywał program z Accessa na VB, ale
przynajmniej mogę to robić z marszu i nie muszę poświęcać czasu na
nauczenie sie nowego języka.
Moim zdaniem największym problemem przy zmianie systemu i klienta baz nie
jest samo narzędzie, ale oduczenie się okienkowego (Accessowego) sposobu
myślenia. Przy bazach SQL większość rzeczy powinna być robiona po stronie
serwera, a klient ma tylko wyświetlać/wprowadzać dane, plus kilka
dodatkowych drobiazgów, których nie da się umieścić po stronie serwera.
I nie zapominać, że to inny system, w którym jest już cała fura gotowych
narzędzi i nikt nie każe mi robić wszystko w jednym. To co mam na myśli
chyba najlepiej odda przykład z ostatnich dni. Program będzie przechowywał
skanowane rysunki techniczne o dość dużych rozmiarach. Przez trzy godziny
męczyłem się jak wyświetlić podgląd rysunku (to akurat nie problem, choć
przy dużych rysunkach Gambas jest strasznie powolny), ale przy okazji
zrobić skalowanie. Z powiększaniem nie mam problemu, ale jak go
pomniejszyć? Po trzech godzinach palnąłem się w swój głupi łeb i
stwierdziłem, że przecież w linuksie nie muszę wykupować dodatkowych
licencji i wystarczy wywołać Kuickshow z parametrem obrazka i niedość, że
się szybciej ładuje, to mam skalowanie, obracanie, jasność, kontrast i
drukowanie w jednym. Wystarczy?
Podsumowując ten przydługi elaborat. Zgodzę się, że w linuksie nie ma tak
wygodnego, zintegrowanego środowiska jakim jest Access. Ale jeśli ktoś
twierdzi, że w linuksie nie da się szybko i wygodnie tworzyć formularzy, bo
nie ma tego OOo, to znaczy, że albo mu się nie chce poszukać narzędzi, albo
lenistwo wychodzi mu już uszami. ;-P
Ale w jednym przyznam Ci 100% racji. Jedyną rzeczą jaką mi brakuje, to
właśnie Accessowa elastyczność ComboBoxa. Przy bardziej skomplikowanym
muszę go dodatkowo oprogramować lub zastępować go dodatkowym okienkiem.
Cała nadzieja w zapowiedzianym nowym QT. :-)
--
Wojtek
e
+ Jamnik wrote:
(...)
> Podsumowując ten przydługi elaborat. Zgodzę się, że w linuksie nie ma
> tak wygodnego, zintegrowanego środowiska jakim jest Access. Ale jeśli
> ktoś twierdzi, że w linuksie nie da się szybko i wygodnie tworzyć
> formularzy, bo nie ma tego OOo, to znaczy, że albo mu się nie chce
> poszukać narzędzi, albo lenistwo wychodzi mu już uszami. ;-P
Hmmm dosyć szybko się takie aplikacje robi w PHP, minusem jest tutaj
konieczność posiadania serwera - ale z drugiej strony to duży plus bo na
kliencie może być cokolwiek, co do tych obrazków i miniaturek to jak dla
mnie żaden problem, po prostu przy wprowadzaniu obrazka do bazy
generowana jest jego miniaturka (w sposób dowolny, np. przez
ImageMagick, gd2 czy cokolwiek innego) i umieszczana wraz z rekordem
obrazka...
> Ale w jednym przyznam Ci 100% racji. Jedyną rzeczą jaką mi brakuje, to
> właśnie Accessowa elastyczność ComboBoxa. Przy bardziej skomplikowanym
> muszę go dodatkowo oprogramować lub zastępować go dodatkowym
> okienkiem. Cała nadzieja w zapowiedzianym nowym QT. :-)
Hmmm ja Accessa to znam tyle co z uczelni czyli prawie nic (w sensie z
praktycznego puntku widzenia to w ogóle) ale nie wiem o co chodzi z tym
comboboxem... Jakiś przykład?
--
www.e.kliper.eu.org/ + . .-. .
linuxweb.linuxindex.pl/ . * ) )
apt.wsisiz.edu.pl/ . . . '-' .
Jamnik
> Hmmm dosyć szybko się takie aplikacje robi w PHP,
Aplikację kliencką można napisać w dowolnym języku, najlepiej w takim, który
się już zna. ;-) Natomiast zarzut był o szybkie tworzenie formularzy, tak
jak w M$ Access, czyli narzędzia typu RAD, więc wymieniłem tylko takie
gotowe narzędzia, nie wspominając o innych sposobach.
> minusem jest tutaj
> konieczność posiadania serwera - ale z drugiej strony to duży plus bo na
> kliencie może być cokolwiek, co do tych obrazków i miniaturek to jak dla
> mnie żaden problem, po prostu przy wprowadzaniu obrazka do bazy
> generowana jest jego miniaturka (w sposób dowolny, np. przez
> ImageMagick, gd2 czy cokolwiek innego) i umieszczana wraz z rekordem
> obrazka...
Akurat z obrazkiem to był tylko przykład, nawet nie dotyczący bazy jako
takiej, tylko samego formularza, który miał pokazać, że niekoniecznie do
wszystkiego muszę używać tych samych narzędzi w których tworzę formularz.
Ty proponujesz inne sposoby, tym samym potwierdzając, że jeśli spojrzeć z
dystansu, to, to co wydawało się trudne, można w bardzo prosty sposób
zrobić, tyle, że inaczej. :-)
>> Ale w jednym przyznam Ci 100% racji. Jedyną rzeczą jaką mi brakuje, to
>> właśnie Accessowa elastyczność ComboBoxa. Przy bardziej skomplikowanym
>> muszę go dodatkowo oprogramować lub zastępować go dodatkowym
>> okienkiem. Cała nadzieja w zapowiedzianym nowym QT. :-)
>
> Hmmm ja Accessa to znam tyle co z uczelni czyli prawie nic (w sensie z
> praktycznego puntku widzenia to w ogóle) ale nie wiem o co chodzi z tym
> comboboxem... Jakiś przykład?
A kojarzysz który to ComboBox? Na wszelki zaś gdybyś nieskojarzył nazwy. To
takie pole tekstowe zintegrowane z listą wyboru. Jak klikniesz w przycisk,
otwiera się lista i wskazujesz interesującą Cię pozycję, która po wybraniu
wpisywana jest do tego pola tekstowego. Tak mniej więcej. :-)
Na sposób accessa:
W projekcie formularza wstawiasz ComboBoxa i w jego właściwościach
ustawiasz:
1.Szerokość na ekranie = 200 pikseli (jednostka dla uproszczenia, bo w
Accessie ustawiasz w cm)
2. Jako źródło listy wpisujesz zapytanie sql, które zwróci np. 4 pola z bazy
3. Szerokość otwartej listy = 800 pikseli
4. Podajesz szerokości poszczególnych kolumn listy (z tym, że pierwsza
kolumna = 0)
5. Definiujesz, że ComboBox ma zwracać wartość z pierwszej kolumny
Otwierasz formularz do pracy. Widzisz ComboBoxa szerokości 200 pikseli.
Klikasz w przycisk i otwiera Ci się lista 4 razy szersza od samego
ComboBoxa. Na liście widzisz 3 osobne kolumny różnej szerokości: imię i
nazwisko, zawód, adres zamieszkania. Odszukujesz swoje dane na liście
(były wcześniej wprowadzone do bazy) i je wybierasz. Lista się zamyka, a do
pola tekstowego przenoszone jest Twoje imię i nazwisko, jednak do tabeli,
którą obsługuje ten formularz zostanie zapisany numer rekordu (to ta
pierwsza, ukryta kolumna) z Twoimi danymi a nie imię i nazwisko.
Teraz spróbuj zrobić to samo w linuksie nie pisząc ani jednej linijki kodu.
Jeśli na formularzu jest miejsce, to zamiast ComboBoxa wystarczy wstawić
ColumnView i funkcjonalnie jest to samo. Ale jeśli formularz jest już tak
upchany, że nie ma gdzie tego wcisnąć, to na razie rezygnuję z ComboBoxa i
otwieram dodatkowe okno z ColumnView, jednak jest to już dodatkowa robota.
Oczywiście nie dotyczy to, gdy jest tylko jedna kolumna informacji i wartość
wskazana ma być zapisana do bazy.
I jeszcze jedno. Gambas na razie pracuje tylko z QT więc nie wiem jak to
wygląda np. w GTK lub innych. Może ichniejsze widgety mają większe
możliwości. Jeśli tak, to przepraszam za zamieszanie. Jak widać bliższa
ciału koszula, czyli wcale nie jestem lepszy od innych. ;-)
--
Wojtek