Sergejus apie .NET

Šiandien darbe prisireikė atvaizduoti elementų aibę vienoje eilutėje, t.y. kitaip tariant – sukonkatenuoti elementus. Iš karto kilo mintis pasirašyti IEnumerable praplėtimo metodą Concatenate. Kadangi norėjosi tam tikros laisvės nurodant ką ir kaip konkatenuoti, nusprendžiau kaip vieną iš metodo argumentų priimti delegatą, kuris ir leistų konfigūruoti konkatenavimo procesą. Pats kodas yra labai elementarus:

Jo pagalba, elementų aibė galėtų būti konkatenuojama taip:

Kas rezultate atitinkamai duotų:

Taigi taip greitai, patogiai, o svarbiausia intuityviai, pavyko išspręsti aprašytą uždavinį.

Tikriausiai didžioji jūsų dalis žino, kad Visual Studio 2010 CTP turėjo pilnai perrašyta su WPF pradinį sprendimo puslapį bei kodo redaktorių. Tuo pačiu metu ėjo kalba ir apie pagrindinių langų perrašymą. Šiandien Jason Zander, Visual Studio grupės vadovas, savo bloge parodė keletą tokių langų pavyzdžių. Kol kas viskas atrodo tikrai neblogai, tikiuosi, kad visa tai dar ir veiks pakankamai greitai. Vienu žodžiu - laukiame Visual Studio 2010 Beta versijos…

Kuo toliau, tuo intensyviau jQuery biblioteka yra plėtojama. Visai neseniai pasirodė 1.3.1 versija, o dabar ir jQuery 1.3.2. Šį kartą, IntelliSense failas atsinaujino kartu su biblioteka.

Prieš tai aprašytas būdas automatiškai formuoti korektišką nuorodą iki suspausto arba nesuspausto JavaScript failo nieko nesakė apie patį JavaScript failų suspaudimą. Keli skaitytojai tai teisingai pastebėjo komentaruose, o Domantas net nurodė vieną tokią realizaciją. Tai priminė man, kad savo laiku perskaitęs minėtą straipsnį, aš papildžiau ten aprašytą programą CSS suspaudimu. Programa naudoja .NET adaptuotą Yahoo UICompressor versiją.

JavaScript ir CSS failų suspaudimas Web projekto kompiliavimo metu privertė mane truputi pergalvoti praeitame straipsnyje aprašytą strategiją. Dabar tiek suspausti, tiek nesuspausti failai vadinasi vienodai, skirtumas tik tas, kad suspausti failai yra talpinami į katalogą Release. Pavyzdžiui, turint JavaScript katalogą su jquery.js ir common.js failais, Web projekto kompiliavimo metu į katalogą JavaScript/Release bus patalpinti suspausti failai jquery.js ir common.js.

Taigi realizuojant tokią strategiją, pirmą aprašykime suspaudimo programą:

Kur CompressDirectory ir CompressFile atrodo taip:

Laikykime, kad aukščiau pateiktas kodas susikompiliuoja į programą YUICompressor.exe. Tada ją kartu su priklausomomis bibliotekomis (EcmaScript.NET.modified.dll ir Yahoo.Yui.Compressor.dll) perkeliame į mūsų projektą, pavyzdžiui, katalogą Dependencies:

Tam, kad JavaScript failai iš katalogo Scripts būtų spaudžiami ir talpinami į Scripts/Release po kiekvieno Web projekto kompiliavimo, projekto nustatymuose aprašome Post-build įvykį:

Primenu, kad mano aprašytas YUICompressor priima tris argumentus: katalogą kur guli spaudžiami failai, katalogą kur bus patalpinti suspausti failais ir spaudžiamų failų tipas (js arba css).

Viskas! Dabar kiekvieno kompiliavimo metu mes turėsime suspaustus JavaScript failus:

Paskutinis žingsnis – atnaujinti praeitame straipsnyje aprašytą metodą RegisterInclude, tam kad nurodyti korektišką kelią iki JavaScript failų Debug ir Release metu:

Šaunu tai, kad iš ASPX pusės JavaScript registracija liko nepakitusi:

Taigi, jūsų pagalba, mes dabar turime pakankamai pilną JavaScript (ir CSS) failų suspaudimo ir nuorodų parinkimo strategiją. Kaip vertinote tokį sprendimą? Gal turite dar kokių minčių? Rašykite!

Pasirodo, Microsoft pradėjo lietuviškos Windows 7 versijos beta testavimą. Versija nėra viešai platinama, bet esant norui ir ryžtui - galite nusiųsti prašymą įtraukti jus į testavimą adresu win7lt@microsoft.com. Taip pat mano žiniomis, labiausiai prisidėję prie testavimo - gaus tam tikrų dovanų iš MS. Taigi visi lokalizuotų programų entuziastai – turite gerą progą pasižymėti ;)

Praktiškai bet kuri ASP.NET aplikacija naudoja vieną arba daugiau JavaScript failų. Kaip žinia, kūrimo metu patogiau naudoti nesuspaustus failus, nes tai palengvina derinimą. Vykdant gi galutinę instaliaciją pas klientą vienareikšmiškai geriau naudoti suspaustus / supakuotus JavaScript failus, nes jie užima beveik dvigubai mažiau vietos. Nors tai ir nėra didelė problema, bet iki šiol tekdavo rankomis kaitalioti failų versijas. Šiandien nusprendžiau pagaliau tai sutvarkyti.

Mano atveju, aš laikausi susitarimo, kad jeigu egzistuoja tiek nesuspausta, tiek suspausta JavaScript failų versijos, nesuspaustoji turi galūnę .debug.js. Taip, turint failus jquery.js ir jquery.debug.js, pirmasis yra suspaustas, o antrasis ne. Jeigu neegzistuoja suspaustos versijos, tada .debug.js galūnė nėra rašoma (pvz., common.js).

Turint visą tai omenyje, aš parašiau vieną metodą RegisterJavaScript, kuriam galima perduoti reikalingų JavaScript failų pavadinimus:

RegisterJavaScript patikrina ar Web.config faile nurodyta compilation debug=”true” ir jeigu taip, prideda .debug.js galūnę (su sąlyga, kad failas fiziškai egzistuoja):

Atkreipkite dėmesį, kad aš aprašiau apibendrintą metodą RegisterInclude, kurio pagalba panašią techniką galima pritaikyti ir CSS failams. O ką jus naudojate tokiais atvejais? Būtų laibai įdomu sužinoti jūsų patirtį!

Atsinaujino pakankamai daug kritikos sulaukęs ASP.NET MVC grįstas blogų karkasas - Oxite, apie kurį jau esu rašęs. Noriu priminti, kad Oxite buvo sukurtas MIX komandos specialiai MIX09 konferencijai, o vėliau kodas buvo išplatintas .NET bendruomenei. Būtent kodo kokybė bei Oxit architektūra ir sulaukė didžiausios kritikos. Anot kūrėjų, ši versija atsižvelgia į didžiąją dalį pastabų. Pasižiūrėsime kas išeis…

Apie C jau kuria dainas, kada sulauksim apie C#?

Perskaitę antraštę daugelis tikriausiai pagalvojo - “grįžta dirbti”? Iš tiesų ne - grįžtu, nes už dviejų savaičių prasideda kasmetinis MVP susitikimas - MVP Summit.

Kadangi MVP statusą aš turiu tik pirmus metus, tai nelabai įsivaizduoju net kaip viskas vyks. Kol kas tik aišku, kad pirmoji ir ketvirtoji susitikimų diena vyks Seattle, o kitos dvi - Redmonde. Skirtingai negu įprastose konferencijose, pristatymai, į kuriuos gali vaikščioti, griežtai apriboti MVP kompetencija (mano atveju - C# ir ASP.NET kaip domėjimosi kompetencija). Šiuo metu jau užsirašiau į pristatymus iš:

• C# vNext (sekanti versija po 4.0)


• Visual Studio vNext (sekanti versija po 2010)


• Silverlight 3.0


• Entity Framework 2.0


• ASP.NET MVC 2.0


• Workflow Foundation 4.0


• ir keleto kitų technologijų

Dabar jau galiu pasakyti, kad .NET vartotojų grupių susitikimas įvyks po mano grįžimo (kovo antrą savaitę). Jo metu žadu pasidalinti naujienomis iš MVP Summito (aišku, kiek bus viešos informacijos)!

Kurdami ASP.NET puslapius kiek dėmesio mes skiriame klaidų atvaizdavimo patogumui? Tikrai nedaug! Liūdna, bet ASP.NET klientinis validavimas susiveda į HTML SPAN elemento atvaizdavimą. Mes neturime būdo, kaip vaizdžiai pažymėti komponentą kuriame įvyko klaida.

Vienas iš galimų sprendimo būdų – perrašyti visus ASP.NET validatorius, o tiksliau OnRender metodą. Man tai daryti visiškai nesinori! Kitas variantas – įsiterpti į validatoriaus atvaizdavimą klientinėje dalyje. Šiame straipsnyje aš parodysiu kaip nesunkiai galima tai padaryti.

Tarkime, mes turime tokį ASPX puslapį:

Nieko gudraus. Validavimo klaidos būtų vaizduojamos taip:

Jeigu kam teko nagrinėti ASP.NET klientinio validavimo JavaScript failą – žino, kad egzistuoja funkcija ValidatorUpdateDisplay, kuri ir atsako už validavimo klaidų atvaizdavimą. Kas trukdo mums ją modifikuoti? Visai nesunkiai galima padaryti taip, kad jį kviestų mūsų nurodytą kodą. Papildykime mūsų ASPX kodą:

Puslapio pasikrovimo metu aš išsaugau nuorodą į originalią ValidatorUpdateDisplay funkciją, o tada priskiriu savo aprašytą funkciją friendlyValidatorUpdateDisplay. Tokiu būdu, kiekvieną kartą kai bus vykdomas klientinis validavimas, vietoje originalios ValidatorUpdateDisplay funkcijos bus kviečiama mano. Ji susideda iš originalios funkcijos bei papildomos logikos, kuri priskiria nurodytą CSS klasę komponentui, kuris yra validuojamas. Rezultate mes gauname žymiai patogesnį validavimo klaidų atvaizdavimą: