Szia!

Izgalamas feladat, leirom a sajat hevenyeszett gondolataim. Mellekes: Az alapkoncepciot en szemely szerint nem tartom szerencsesnek, mert a webformos usability limitaciok lekorlatozzak a winformos usability lehetosegeket, de ez csak elvi kerdes nalam, tudjuk milyenek az “enterspajzok” elvarasi, en pedig gazdag kliens maniakus vagyok.

Tul sok informaciot/limitaciot nem adtal meg, igy szabadjara engedem a fantaziam.

Szempontjaim:
– MinimalArchitektura (a MinimalInterface utan szabadon, bar en HumaneInterface “hivo” vagyok, de nem az architektura oldalon!)
– Gyors tervezesi, implementalasi ciklusok, “csigavonal” fejlesztesi metodus, a feature-ok linearisan bovulnek (igy van hasznalhato, de keveset tuso protoipus, mukodo pilot)

Ezen szempontok szerint en sajat implementaciot valasztanek, nem pedig valamilyen mar meglevo (szuperaltalanos, mindenttudo, horror modon testreszabhato, sok, csak a tecnologiara jellemzo “idiosincrasies” tartalmazo) technologiat.

Mi az ami kell:
– Kellene egy designer
– Egy domain specifikus deklarativ nyelv (DSDL)
– A DSDL-hez parser, tree builder, 2 generator (win/web)forms hoz

A designer-t tegyuk felre kicsit, ez nehez ugy, minden esetben.

A DSDL-t en nem XML alapura csinalnam. Kemeny dilemma ez, mivel ellenebe megy az ipar aramlatanak, de nekem szemely szerint (kis, dinamikus, rugalmas csapat, olyan amely tud hatekonyan fejleszteni) rossz tapasztalataim vannak az XML kiterjesztett nyelvekkel, a csapat hatekonysagat erezhetoen visszavetette. Az alapeszkozkent nyujtott XML parser egy nyelv eseteben keves, a parsolas a feldolgozasnak csak az elso, nem is a legbonyolultabb resze. Az XML alapu nyelv nyelvtananak (XML seamajanak) karbantartasa soran a klasszikus XML seama karbanatartasi problemakba utkozunk, mig a sema maga nem igazan intuitiv, konnyebben elkoveti az ember azt a hibat, hogy NE csak kiterjesztenie kelljen az ido soran, hanem atstrukturalni is (-> XML sema verziok problemaja). Szoval en ugy tapasztaltam, hogy egy XML alapu nyelv noveli a fejlesztesi/karbantartasi idot, noveli a rendszer szukseges komplexitasat. Ezek miatt en sajat nyelvet definialnek (meg az is lehet, hogy XML szerut, csak ne a beepitett XML eszkozoket kelljen hasznalni, hanem valami direkt ilyen celra alkotott parser/compiler generatort!) Legfokeppen a nyelvtan megadasa miatt: a BNF ezerszer intuitivabb, kenyelmesebb, atlathatobb, konnyebben kiterjeszthetobb, stb. az XML semanal.

Ha mar parser/compiler generatort hasznalnank, akkor jo tapasztalataim vannak a Coco/R-el es az ANTRL-el.
Ezek nem csak parsert tudnak generalni, hanem testreszabhato syntax-tree buildert (a syntax-tree az XML DOM-nak felne meg.), sot tree parsert is!

Tehat en a kovetkezo modon csinalnam:
– definialnek elso korben egy egyszeru deklrartiv nyelvet BNF alakban (mondjuk ebben a nyelvben a kontroll fuggosegeket fuggosegi graf megadasaval lehetne leirni)
– Generaltatnek hozza parsert, tree-buildert, etc.
– Meginram/megiratnam a ket (kod)generatort fuggetlenul (!) egymastol.

Nagyjabol ennyi.

Terjunk kicsit vissza a designerhez. A formok statikus reszehez (a logika teljes hianya mellett, logikat amugy sem egyszeru desingelni :) lehetne hasznalni mondjuk a VS form designeret. A megdizajnolt formot lehetne assembly-be forditani, majd egy kis tool segitsegevel instancolni, es a kontroll hierarchian vegigiteralva generalni a DSDL-unkben a statikus form struktura leirasat. A logikai reszeket pedig manualisan ezutan hozzaadni. Ez igaz, kisse barkacs megoldas, de olcso, gyors, kenyelmes, hozott anyag lehetosegeit maximalisan kihasznalja, protoipuskent, pilotkent adott esetben megteszi.

… Ehh de jolesett elengedni kicsit a fantaziam. :-)

Wow, egy remek kis VS integracio a Coco-hoz: http://www.codeproject.com/useritems/vsCoco.asp