Silverlight 2.0 beta 1 + Visual Studio 2008 tools gereleased

[beany]

Microsoft heeft vandaag SL 2.0 beta 1 vrijgegeven. Om er ook daadwerkelijk apps voor te maken is ook de VS2008 Silverlight toolset vrijgegeven.

De toolset is hier te downloaden: http://www.microsoft.com/silverlight/resources/tools.aspx

De toolset werkt overigens niet met Visual Studio 2008 Express editie(!).

Het is duidelijk dat er nog een hoop werk verzet moet worden. In VS werkt de drag&drop interface niet, je moet alles met het handje intypen. Ook de control set is nog niet compleet, Microsoft heeft aangegeven dat in de final release er meer controls zullen zitten. Maar de basis controls zitten er in!(button, textbox etc etc).

Wat ik alleen zo gauw nog niet heb kunnen vinden is welke .Net classes beschikbaar zijn en welke niet. Silverlight bevat namelijk een subset van het gewone .Net framework en niet het volledige framework! Heeft iemand hier een informatief linkje van?

En verder: deel hier je ervaringen, tips, problemen en misschien wel een aardige showcase?

[ Voor 4% gewijzigd door beany op 06-03-2008 10:30 ]

[whoami]

-> DTE

[Niemand_Anders]

Een hoop technische informatie kan gevonden worden bij de opensource variant moonlight.

Na de installatie van beta 1 is er een readme.txt in de folder 'C:\Program Files\Microsoft SDKs\Silverlight\v2.0\Documentation\VS-Help'. Volg de aanwijzingen in dit bestand en silverlight 2 documentatie is beschikbaar in je lokale MSDN en weet je dus precies welke classes beschikbaar zijn..

[Niemand_Anders]

Oh ben ik nog even het MSDN path vergeten: (Filtered by: unfiltered!) --> Microsoft Silverlight 2 SDK --> Silverlight 2 beta 1 - Development with the .net framework --> Silverlight reference.

[EfBe]

Of hier:
http://msdn2.microsoft.com/en-us/library/bb404716.aspx

Erg summier framework, er zit geen system.data in bv. Code porten van normaal .net naar cf.net was al een ramp, maar dit wordt onmogelijk volgens mij.

[Niemand_Anders]

EfBe schreef op donderdag 06 maart 2008 @ 13:08:
Of hier:
http://msdn2.microsoft.com/en-us/library/bb404716.aspx

Erg summier framework, er zit geen system.data in bv. Code porten van normaal .net naar cf.net was al een ramp, maar dit wordt onmogelijk volgens mij.

Zelf vind ik de online interface uitermate irritant (langzaam, framesets, etc). Het zou fijn zijn dat als ze die navigatie boom niet zo minimalistisch ophalen.

Maar waarom zou een client control dan een verbinding moeten maken met een database? Voor communicatie met de server zijn WFC, Webservices, WebRequests en XML beschikbaar. De System.Data namespace heb je dus niet nodig. Daarbij zijn de meeste database servers niet vanaf het internet benaderbaar. Wij zijn hier nu lekker aan het spelen met beta 1, maar wij zijn nog geen problemen mbt porting tegen gekomen.

Heb je meer nodig, dan moet je misschien WPF browser applicaties kijken.

[EfBe]

erm... datatable? Je kunt nu alleen data uit een db naar de client sturen in DTO's. Als je met datatables werkt etc. lukt dat dus niet.

Als ik onze runtime naar silverlight wil porten (niet de SQL engines, maar de runtime voor entities/change tracking etc.) dan gaat dat lastig worden, ik kan bv niet de compactframework variant pakken (custom build) en die op silverlight draaien want silverlight's framework is kleiner.

Dus je zit vast aan domme DTO's en het nadeel is dat wanneer je data van service naar client stuurt, daar update en dan terugstuurt, je op de service dus moeilijk moet gaan doen met change tracking van je entities.

Ik krijg het wel werkend denk ik, maar het is lastig, want veel classes zitten er niet in, en welke er wel in zitten hebben waarschijnlijk minder methods, dus het is niet makkelijk om code zomaar over te zetten, wat het ook niet was voor cf.net.

[Niemand_Anders]

EfBe schreef op donderdag 06 maart 2008 @ 16:28:
erm... datatable? Je kunt nu alleen data uit een db naar de client sturen in DTO's. Als je met datatables werkt etc. lukt dat dus niet.

Als ik onze runtime naar silverlight wil porten (niet de SQL engines, maar de runtime voor entities/change tracking etc.) dan gaat dat lastig worden, ik kan bv niet de compactframework variant pakken (custom build) en die op silverlight draaien want silverlight's framework is kleiner.

Dus je zit vast aan domme DTO's en het nadeel is dat wanneer je data van service naar client stuurt, daar update en dan terugstuurt, je op de service dus moeilijk moet gaan doen met change tracking van je entities.

Ik krijg het wel werkend denk ik, maar het is lastig, want veel classes zitten er niet in, en welke er wel in zitten hebben waarschijnlijk minder methods, dus het is niet makkelijk om code zomaar over te zetten, wat het ook niet was voor cf.net.

Maar silverlight is toch alleen maar de presentatie laag eventueel met een beetje frontend logica? Deze logica roept toch gewoon de standaard op de server aanwezig zijnde middleware aan (waar je dus wel de beschikking hebt dat de System.Data namespace). Deze middleware behoort te communiceren met je entity (data) laag. Althans, dan is de structuur welke ik gebruik bij mijn projecten en ik heb dan ook weinig last om om bestaande classes in silverlight te gebruiken.

[EfBe]

Ja dat zou moeten inderdaad, helaas willen veel mensen meer dingen op de client regelen, zoals change tracking, graph management (nieuwe order in customer.orders plaatsen, handel terugsturen, graph wordt automatisch gesaved etc.). Ik denk wel dat het komt omdat het nieuw is en men niet echt weet wat allemaal kan en niet kan, en beter: wat je beter wel en niet kunt doen. Men leest '.net framework' en men denkt dat het runnen van allerlei code op dat framework moet kunnen.

[Roet]

EfBe schreef op vrijdag 07 maart 2008 @ 21:19:
Ja dat zou moeten inderdaad, helaas willen veel mensen meer dingen op de client regelen, zoals change tracking, graph management (nieuwe order in customer.orders plaatsen, handel terugsturen, graph wordt automatisch gesaved etc.). Ik denk wel dat het komt omdat het nieuw is en men niet echt weet wat allemaal kan en niet kan, en beter: wat je beter wel en niet kunt doen. Men leest '.net framework' en men denkt dat het runnen van allerlei code op dat framework moet kunnen.

Hoezo zeg je "Helaas willen veel mensen meer dingen op de client regelen" ? Als je een Silverlight applicatie via WCF wilt laten praten met je business logic (incl. bijbehorende entities), is het toch handig om de state op de client al bij te houden, zodat je niet alle DTO's over het web hoeft te sturen, maar alleen de gewijzigde?

Ik zal waarschijnlijk wel iets over het hoofd zien, maar ik ben wel benieuwd wat dat precies is. Het is misschien niet het mooiste design pattern, maar het werkt en daar gaat het uitendelijk toch grotendeels om.

[EfBe]

Roet schreef op woensdag 02 april 2008 @ 15:34:
[...]

Hoezo zeg je "Helaas willen veel mensen meer dingen op de client regelen" ? Als je een Silverlight applicatie via WCF wilt laten praten met je business logic (incl. bijbehorende entities), is het toch handig om de state op de client al bij te houden, zodat je niet alle DTO's over het web hoeft te sturen, maar alleen de gewijzigde?

Ik zal waarschijnlijk wel iets over het hoofd zien, maar ik ben wel benieuwd wat dat precies is. Het is misschien niet het mooiste design pattern, maar het werkt en daar gaat het uitendelijk toch grotendeels om.

Die logica vereist veel meer code, terwijl de platforms waar die dunne UIs op draaien daar niet altijd voor geschikt zijn. Je maakt je UI ook veel dikker, zodat je een fat client hebt, ipv een thin client. Niet iets wat je wilt IMHO.

[Roet]

EfBe schreef op woensdag 02 april 2008 @ 18:52:
[...]

Die logica vereist veel meer code, terwijl de platforms waar die dunne UIs op draaien daar niet altijd voor geschikt zijn. Je maakt je UI ook veel dikker, zodat je een fat client hebt, ipv een thin client. Niet iets wat je wilt IMHO.

Dat 'veel meer' vind ik meevallen. Stel je houdt in een grid de rowstate bij en je flagged de objects met hun state en je stopt ze in een list/collection, dan kun je die op de serverzijde goed verwerken. Er zijn betere oplossingen, maar de keuzes zijn beperkt met Silverlight.

Daarnaast zorgt clientside state-tracking er wel voor dat de belasting op je server een stuk minder wordt en ook het dataverkeer tussen de client en de server is minder. Dat maakt mijn inziens de applicatie ook beter schaalbaar.

[Ruudjah]

DIT BERICHT IS PREVENTIEF VERWIJDERD DOOR DE GEBRUIKER

[ Voor 95% gewijzigd door Ruudjah op 01-12-2009 22:52 ]