[janosik-devel] koncepcje

[Marek Pętlicki]

Za³±czam wstêpn± wersjê swoich koncepcji. Wstêpn±, bo obawaij±c siê
sprzeciwów wolê nie rozwijaæ tego bardziej :-)

W tej chwili ju¿ zmieni³bym na przyk³ad rozdzia³ o strukturze danych
(n.p. wy³±czy³bym ustawienia do osobnego obiektu).

Jak wspomina³em - chcia³bym, ¿eby te pomys³y wywo³a³y burzê mózgów. W
¿adnym wypadku nie traktujê tych zapisków jako swojego ostatniego s³owa
;-)

pozdrawiam

-- 
Marek Pêtlicki <marpet at linuxpl.org>
Linux User ID=162988


-- Attached file included as plaintext by Listar --

Moja koncepcja struktury wewnêtrznej Janosika
Marek Pêtlicki <marpet at linuxpl.org>
2002-01-10


Stara³em siê byæ w miare zgodny z plikami spec.txt i specyfikacja.txt, w
ramach rozs±dku oczywi¶cie :->


W tym dokumencie zaproponujê strukturê katalogów bibliotecznych i wstêpny
pomys³ obs³ugi wewnêtrznego przechowywania danych. Wraz ze struktur± katalogów
zaproponujê te¿ zarys logiki aplikacji zwanej Janosikiem.

1. STRUKTURA BIBLIOTEK

Wstêpne za³o¿enia okre¶laj±, ¿e program powinien byæ niezale¿ny:

  a. od platformy systemowej;
  b. od obecnych przepisów;
  c. od wszelkich interfejsów, jak baza danych, GUI, podsystem drukowania itp.

z tego wynika, ¿e program mo¿e byæ zale¿ny w³a¶ciwie tylko od jêzyka
programowania w jakim zostanie napisany :-)

Zastosowanie Pythona i budowy modu³owej (lub zastosowanie wtyczek, jak kto
woli) pozwoli nam uwolniæ siê nawet od tego ostatniego uzale¿nienia ;-)

Moja propozycja polega na takim u³o¿eniu bibliotek, ¿eby w³aczenie wtyczki do
Janosika równa³o siê wykonaniu instrukcji "import" z odpowiedni± nazw± modu³u.
Dziêki temu mo¿emy zastosowaæ pe³ne szykany tworzenia modu³ów Pythona z
modu³ami typu 'extension' w postaci bibliotek dynamicznych (*.so, *.dll itp)
bez jakiejkolwiek dodatkowej komplikacji w ich wykorzystaniu.

Jak pisa³em gdzie¶ indziej moim marzeniem jest uczynienie z Janosika programu
jak najbardziej elastycznego. Dlatego podsystem 'ZUS' powinien byæ w nim jedynie
jedn± w wtyczek, struktura programu nie ma prawa w najmniejszym stopniu
uzale¿niaæ siê od specyfiki wymaganej przez to konkretne zadanie.

Dlatego proponujê, aby Janosik jako program by³ zaledwie kodem spajaj±cym w
jedn± ca³o¶æ wtyczki o ró¿nym przeznaczeniu, które dopiero spojone beda dawaæ
pe³na funkcjonalno¶æ programu. Wola u¿ytkownika a tak¿e inwencja twórców
modu³ów/wtyczek bêd± jedynym wyznacznikiem funkcjonalno¶ci programu.

1.1. wtyczki

Wstêpnie wyodrêbni³em nastêpuj±ce typy wtyczek:

 - GUI
 - printing
 - database
 - subsys

s± to typy wtyczek obs³ugiwane przez g³ówny program (janosik).

Na uwagê zas³uguje tutaj wtyczka typu subsys: jest to najbardziej rozbudowany
rodzaj wtyczki. Wtyczki podsystemów bêd± definiowaæ funkcjonalno¶c programu
specjalizowan± pod k±tem konkretnego problemu. W dalszej czê¶ci wtyczki te
bêdê nazywaæ podsystemami.

W nomenklaturze Pythona podsystemy bêd± zbudowane jako pakiety modu³ów
('module packages'), czyli jako hierarchie modu³ów z podmodu³ami.

Nasz przyk³adowy podsystem mo¿e nosiæ nazwê "ZUS".

Pozosta³e wtyczki bêd± spe³niaæ odpowiednie role w zalezno¶ci od nazwy.

Zauwa¿my, ¿e w systemie u¿ytkownika (w instalatorze?) mo¿e wystêpowaæ po kilka
wtyczek ka¿dego rodzaju: bêd± one stanowiæ alternatywê dla u¿ytkownika do
wyboru na etapie instalacji (w zale¿no¶ci od konfiguracji systemu) lub potem w
trakcie u¿ytkowania w zalezno¶ci jednak od mo¿liwo¶ci (n.p. zmiana motoru GUI 
w trakcie pracy nie powinna nastrêczaæ jakichkolwiek problemów, natomiast
zmiana motoru przechowywania danych bêdzie wi±zaæ siê z konieczno¶ci±
dokonania importu do nowego mechanizmu wszelkich zasobów zgromadzonych do tej
pory w starym).

Oczywi¶cie mo¿na/nale¿y uzupe³niæ jeszcze powy¿sz± listê modu³ów podstawowych o
modu³y uwierzytelniania/dostêpu wielou¿ytkownikowego z kontrol± zasobów itp.

1.2. podsystemy

Ka¿dy podsystem bedzie wyspecjalizowany pod k±tem obs³ugi konkretnych typów
dokumentów. Musi jednak realizowaæ pewien podstawowy interfejs celem
komunikacji z pozosta³ymi elementami systemu:

 - import
 - export
 - processing
 - GUI
 - printing
 - ...

te dwa ostatnie elementy mia³yby s³u¿yæ w charakterze uzupe³nienia w stosunku
do g³ównych wtyczek i byæ zupe³nie opcjonalnymi elementami. Ich u¿yteczno¶æ
mo¿e polegaæ na przes³oniêciu domy¶lnej funkcjonalno¶ci systemu przez
specyficzn±, wymagan± w danym podsystemie.

Interfejs przetwarzania mia³by zawieraæ procedury przeliczaj±ce, wstêpnie
wype³niaj±ce pola formularza. Jest to interfejs wykorzystywany wewnêtrznie
przez program (bez ingerencji u¿ytkownika) lub te¿ na ¿yczenie u¿ytkownika
(celem ponownego przeliczenia warto¶ci).

Dokumenty mog± posiadaæ równie¿ mechanizmy specyficzne dla siebie, które nie
powinny za¶miecaæ g³ównego modu³u przetwarzania. Do tego celu tworzymy
podmodu³ o odpowiedniej nazwie w module processing:

subsys.ZUS.processing.RSA

1.3. Przyk³ady

za³ó¿my, ¿e u¿ytkownik zechce zaimportowaæ do systemu plik ZUS-12.xml
(utworzony w innym programie) a nastepnie wyeksportowaæ te dane do formatu
KEDU.

janosik --nogui --module=ZUS --new-collection="ZUS-12" --import=ZUS-12.xml \
	--import-engine=xml 

janosik --nogui --module=ZUS --collection="ZUS-12" --export-engine=KEDU \
	--export=ZUS-12.kdu

Jak to bedzie wygl±daæ w programie:

 a. otworzy podsystem ZUS
 b. utworzy now± kolekcjê dokumentów pod nazw± "ZUS-12"
 c. zaimportuje do nowo utworzonej kolekcji dane zawarte w pliku ZUS-12.xml z
    wykorzystaniem mechanizmu importu zawartego w module o nazwie xml (czyli
    subsys.ZUS.import.xml)

a nastêpnie:

 d. zapisze dane zawarte w kolekcji dokumentów "ZUS-12" do pliku ZUS-12.kdu
    za pomoc± mechanizmu eksportu ZUS.export.KEDU


Je¶li jednak plik wej¶ciowy zawiera tylko dane pojedyñczego dokumentu który
nale¿y w³±czyæ do istniej±cej kolekcji:

janosik --nogui --module=ZUS --doctype=DRA --open-collection="ZUS-12" \
	--import=ZUS-DRA-Kowalski-12.xml --import-engine=xml

z tym, ¿e w tym przypadku powinien zostaæ u¿yty mechanizm z modu³u
ZUS.import.xml.DRA

Mo¿na oczywi¶cie przewidzeæ sytuacjê, w której ca³o¶æ logiki importu mie¶ci siê
w g³ównym module podsystemu, wtedy wystarczy:

janosik --nogui --module=ZUS --open-collection="ZUS-12" \
	--import=ZUS-DRA-Kowalski-12.xml --import-engine=xml

co oczywi¶cie wywo³a procedury importu z ZUS.import.xml (który mo¿e równie¿
niejawnie skorzystaæ ze swojego podmodu³u DRA)


2. STRUKTURA DOKUMENTÓW

Jeden z postulatów zak³ada niezale¿no¶æ Janosika od systemu przechowywania
danych.

Proponujê od razu odej¶æ od koncepcji wewnêtrznego przechowywania danych w
formacie KEDU: jest on b³êdny z za³o¿enia, niezgodny z czymkolwiek (pola o
za³o¿onej d³ugo¶ci wewn±trz struktury SGML) i ma³o elastyczny. Pliki w
formacie _zgodnym z P³atnikiem_ (oraz przede wszystkim z P³atnikiem PE) bêdzie
mo¿na ³atwo uzyskaæ poprzez eksport danych.

Niestety taki krok zmusza nas do wymy¶lenia w³asnego, lepszego standardu ;-)

Nie bêdê wnikaæ w zawi³o¶ci mechanizmów baz danych itp. problemy. Chcê
zaproponowaæ jednak pewn± hierarchiê dokumentów, która mo¿e znale¼æ
zastosowanie w Janosiku.

Uwaga na wstêpie: hierarchia opisana tutaj odnosi siê do wewnêtrznych struktur
Janosika (drzewa obiektów) nie za¶ do fizycznego umieszczenia plików na dysku
czy jakiejkolwiek innej formy hierarchizacji danych. Oczywiste jest jednak, ¿e
dla zapewnienia wygody u¿ytkowania fizyczna struktura danych na dysku powinna
u³atwiaæ korzystanie z tych danych a w szczególno¶ci wczytywanie ich do
wewnêtrznych struktur programu.

Jak pisa³em powy¿ej obs³ug± przechowywania danych bêdzie zajmowaæ siê
odpowiednia wtyczka. Dane wczytane do programu przez wtyczkê musz± zostaæ
u³o¿one w odpowiednie struktury i to w³a¶nie chcê tutaj opisaæ.

2.1 hierarchia danych:

database.settings - ustawienia g³ówne programu
            FIXME: s± tacy, którzy sprzeciwiaj± siê takiemu podej¶ciu i mo¿e
	    s³usznie :-) W ka¿dym razie dobrze by³oby, gdyby konfoguracja
	    programu by³a dostêpna w jawny sposób, dlaczego wiêc nie w postaci
	    obiektu wczytywanego na starcie programu i dostêpnego w
	    odpowiedniej przestrzeni nazw.

database.users - dane dotycz±ce podmiotów których dotycz± dokumenty obrabiane w
         Janosiku 
	 FIXME: nazwa
	 FIXME: byæ mo¿e warto tutaj tez przewidzieæ grupy u¿ytkowników
	 (wirtualne) podobnie jak wspomniane dalej metadokumenty.

database.subsystem[SUBSYS_NAME] - dane obs³ugiwane przez konkretny podsystem:
database.subsystem[SUBSYS_NAME].settings - ustawienia specyficzne dla
                                           podsystemu - patrz wy¿ej;
database.subsystem[SUBSYS_NAME].user_data[USER_ID] - dane wybranego podmiotu w
                                                     ramach podsystemu;

System odwo³uje siê do swoich danych poprzez odpowiednie odwzorowania.

Przyk³adowa sesja debuguj±ca wtyczki podsystemu i bazy danych oraz hierarchii
dokumentów:

# inicjuje wtyczkê obs³ugi bazy danych, zmienna 'database' zawiera odpowiedni±
# referencjê do podsystemu bazy danych przypisan± w procesie inicjacji systemu
db = database.open()
import subsys.ZUS
# otwieram dane podsystemu "ZUS"
ZUS_subsys_data = db.subsys_data["ZUS"]
# inicjujê podsystem ZUS
ZUS_subsys = subsys.ZUS.use_data(ZUS_subsys_data)
# otwieram dane podmiotu "marpet"
this_user_data = ZUS_subsys.data.user_data["marpet"]
# otwieram zestaw dokumentów o nazwie "ZUS-12"
this_docset = this_user_data.documents_set["ZUS-12"]
# lista dokumentów w zestawie:
for doc in this_docset.documents:
	print doc.name, doc.type, doc.comment

Janko_Walski_DRA_2001-12 DRA za m-c 12-2001
Kubus_Puchatek_DRA_2001-12 DRA za m-c 12-2001
.
.
.

odwzorowania oczywi¶cie obs³ugiwane "programowo" (przez __getitem__) celem
unikniecia wczytywania do programu ca³ego drzewa dokumentów na raz.

Mo¿e przydaæ siê jest te¿ dostêp do list dokumentów odpowiedniego typu:

ZUS_subsys.data.user_data["marpet"].documents_sets["ZUS-12"].get_documents_by_type("DRA")

co pozwoli na ³atwe wyliczanie pól n.p. w miesiêcznych formularzach
podsumowuj±cych.

Przydatne równiez mog± wydaæ siê atrybuty pomocnicze, na przyk³ad:

db.subsystems - lista podsystemów, których dane s± przechowywane w systemie;

db.subsys_data[SUBSYS_NAME].users - lista podmiotów, których dokumenty s± obs³ugiwane
                                    przez podsystem;


2.2 kolekcje dokumentów

kolekcje dokumentów mo¿na uzyskaæ poprzez zastosowania koncepcji
metadokumentu. Taki metadokument mo¿e zawieraæ odwo³ania do dokumentów lub
innych metadokumentów. Najwa¿niejsze jest jednak, aby silnik podsystemu umia³
sobie radziæ z takimi zagnie¿d¿onymi dokumentami. Domy¶lnie ka¿dy silnik
powinien umieæ obs³u¿yæ jeden poziom zagnie¿d¿enia.

Metadokument fizycznie nie zawiera ¿adnych danych, wy³±cznie odwo³ania do
innych dokumentów.


3. DALSZE PLANY

Co trzeba koniecznie ustaliæ w pierwszej kolejno¶ci:
 a. interfejsy poszczególnych wtyczek, szczególnie systemu g³ównego i
    podsystemu;
 b. struktura wewnêtrzna danych w Pythonie - model obiektowy;

W dalszej kolejno¶ci:

 c. uzgodniæ domy¶lny format wewnêtrzny p³atnika (propozycja: XML, _nie_
    KEDU);
 d. uzgodniæ interfejsy pozosta³ych wtyczek (GUI, drukowanie itp.).

Na koñcu formalno¶æ: implementacja :-)

UWAGI

1. koncepcje te s± w wiêkszo¶ci zupe³nie ¶wie¿e, czê¶æ z nich zaledwie dopiero
   wymy¶lona i nie przemy¶lana dok³adnie. Mam jednak nadziejê, ¿e mog± pos³u¿yæ
   jako po¿ywka dla dalszych pomys³ów a najlepiej wywo³ac konstruktywn± burzê
   mózgów (nie flame-war ;-)...

2. osoby siedz±ce chwilê w Pythonie proszê o szczególnie krytyczne spojrzenie
   na koncepcjê modu³ów/wtyczek i ich hierarchii - tutaj wiele jest miejsca na
   poprawianie/dodawanie.


-- 
Aby sie wypisac z listy, wyslij maila o tre¶ci 'unsubscribe janosik-devel'
na adres listar at 7thGuard.net