[janosik-devel] Re: leniuszki

[Marek Pętlicki]

W liście z śro, 02-01-2002, godz. 22:21, Zbigniew Chyla pisze: 

> W czasie obliczania wyrażenia zaimportowane są moduły (tutaj lista modułów),
> dostępne pod ich nazwami, dodatkowo zaś wszystkie moduły dostępne są za
> pośrednictwem obiektu MOD (w lokalnej przestrzeni nazw). Oznacza to
> oczywiście, że pozostałe moduły importowane są "automagicznie". Tak więc
> jeśli wśród domyślnie zaimportowanych modułów nie ma fnmatch, ale my
> koniecznie chcemy użyć funkcji fnmatch, to możemy napisać:
> ... check_expression="MOD.fnmatch.fnmatch(VALUE, '*.doc')" ...

ciągle umyka jedna sprawa: niektóre dokumenty zawierają pola będące
wyliczeniem wartości odpowiednich pól z _innych dokumentów_. Co z tym
robimy? Definicja tego wyliczenia też musi znaleźć się w schemacie. Co
więcej wartość tego wyliczenia musi pojawiać się w formularzu (ja znów o
tym GUI ;) dla kontroli bez możliwości edycji (Pani Józia Od Płac
sprawdza sobie szybciuteńko na takim kalkulatorku z drukareczką, czy
wszystko się zgadza ;-)

Dlatego trzeba też zdefiniować pola wyliczeniowe, być może znów za
pomocą wyrażenia Pythona.

	default_value="MOD.calcu.calculate_it()"

Pola też powinny mieć atrybut:

	read_only="FALSE"

(wartość domyślna tego atrybutu dla wszystkich pól) aby móc zdefiniować
pola tylko do wglądu, żeby Pani Józia nie poprawiała statystyk ;-)

Otwarcie dokumentu danego typu może również spowodować załadowanie
odpowiedniego modułu definiującego funkcje specyficzne dla tego
dokumentu. Dzięki temu możemy ominąć zależność Janosika od konkretnych
typów dokumentów a ludziki będą mogły same definiować sobie nowe
formularze bez ingerowania w kod programu. Co Wy na to?
Wtedy przykładowy wiersz zmieniłby się na:

	default_value="MOD.doc_specific.calculate_it()"

czy cóś ;->

Dodatkowo aby to wszystko działało musimy zdefiniować strukturę p.t.
zestaw dokumentów (jak ma to miejsce w Płatniku). Ta struktura powinna
również rezydować w lokalnej przestrzeni nazw aby funkcje wyliczeniowe
miały łatwy dostęp do innych dokumentów zestawu.

Inna rzecz, że wysyłka danych do ZUS również odbywa się zestawami, więc
istnienie takiego pojęcia w naszym programie wydaje się zasadne.

W tej sytuacji zapewne jednym z argumentów większości funkcji
wyliczeniowych powinien być obiekt zestawu, na którym należy wykonać
wyliczenia (co również umożliwi korzystanie z wielu zestawów dokumentów
jednocześnie):

	default_value="MOD.doc_specific.calculate_it(DOC_SET)"

Sprawa się komplikuje, ponieważ takie zagłebianie (zestawy zestawów,
zestawy zestawów zestawów itp.) może nie mieć końca bo nikt nam nie
zagwarantuje, że nie będzie trzeba sporządzać zestawienia
rocznego/dekadowego (na przestrzeni 10 lat) itp., gdzie w rachubę będą
wchodzić zestawy miesięczne czy też roczne zestawy miesięcznych
zestawów... uff...

Można pójść na łatwiznę i grupować po prostu na podstawie kalendarza
(miesięcznie, rocznie itd), ale bywają też zestawienia kwartalne,
pięciolatki, kadencje (4 lata ;) i sam Minister wie co jeszcze ;-)

Coś trzebaby tu wymyślić. Sądzę, że teraz jest najlepszy moment na
zdefiniowanie takich rzeczy jak powiązania pomiędzy dokumentami itp.

pozdrawiam

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



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