Soci (Soczó Zsolt) szakmai blogja

2007.03.22.

User interface description for ASP.NET és WinForms

Filed under: .NET,Design,Felhívás,Szakmai élet — Soczó Zsolt @ 13:34

Kiírom, hátha van valakinek jó ötlete, vagy akár csinált már ilyet.
A feladat, hogy viszonylag egyszerű, form alapú, adatbázis hátterű appokat (ez ugye az enterspájz dev) akarnak írni. A UI-t mindenképpen csak egyszer akarják leírni, valamilyen metanyelven, amelyből egy-egy keretrendszer asp.net WebForms és Winforms kimenetet készít. Nem feltétlen előfordítással, hanem akár azonnali értelmezéssel.
Nem csak a GUI-t kell leírni, de egyszerűbb logikát is kell támogatni. Pl. ha nincs valami kitöltve, akkor egy másik control csoport disabled legyen, stb.

Vannak GUI leírók, mint a XUL vagy a XFDL, esetleg XAML.
Az egész cuccnak menni kell w2k-n, így fw. 2.0 a max, amit lehet használni. Jó lenne, ha a meglévő nyelvet kibővítve a hozzá kapcsolódó esetlegesen létező designer programot is ki lehetne bővíteni az új nyelvtannak megfelelően.

Van valakinek ötlete, netán tapasztalata a témában? Szívesen beszélgetnék róla kicsit.

4 Comments

  1. 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. :-)

    Comment by Szindbad — 2007.03.23. @ 10:04

  2. Szindbad: nagyon köszönöm, megtisztelsz, hogy ilyen bő lére eresztetted.
    Az egészben a legérdekesebb rész, hogy nem xmlt javasolsz. Ez persze nem új, mert pl. az ant esetében is sokan vartyogtak, hogy tök szar xmlben leírni a build részeit, sok esetben sokkal egyszerűbb lenne valamilyen saját, nem kacsacsőrös nyelv.
    Megfontoljuk, amit írtál, köszönöm szépen.

    Comment by Soczó Zsolt — 2007.03.23. @ 10:20

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

    Comment by Szindbad — 2007.03.26. @ 06:27

  4. […] Document Schema Definition Languages * DSDM Dynamic Systems Development Method * DSL Digital …Soci blog Blog Archive User interface description for …A DSDL-t en nem XML alapura csinalnam. Kemeny dilemma ez, mivel ellenebe megy az ipar … kontroll […]

    Pingback by dsdl — 2010.03.05. @ 08:56

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Powered by WordPress