XAML możliwości ?

Witka
Zgłębiam temat XAML'a, ale może już tutaj na forum mamy specjalistów, więc pomóżcie jeśli możecie. Co mnie interesuje ? Już mówię...

1. Czy można zmieniać wygląd formy (za pomocą XAML) programistycznie już podczas działania ? (chodzi mi o to czy robimy to po staremu np new TextBox czy też w XAML dodajemy elementy itd)
2. Jeśli idzie XAML to jak to się dzieje że zdarzenie dodane do elementu widzi metode np w innej klasie i jak to wiązać ?
3. Jak to się zachowuje w grubym kliencie ?? czy formatki za pomocą xaml'a można wczytywać z dll np w folderze plugins i dodawać do place holderów i po prostu odświeżyć i dodać jakiś element albo np modyfikować XAML rich clienta tak aby podłączyć nowe zdarzenia itd. ?
4. Wady XAML w praktyce ?
5. Zalety korzystania z XAML
6. Co myślicie o XAML ?

Pozdrawiam mam nadzieje, że nie zamieni się to w szereg odpowiedzi... "nom da się" , albo "google" itd

Ja tam moge odpowiedziec na pytanie 1 bo jest konkretne :) Generalnie wyglad mozna definiowac i za pomoca xamla, i za pomoca zwyklego kodu (np c#). Wszystko co daje sie napisac w xamlu mozna tez napisac w c#, ale po to jest ten caly xaml zeby tego unikac, tzn. kod odpowiadajacy za wyglad w xaml, kod odpowiadajacy za dzialanie (logike) w c#.

1. XAML jest 'zasobem tekstowym', nie jest przetwarzany tak jak WinForms Designer na kod a'la InitializeComponent. XAML jest kompilowany do BAML'a, czyli do swojej binarnej reprezentacji - ktora jest bardzo podobna do tekstowej, tyle ze sie szybciej ja potem interpretuje. BAML jest osadzany w assembliu jako zasob i uzywany podczas runtime'a. Innymi slowy, XAML nie tworzy kodu. XAML jest zapisany w binarce. XAML jest ladowany i interpretowany i wykonywany na biezaco w razie potrzeby.

z tego powodu, w dowolnym momencie czasu, mozesz podczas pracy aplikacji skonstruowac sobie stringa, podac go runtimeowi jako xaml do skompilowania, a potem wynik kompilacji "wykonac", wstrzelic na formatke w okreslone miejsce, wyslac przez siec jako string zeby klient to wykonal (i odkrylismy SilverLight, muhahaha), whatever

2. że co? chodzi Ci dowiazanie metody obiektu klasy Ygrek jako EventHandler'a eventu z obiektu klasy Zet? jesli tak, to wez sobie odswiez informacje o delegatach.. (minipakiecik {ref-na-obiekt, pointer-to-method} )

3. tak. patrz opis w pkt. 1

4. upierdliwosc notacji w wielu miejscach, powolnosc (miejscami), brak Dispose, cacheowanie wszystkich DependencyProperty w warstwie WPF, wiele wiele upierdliwosci przy wiazaniu danych, WPF ma problemy sprzetowe na roznych platformach - pusczasz okienko i chodzi, za 5 minut puszczasz okienko i masz BlueScreen'a.. a takze, problemy blizejniewiadomojakie - mialem przypadek ze aplikacja renderowala sie poprawnie na 10 maszynach a na jednej nie, wszystko bylo rozjechane mimo ze ustawienia systemowe (czcionki, ramki, duperele) byly standardowe i identyczne na wszystkich 11stu kompach. ale te dwa to bardzo rzadkie przypadki. a -- no i wymagania sprzetowe... :):):)

ah, i mega minus: brak wsparcia dla dziedziczenia. na danej sciezce dziedziczenia klas, tylko JEDNA (nad)klasa ma prawo miec przywiazanego do siebie XAML'a. inne musza sie obyc bez niego. nie ma zmiluj sie. wszysktie mozliwe ograniczenia jakie z teog wynikaja wychodza szybko. jesli chcesz "odziedziczyc" wizualia po innej klasie, musisz zrobic to kompozycja: jakis obiekt tej innej klasy musisz zagniezdzic w sobie i go renderowac jako siebie, mowiac w skrocie..

i minus temu potomny: zalozmy ze tak zrobisz i ten obiekt wewnetrzny, oryginalny chcesz dostosowac.. chodzenie po jego drzewie zawartosci jest koszmarne - dopoki go nie zrozumiesz. w WinForms, w ASP- bylo "Control.Controls" etc i chodziles sobie po tym. Tutaj jest VisualTree i LogicalTree. Tzn. ze kazdy komponent ma dwoch rodzicow - takiego od renderingu (kto-w-czym sie prezentuje) i od struktury (kto-kogo-zdefiniowal)

i kolejny duzy minus: tak jak w WinForms i ASP - brak wsparcia dla kontrolek generycznych..

5. wiele wiele upierdliwosci przy wiazaniu danych - tak!:) - dopoki sie nie przyzwyczaisz i nie zrozumiesz tego "od deski do deski" to tak to postrzegasz.. ale to de facto nie minus.. porownujac z ASP albo WinForms, kocham XAML'a za te jego upierdliwosci, bo daja w koncu sensowny, spojny i jednoznaczny silnik databindingu). inny plus - przy odrobinie wprawy, totalna separacja GUI od reszty programu bardzo latwa do uzyskania. miodzio. poza tym, wszystkie 'proste operacje graficzne' masz prosto dostarczone. obroty, skalowania, animacje, etc sa definiowalne totalnie poza kodem. jest to upierdliwe, bez narzedzia w stylu Microsoft Blend bardzo ciezkie do sensownego stworzenia - ale.. ostatecznie we Flashu tez nie piszesz grafiki z palca tylko uzywasz edytora.. prawda? co do VisualTree i LogicalTree, po zrozumieniu ich, tez zaczynaja wygladac sensowniej niz pomysly stare z .Controls -- ostatecznie, dzieki temu mozna .. przeszukiwac/definiowac cokolwiek renderujace sie gdziekolwiek, a nie tylko definiowac dzieci renderujace sie 'we mnie'..

6. dobre. dobre. dobre. pare lat temu, piszac w C++ sterte formatek, wkurwilem sie i napisalem cos bardzo podobnego -- parser xml'i opisujacych jak w runtimie generowac formularz, tak zeby definicja danych i definicja grafiki byly osobno, niezle sie zdziwilem jak sie okazalo ze w XAML'u jest sporo podobnych rozwiazan do tego co musialem wykombinowac smameu wtedy..
   ulomnosci designera WinForms i ASP'a chyba dobrze znasz.. generowanie InitializeComponent na podstawie drzewa obiektow w pamieci designera jest morderczym pomyslem, jesli tak nie uwazasz, to znaczy ze designer nigdy jeszcze Ci sie nie .. pomylil. podobnie w ASP'ie z jego generowaniem kodu stron/kontrolek w tle.. acz -- ASP juz byl calkiem niezly jesli chodzi o 'szablony' - ITemplate - ktore pozwalaly podac kontorlce z zewnatrz opis jak ma wygladac jej zwartosc.. ale, proba rozszerzenia obu mechanizmow o cokolwiek przypomina zwykle walenie glowa o sciane. w XAML'u bedzie troche lepiej. sensowniejsze ostylowywanie i wiazanie danych jest na tyle spojnie zdefiniowane, ze da sie rozbudowac o nowe rzeczy, co juz zasluguje na uznanie, zwlaszcza ze przy niezlych mozliwosciach graficznych, bedziesz chcial dorabiac nowe rzeczy i mechaznimy.. AttachedProperties i RoutedEvents beda CI wygladaly dziwacznie, sa dziwaczne. np. zadne DependencyProperty nie moze miec... gettera robiacego cos wiecej niz retun X; - getter nigdy sie nie odpali z poziomu xaml'a. ale za to, to pozwala na AttachedProperties co jest wielkim dodatkiem (mozesz do kazdego obiektu 'dostrzelic' atrybuty, nawet jesli on nie ma takich wlasciwosci sam z siebie)..

IMHO, XAML to bardzo dobry sposob definiowania GUI. jest prostszy niz zmuszanie WinForms designer'a do zrobienia nam dobrze i pozagniezdzania obiektow tak jak MY chcemy a nie on sadzi ze-, jest bardziej przejrzysty przy 'skinowaniu' istniejacych kontrolek niz ASP'owe wygibasy nad ITemplate.. ale ma niedopomyslenia: brak dziedziczenia wizualii prowadzi do koszmarnych wygibasow w miejscach gdzie faktycznie chcesz je uzyskac, brak mozliwosci prostego poprawienia kawalka stylu kontrolki, prowadzacy do koniecnzosci przedefniowania calego stylu na calkiem nowy rozniacy sie jedna linijka drazni i wola o pomste do nieba. ale to sie da przezyc albo obejsc wygibasami i refleksja.. itedeee.. mam nadzieje ze widac z tego ze problemy sa, ale sa inne: bardziej "zaawansowane". proste, podstawowe rzeczy osiagasz w mig

jesli wkurzaja cie ograniczenia WinForms/ASP, zapomnij o nich, zapomnij wszystko i przejdz na XAML'a. uwierz na slowo, ze jest to cos totalnie nowego. zapomnij o wszystkim i nie zwracaj uwagi ze sa miedzy nim podobienstwa z WinForms/ASP, dopoki nie poznasz XAML/WPF dobrze -- bo sie na tych podobienstwach przejedziesz i zmarnujesz kupe czasu tylko po to, by sie na koncu dowiedziec w tutorialu dla newbie ze 'tu sie to robi inaczej' :). serio

a jak juz zaczniesz xamlowac, jesli lubisz uzywac gotowych kontrolek pochodzacych od innych osob/firm i je dostosowywac do swoich widzimisie, idz kupic sobie nowy kontener stalowych nerwow. nie uslyszysz bowiem ze 'no co ty, nie da sie, bo niby jak??', bo sie da i jest to wiadome z gory, ale przeklinac bedziesz kazde drobne niedopomyslenie autorow kontrolki, kazdy brak publicznej wlasciwosci Font czy Color ktora powina byc w tej podkontrolce, kazdy hardcodowany styl graficzny ktory ktos nie pomyslal ze ktos chcailby zmienic :] (WPF! XAML! z definicji chcemy zeby dalo sie zmieniac!).. i vice versa, oni Ciebie za to tez. WPF podnosi mozliwosci i wymagania rowniez :P

Zgadza się.

Obserwacja: po pewnym czasie ustawiania XAMLi przestałem w ogóle używać do tego myszki. Projektowanie zaczęło polegać na pisaniu na klawiaturze i ewentualnie obserwowaniu zmian, które renderują się powyżej.

Wniosek: projektowanie (układanie) staje się w pełni przewidywalne i przejrzyste. I przestaje przypominać grę zręcznościową :-)
//q: hahha.. swietnie powiedziane :))

Dziękuję ślicznie za porządne wypowiedzi, co do pkt.2 Chodzi mi o to, że nie bardzo rozumiem w jaki sposób XAML wiąże (widzi) metody kodu. Jeszcze inaczej mówiąc interesuje mnie np taki przypadek. Mam główną forme i to jest projekt A, ten projekt A odczytuje przy uruchomieniu pluginy i wyłapał np projekt B odczytuje z projektu B ( z biblioteki ), bo znalazł tam pewien interfejs widok i dowiązuje ten widok do widoku A (z ustawień wynika, że do powiedzmy tabeli w głównej części formy A z prawej strony pojawia się lista z B) i teraz. Czy forma A może do XAML dodać triger który po zmianie selekcji na tej liście w A wyświetla zaznaczoną selekcję w liście B. Czy taka sytuacja jest możliwa (tzn przewidziana przez XAML... chodzi o to czy nie muszę pisać właściwie wszystkich interfejsów bla bla bla od nowa czy może po prostu odczytuje string mam jakieś zdarzenia i doklejam to jakby w xml węzeł z trigerami i mam już to na formie głównej)

Nie bardzo rozumiem w jaki sposób XAML odszukuje te metody i je wykonuje z parametrami. Bo w zasadzie jeden koleś może programować, a drugi myśleć nad interfejsem i później to złączyć... racja ?

Inaczej mówiąc jak sprawdza się XAML w pisaniu różnych modułów w grubych klientach ? Przeglądałem codeproject i parę ciekawych zastosowań widziałem, ale są to przykłady pojedyńczych projektów, a to nie jest tym co mnie najbardziej nurtuje.

zamieszales jako zywo.. to co opisujesz to zwykly widok master(lista)-details(inne)

klasycznie, zrobilbys to po prostu:
do listy podpinasz handler na onSelIndexChgd
w tym evencie:
obj = getSelectedValue
details.datasource = obj
finito

w xaml mozesz zrobic to tez wlasnie tak, albo mozesz w DETALACH czyli w XAMLu B zdefiniowac, ze jego zrodlo danych ma byc brane z 'kontekstu', zas w FORMIE/LISCIE zdefiniowac, zeby kontekst Detali byl zbindowany z selectedvalue listy

poczytaj DUŻO i RÓŻNYCH rzeczy na temat databindingu w xamlu, zwlaszcz tez na temat bindowania danych w templatach.. (tzn. szablonach kontrolek).. bardzo wiele rzeczy jestes w stanie uzyskac po prostu tym, bez bawienia sie w 'runtimeową edycje xamla'

to ostatnie tez sie da uzyskac -- wystarczy ze w runtimie utworzysz obiekty triggerow/ich kolekcji/etc i je wstrzelisz w odpowiednie miejsca na drzewie visual/logical.. ale, szczerze, wydaje mi sie ze takie cos to chcialbys robic raczej w ostatecznosci, patrz paragraf wczesniejszy..

a co do wspolpracy miedzyprojektowej, to tak jak zawsze, tak i tutaj, wspolpraca MUSI SIE OPIERAC na wspolnych zalozeniach: specyfikacja wejscia (sposob bindowania, zalozenia co do kontekstu, nazwy template parts, etc), wyjscia (mam byc z wierszem ramka, czy bez?), zachowania (odswiezam sie sam, czy czekam na sygnal refreshu z zewnatrz?) itede. Nigdy nie bedziesz mial tak, ze N osob bedzie moglo sobie w osobnieniu bezslowa i wspolnych ustalen dlubac swoje kawalki kodu i po pol roku sie spotkaja, zderza klatami, i juz bedzie wielki scalony, kompilujacy sie i dzialajacy poprawnie multi-projekt..

Jasne :) właśnie jestem na fragmencie gdzie co nieco o tym piszą... dzięki za helpa. Jak nieco doczytam wezmę się za napisanie takiego przykładu i wszystko będzie jasne.