Sergejus apie .NET

Klausimas #8

Web optimizavimo technologijos rekomenduoja visus JavaScript failus sukombinuoti į vieną. Aš tą pati norėčiau atlikti savo puslapiuose.

Atsakymas

Ši galimybė yra prieinama ScriptManager nuo ASP.NET 3.5 SP1. Viską ką reikia padaryti, tai patalpinti ScriptManager Scripts skiltį į CompositeScript:

Šiame pavyzdyje puslapyje bus naudojami trys JavaScript skriptai: jQuery.js, common.debug.js ir naujas skriptas, kuris sukombinuoja WebForms.js ir WebUIValidation.js skriptus.

Klausimas #9

Pasinaudojant standartiniu ScriptManager skirptų kombinavimo mechanizmų rezultate gaunu AXD skriptą. Aš noriu vietoje jo naudoti įprastą nuorodą iki statinio skripto.

Atsakymas

Tai yra įmanoma, bet reikalauja papildomo darbo. Nurodžius CompositeScript skiltyje reikalingus skriptus, reikia išsaugoti sukombinuoto skripto turinį lokaliai (turinį galima pamatyti vykdant aplikaciją iš Visual Studio arba naudojant Internet Explorer Developer Toolbar). Tai reikia atlikti tiek su suspaustais skriptais, tiek su skirtais derinimui (kad turėtume dvi sukombinuotų skriptų versijas). Galiausiai CompositeScript savybės Path pagalba nurodome kelią iki mūsų sukombinuoto failo:

Kaip matyti, aš sukombinavau standartines ASP.NET JavaScript bibliotekas į failus system.web.js (suspausta versija) ir system.web.debug.js (versija skirta derinimui). Rezultate gauname labai tvarkingą HTML kodą:

Klausimas #10

Savo puslapiuose norėčiau naudoti lokalizuotus JavaScript pranešimus. Kokios yra su tuo susijusios gerosios praktikos?

Atsakymas

ScriptManager turi labai gerą skriptų lokalizacijos galimybę, kuri pagal savo principą yra labai panaši į ASP.NET puslapių lokalizaciją. Pirma reikia sukurti JavaScript failą, kuris atitiks kalbą pagal nutylėjimą (pvz., Resources.js) bei failus, atitinkančius kiekvieną palaikomą kalbą (pvz., Resources.lt-LT.js):

Pateiktuose failuose aprašytas JavaScript objektas Resources su savybe Message. Toliau pasinaudojame šiuo objektu viename iš skriptų:

Tam kad automatiškai būtų naudojamas reikalingas lokalizacijos failas, reikia ScriptManager nurodyti EnableScriptLocalization="true" bei pridėti nuorodą į JavaScript resursų failą:

Atkreipkite dėmesį į tai, kad savybėje ResourceUICultures reikia per kablelį išvardinti visas palaikomas kalbas. Nuo šiol užtenka puslapyje nurodyti UICulture, ir pagal tai bus automatiškai parenkamas reikalingas JavaScript lokalizacijos failas!

Taigi tiek naujo ir mažai žinomo ASP.NET 4.0 ScriptManager funkcionalumo aš norėjau parodyti šiame straipsnių cikle. Tikiuosi nuo šiol nebeliks programuotojų, kurie vengia jį naudoti ir galės pasinaudoti visomis gerosiomis ScriptManager savybėmis kasdieniame darbe. Labai laukiu jūsų atsiliepimų ir nevenkite spausti „patiko“, jeigu jums tikrai straipsnis patiko…

Klausimas #5

ScriptManager savybės ScriptMode pagalba galima nurodyti kokia skriptų versija turi būti naudojama: skirta derinimui – *.debug.js arba suspausta – *.js. Aš noriu nurodyti kitus susitarimus, pavyzdžiui, naudojamus jQuery: derinimui skirta versija pasibaigia *. js, o suspausta – *.min.js.

Atsakymas

ASP.NET 3.5 SP1 ScriptManager mokėjo operuoti tik minėtu *.debug.js susitarimu, todėl vienintelis variantas pasinaudoti automatiniu tinkamos skriptų versijos parinkimo galimybe buvo patiems pervardinti failus pagal ScriptManager naudojamus susitarimus.

Džiugi naujiena, kad su ASP.NET 4.0 ScriptManager galima aprašyti bet kokius susitarimus (tiesa, kiekvienam failui atskirai). Nuo šiol ScriptManager atsirado savybė ScriptResourceMapping, kur ir galima pridėti jQuery bibliotekos failus:

Atkreipkite dėmesį į tai, kad sąsajos aprašomos Global.asax faile. Taip pat iš pateikto pavyzdžio matyti, kad būtent ScriptResourceDefinition objektas nurodo visus reikalingus jQuery bibliotekos kelius. Paskutinė pastaba – AddDefinition metode pirmasis parametras yra resurso pavadinimas, kuris ir turi būti naudojamas ScriptManager Scripts skiltyje:

Nuo šiol, priklausomai nuo ScriptMode savybės reikšmės, reikalingas jQuery bibliotekos failas bus automatiškai parenkamas.

Klausimas #6

Kaip žinia, jQuery yra patalpintas net keliuose CDN (Content Delivery Network). Aš noriu įgalinti ScriptManager krauti atitinkamą skriptų versiją (suspaustą ar skirtą derinimui) iš norimo CDN.

Atsakymas

Dabar tai yra daroma labai paprastai ir mums tereikia papildyti ScriptResourceDefinition aprašą iš praeito pavyzdžio:

Atkreipkite dėmesį į tai, kad jus net galite nurodyti skirtingus CDN suspaustai versijai bei versijai skirtai derinimui. Norėdami krauti skriptus iš CDN, nepamirškite ScriptManager nurodyti EnableCdn="true".

Klausimas #7

Visos standartinės ASP.NET JavaScript bibliotekos, pavyzdžiui, WebForms.js, WebUIValidation.js ir pan. yra kraunamos naudojant WebResource.axd arba ScriptResource.axd. Aš noriu atsikratyti AXD failų ir vietoje jų rodyti kelią iki normalių JavaScript failų.

Atsakymas

Iki šiol tai buvo pakankamai sunkiai pasiekiama. Nuo šiol tai galima padaryti paprasčiau (bet vis dar tai reikalauja pastangų). Visi minėti JavaScript failai randasi System.Web.dll bibliotekoje, dėl ko ir atsiranda AXD failai. Ką reikia padaryti, tai:

• lokaliai išsaugoti reikalingus JavaScript failus;
• perrašyti susiejimus ScriptResourceMapping pagalba.

Tarkime, mes norime išvengti AXD failų kraunant WebForms.js (postback logika) ir WebUIValidation.js (standartiniai ASP.NET validatoriai) failus. Pirma šių failų turinį reikia išsaugoti lokaliuose failuose (turinį galima pamatyti vykdant aplikaciją iš Visual Studio arba naudojant Internet Explorer Developer Toolbar). Turint šiuos failus, tereikia perrašyti susiejimus, kad kraunant nurodytus failus būtų kreipimąsi ne į System.Web.dll, bet į mūsų nurodytus JavaScript failus:

assemblySystemWeb – tai tiesiog nuoroda į System.Web.dll rinkinį. Pačiame ScriptManager nieko papildomai registruoti nereikės, viskas bus daroma automatiškai! Vieną dalyką kurį pastebėjau, tokie standartiniai JavaScript failai kažkodėl neatsižvelgia į DebugPath ir visada naudoja tiesiog Path savybės reikšmę…

Tai tiek įdomybių šiam kartui, kitoje dalyje aptarsiu automatinį skriptų apjungimą naudojant ScriptManager. Tikiuosi šis straipsnių ciklas bus jums ypač naudingas prieš pradedant naujus projektus su ASP.NET 4.0!

Nuo paties ASP.NET AJAX bibliotekos atsiradimo ScriptManager suskaidė ASP.NET programuotojus į tuos ką šį komponentą myli ir tuos, kas vengia jį naudoti. Pirmiesiems patinka ScriptManager pagrinde dėl dviejų dalykų: UpdatePanel palaikymo ir JavaScript proxy klasių generavimo ASMX ir WCF web servisams. Antrieji nenori naudoti ScriptManager dėl to, kad kartu su juo priversti naudotis ir visa ASP.NET AJAX biblioteka: MicrosoftAjax.js (82 KB suspausta) ir MicrosoftAjaxWebForms.js (29 KB suspausta). Laimei, ASP.NET 4.0 ScriptManager yra tiek patobulintas, kad jį pamils visi!

Šiandien aš pradedu kelių straipsnių ciklą iš naujų ir mažai žinomų ASP.NET 4.0 ScriptManager galimybių.

Klausimas #1

Aš noriu registruoti savo JavaScript failus ScriptManager pagalba (nes taip atsiranda Visual Studio IntelliSense), bet nenoriu naudotis ASP.NET AJAX biblioteka.

Atsakymas

ASP.NET 4.0 ScriptManager atsirado nauja savybė AjaxFrameworkMode, kuriai užtenka priskirti reikšmę Disabled ir ASP.NET AJAX biblioteka nebebus naudojama.

Klausimas #2

Atjungus ASP.NET AJAX biblioteką AjaxFrameworkMode savybės pagalba nustojo veikti UpdatePanel. Aš noriu pakrauti tik UpdatePanel reikalingą AJAX bibliotekos dalį.

Atsakymas

ScriptManager AjaxFrameworkMode savybė turi dar vieną galimą reikšmę – Explicit, kas reiškia mes patys nurodysime mums reikalingus ASP.NET AJAX bibliotekos skriptus. Pradedant nuo ASP.NET 4.0 šalia MicrosoftAjax.js failo atsirado ir atskiros jo dalys:

• MicrosoftAjaxCore.js
• MicrosoftAjaxComponentModel.js
• MicrosoftAjaxNetwork.js
• MicrosoftAjaxWebServices.js
• MicrosoftAjaxSerialization.js
• MicrosoftAjaxHistory.js
• MicrosoftAjaxGlobalization.js

Mano bandymai parodė, kad norint pasinaudoti UpdatePanel galimybėmis reikia ne tik pakrauti MicrosoftAjaxWebForms.js, bet ir praktiškai visus MicrosoftAjax*.js failus:

Klausimas #3

Microsoft nesenai anonsavo nuosavą CDN (Content Delivery Network). Kaip ir rekomenduoja gerosios praktikos, aš noriu krauti ASP.NET AJAX ir kitų Microsoft komponentų skriptus iš CDN.

Atsakymas

Tiek visa ASP.NET AJAX biblioteka, tiek System.Web.dll ir System.Web.Extensions.dll JavaScript skriptai yra prieinami Microsoft CDN. Tam kad pasinaudoti šia galimybe, ASP.NET 4.0 ScriptManager reikia nurodyti EnableCdn="true". Kadangi tai apima ir System.Web.dll esančius JavaScript, tai Web formų (WebForms.js), klientinio validavimo (WebUIValidation.js), GridView (GridView.js) bei kitų komponentų JavaScript failai irgi bus kraunami iš CDN:

Klausimas #4

Pastebėjau, kad mano puslapyje naudojami Microsoft skriptai su galūne *.debug.js, bet aš noriu suspaustų skriptų versijų.

Atsakymas

Tokia galimybė egzistuoja nuo ASP.NET 3.5 SP1, bet vis dar didžioji dalis žmonių apie ją nelabai žino. ScriptManager pagal Web.config faile nurodytą parametrą <compilation debug="true|false" /> nustato kokią skriptų versiją rodyti: skirtą derinimui (*debug.js) ar suspaustą (*.js). Taip pat šis nustatymas gali būti kontroliuojamas ir pačiame ScriptManager ScriptMode savybės pagalba. Kas svarbiausia, tai galioja ir mūsų JavaScript failams – užtenka turėti, pavyzdžiui, common.js (suspaustą) ir common.debug.js (skirtą derinimui):

Noriu atkreipti dėmesį, kad čia svarbi yra savybė ScriptMode="Inherit", kuri nusako, kad derinimo metu turi būti pridedama galūnė *.debug.js.

Tiek šiam kartui, tikiuosi pirma dalis jus sudomino. Antroje dalyje aš aprašysiu kaip galima nurodyti ScriptManager, kad JavaScript failų versijos skirtos derinimui baigiasi *. js, o suspausti failai – *.min.js. Taip pat aptarsiu kaip galima prijungti kitas JavaScript bibliotekas talpinamas CDN.

Pagaliau pasirodė antroji ASP.NET MVC 2 Preview versija. Šią versiją asmeniškai aš laukiau dėl kelių pagrindinių naujovių, kurias pabandysiu trumpai aprašyti.

Pagal nutylėjimą pirmoji Preview versija modelio validavimui naudojo DataAnnotations mechanizmą ir nebuvo jokio būdo panaudoti kitą validavimo biblioteką (pvz., NHibernate Validator arba Validation Application Block). Antroje Preview versijoje atsiranda klasės ModelMetadata, ModelMetadataProvider ir ModelValidatorProvider, leidžiančios pasirašyti reikalingus adapterius.

Kita svarbi naujovė - automatinis klientinės dalies validavimas. Dabar pagal DataAnnotations atributus bus generuojamas visas jQuery Validation bibliotekai reikalingas kodas. Šiuo metu automatinis klientinės dalies validavimas vyksta pagal tokius atributus:

• StringLengthAttribute
• RequiredAttribute
• RegexAttribute
• RangeAttribute

Naujoje versijoje tapo žymiai paprasčiau nurodyti HTTP metodo panaudojimą, pvz., vietoje AcceptVerbs(HttpVerbs.Get) atributo užtenka tiesiog panaudoti atributą HttpGet. Dabar prieinami tokie atributai:

• HttpPostAttribute
• HttpPutAttribute
• HttpGetAttribute
• HttpDeleteAttribute

Paskutinė svarbi naujovė - projekto sritys (Project Areas). Pirmoje Preview versijoje galima buvo sukurti tik vieną projekto sritį viename projekte, dabar šis apribojimas yra panaikintas ir viename projekte gali būti kelios sritys. Pagrindinis jų panaudojimo būdas - loginis ASP.NET MVC kodo grupavimas, pvz., administravimo sritis, anoniminių vartotojų sritis, registruotų vartotojų sritis ir pan.

Tiek trumpai apie ASP.NET MVC 2 Preview 2 naujoves ir gero naudojimosi!

Tikriausiai nemažai iš jūsų jau matėte, kad prieš kelias dienas oficialiai buvo pristatyta antroji ASP.NET MVC versija. Šiandien CodePlex puslapyje pasirodė daugelių lauktas programinis kodas.

Priminsiu, planuojama kad ASP.NET MVC 2 įeis į Visual Studio 2010 ir .NET Framework 4.0.

P.S. Nuo savęs noriu pridurti, kad mane labai džiugina tas tempas, su kuriuo yra vystomas ASP.NET MVC.

Po tam tikros pertraukos atsinaujino daugeliui gerai žinomas Microsoft AJAX Control Toolkit. Šioje versijoje ne tik ištaisytos klaidos, bet ir pridėti 3 nauji komponentai:

• HTML redaktorius
  


• ComboBox elementas
  


• Spalvos pasirinkimo elementas
  

Nežinau kaip jus, o aš praktiškai pilnai perėjau prie jQuery :)

Tikriausiai nemažai jūsų esate susidūrę su ASP.NET puslapių kūrimu keliomis kalbomis. Laimei, tai padaryti nėra sunku. Priminsiu, norint kad Web puslapis palaikytų lietuvių ir anglų kalbas, užtenka aprašyti atitinkamus resursų failus (pavyzdžiui, Global.resx ir Globa.en-US.resx). Vertimai iš antrojo failo bus naudojami tik esant EN-US kalbai, o iš pirmojo – visais kitais atvejais.

ASP.NET puslapyje vietoje konkretaus teksto galima rašyti $Resources arba GetGlobalResourceObject / GetLocalResourceObject. Einamosios kalbos keitimą aš realizuosiu spaudžiant ant atitinkamų mygtukų:

C# pusėje apdorojamas einamos kalbos pakeitimas, o pasirinkta kalba išsaugome sesijoje:

Kam aš visą tai rašau? Praeitą savaitę darbe reikėjo realizuoti panašų mechanizmą, bet skirtą ne ASPX puslapiams, o JavaScript failams. Sprendimas ties kuriuo apsistojau yra pakankamai paprastas, bet tuo pačiu metu ir galingas.

Pirma reikia sukurti du JavaScript failus, skirtus saugoti lietuviškus ir angliškus pranešimus:

Tada reikia pridėti nuorodas į aprašytus failus atitinkamai į Global.resx ir Global.en-US.resx:

Tokiu būdu, pats ASP.NET lokalizacijos mechanizmas mums grąžins teisingą kelią iki JavaScript resursų failo, kurį mes registruojame mūsų puslapyje:

Tai leido panaudoti mano aprašytą JavaScript objektą Resources tiesiog alert funkcijoje. Paprasta ir patogu! Dar vienas svarbus aspektas - Resources objektas prieinamas ir kituose JavaScript failuose. O ką jus manote apie tokį JavaScript lokalizacijos būdą?

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!

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į!

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ą: