Ucto: par poznamek

[Bohdan Linda <b.linda@sh.cvut.cz>]

Zdravim,

protoze, bohuzel, nebudu moc  se zucastnit na session o ucte (ikdyz ty
burty mne hoodne mrzi), tak bych rad dal par pripominek, ktere vam doufam
k necemu budou:
- Pri navrhu datoveho modelu se musi pocitat s _podvojnym_ ucetnictvim a
  jednoduche derivovat z datoveho modelu pro podvojne. Duvod je ten, ze EU
  funguje pouze na podvojnem ucetnictvi a pravdepodobne do par (1-3) let
  bude u nas taky pouze podvojne.
- Je jasne, ze jako back-end musi byt pouzita transkacni SQLDB. Je docela
  riskatni udelat podporu pouze pro jeden produkt (co v pripade skonceni
  projektu toho SQL servru), takze vyvstava otazka zda obetovat trochu
  vykonu a udelat architekturu trivrstvou s tim, ze jako middle-ware se
  pouzije rozumny jazyk - doporucuju PERL nebo JAVU a vyvaroval se
  jakychkoliv platform-dependent jazyku. Osobne bych dal prednost PERLu,
  diky jeho eleganci a rychlosti tvorby kodu. U dvouvrstve architektury je
  volba pouze pres stored-procedures. To by vsak chtelo psat tyto
  procedury minimalne 3x (pokud nekdo nudela nejaky metaSQL compiler pro
  ruzne SQL produkty) PGSQL, ORACLE a MSSQL
- stored procedures nebo middleware by mel byt psat univerzalne tak, aby
  se dalo emulovat jednoduche ucetnictvi na podvojnem, tj. procedury budou
  mit kod pouze pro podvojne ucetnictvi, kde se zmeni a) organizace parametru -   nepripustne je vetveni kodu dle extra parametru, nebo b)modifikace na 
  frontendu.
- middleware nemusi by skutecny middleware, tj. aby zachovaval
  client/server komunikaci mezi FE a middlewarem a client/server
  komunikaci mezi middleware a BE. Staci, ze FE bude volat middleware
  lokalne.
- FE by mel byt vizualizator zalozen na XML, ktere bude obsahovat jak
  design formulare, sestavy, tak syntax pro zavolani middleware a
  access-level-atribut pro security.
- platform dependent by mel byt pouze vizualizator, ale uplne nejlepsi by
  bylo _hned_ pouzit OK.NET nebo php-gtk! Ziskat konkurencni naskok a
  zatraktivnit to pro uzivatele, pristp odkudkoliv
- koncepce musi byt modularni, idkyz bude pouzito ACL. Duvod je v
  nasazovani v praxi. Kazdy si muze sprovoznit moduly jak se mu zlibi.
  Moduly se by mely byt cleneny na urovni formularu s tim, ze rodicovsky
  formular automaticky spozna pridany modul - reseni napriklad adresarova
  struktura:
     - /opt/ucto (obsahuje XML soubor s hlavni nabidkou, globalni fce)
             |-fakturace (XML s nabidkou fakturace, relativni fce)
	     |     |- odberatelske (XML s nabidkou formul, rel fce)
	     |	   |       |- zavest (XML formular, fce dane pro formular)
	     |     |       |- editovat
	     |     |- dodavatelske
	     |-sklad
  tato struktura nabizi nesmirnou flexibilitu a customizovatelnost
  (samozrejme ~/.ucto obsahuje symlinky na /opt/ucto), coz kazdy user muze
  mit svuj "vzhled" a organizaci menu (middleware by nesmel byt linkovan)

  "refresh" adresarove struktury by se mel dit vzdy pri pruchodu urovne
  nabidek - zarucit dynamicke pridavani modulu. Roletove menu je zdrzujici
  melo by byt pouzito "klasicke", tj na obrazovce je pouze dana uroven
  (ovladatelna klavesami primo) a pak vedle "stromova" nabidka pro ty
  pohodlnejsi uctare


  Zatim ode mne vse
  Bohdan Linda