Meg mielott barki is felreertene(lehet mar keso :)) nem a Delphi vcl vagy a WinForms ellen irok. Inkabb az ellen, hogy a wpf nem eleg jo.
"Kulon van a megjelenites a kodtol. "
Azzal, hogy definiálok XML-ben egy felületet és ahhoz hozzáreszelek még kódot - mert előbb-utóbb előjön az, hogy van kód, ami igazából a megjelenítéshez tartozik - akkor jön egyeseknél a fejvakarás.
Ez csak egy pelda volt, lehetne emliteni meg parat:
-Egy grafikus anelkul tud valtoztatni a feluleten, hogy kod is valtozna. (Lasd Expression Blend/Sketchflow.)
-Nem csak ui tervezesre/kivitelezesre jo, ha jobban megnezed maga a XAML egy alltalanos framework amivel egy objektum fat fel tudsz epiteni. Ha jol emlekszem a WWF(Windows Workflow Foundation) is ezt hasznalja, es barki hasznalhatja, hiszen lehet dinamikusan betolteni xaml fileokat(Ahogy a VS 2010 is teszi, hogy atszabhasd a [url=http://msdn.microsoft.com/en-us/library/aa991992(VS.100).aspx]Start Page-et[/url].).
-Nyelv fuggetlen.
-Mivel sima xml, konnyu hozza toolokat/editort irni. Vagy legalabbis konyebb mint pl. delphi-hez. :)
-Es igy tovabb.
Plusz, ami viszont nem teljesen xaml feature: Veszett gyorsan lehet sajat komponenseket irni. Sokat programoztam Delphi-ben, maig nagy kedvenc, de sajat komponenseket nem csinaltam benne igy nincs osszehasonlitasi alapom. De azt tudom, hogy wpf-ben nagyon konnyu es egyszeru(persze azert az elso nap mindenfele hattertudas nelkul nem ennek kezd/kezdjen neki az ember!). Es sokszor nincs is szukseg uj komponens irasara, mivel eleg jo styling/templating rendszere van a wpf-nek.
Erről eszembe jut most az, amikor az MS által kiadott WPF-s ribbon demót próbáltam átrakni egy saját projektbe. Nah, ott is volt kopipaszta módszerrel átmásolt néhányszáz sornyi XAML kód, ami szinte "csak úgy kellett". Ahhoz képest egy 3rd party Delphis, kattintgatós komponens maga a megváltás volt.
Probald meg azokat a komponenseket ugy szemelyre szabni, mint ahogy wpf-ben lehet, aztan rogton nem is lesz olyan egyszeru az egesz. ;) Pl. ha jol emlekszem Delphi-ben van TButton, meg TImageButton. De mi van, ha mondjuk ket kepet akarsz a gombra, vagy azt akarod, hogy bizonyos esemenyekre(eventekre, vagy akar egy-vagy tobb feltetel teljesulesekor) mas-mas kep legyen rajta? Ezeket wpf-ben trivialis megoldani(par sor). Egy tetszoleges control resource-ebe pl betehetsz egy Style-t, amivel egyes controllok default property-jet allitja at, innentol kezdve a hierarchiaban minden olyan control megkapja azt a style-t.(Pl. app.xaml-ba beteszed, hogy a TextBlock szovege kek szinu legyen, es 16-os betumeret. Innentol kezdve, az egesz alkalmazasodban a TextBlock-okra ez lesz a default.)
Abban viszont igazad van, hogy itt is lehet eleg hosszura sikerult dolgokat alkotni, viszont itt akar tobb ezer sort is atrakhatsz egy kulon xaml resource file-ba anelkul hogy az editor megzavarodna tole. Abban a ribbon demo-ban levo "csak ugy kellett" kodot szepen, igenyesen szet lehet szervezni kulonbozo logika alapjan kulonbozo helyekre(valoszinuleg a demo-nak nem ennek a demonstralasa volt a celja).
Áh, ha 10-20 évvel régebb óta űzném az ipart, akkor lehet jobban hisztiznék emiatt. Most csak szimplán nem látom azt a mindent beragyogó fényes üstököst, ami miatt annyira jó lenne a régebbi technológiákhoz képest. Főleg, hogy valahol arra van ráépítve az egész.*
Nem celom elhitetni, hogy ez a szent gral, de nem is rosszabb mint a tobbi.
Ui: ok, tudom, ez most nincs nagyon összeszedve jól, de most nem vagyok olyan hangulatban, hogy mindent összeszedjek rendesen. Sry érte.
En is irhatnek jobb peldakat mint a 16-os meretu kek szinu TextBlock. :)