BLOGas.lt
Sukurk savo BLOGą Kitas atsitiktinis BLOGas

Greitas ASP.NET Web platformos komponentų instaliavimas

Parašė Sergejus | 2009-01-31 20:48

Kaip vyksta tipinis ASP.NET Web platformos instaliavimas naujame serveryje?



  • Instaliuojame reikalingus IIS komponentus

  • Instaliuojame naujausią .NET Framework versiją

  • Instaliuojame SQL Serverį

Visą tai galima žymiai supaprastinti naudojant naują Microsoft Web Platform Installer.



Kaip matyti, galima pasirinkti kokius konkrečius IIS komponentus reikia instaliuoti arba pasirinkt vieną iš prieinamų profilių: ASP.NET, PHP, klasikinis ASP. Šalia IIS komponentų, galima suinstaliuoti naujausias .NET Framework, ASP.NET MVC, SQL Express, Visual Web Developer integruotos aplinkos bei Silverlight Tools for Visual Studio versijas:



Mano manymu, visai neblogas pagalbinis įrankis!

Rodyk draugams

ASP.NET MVC Release Candidate 1 išeities tekstai

Parašė Sergejus | 2009-01-29 01:04

Tikriausiai daugelis jūsų jau žinote, kad vakar buvo išleista ASP.NET MVC Release Candidate 1 versija. Tai yra pakankamai svarbus įvykis tuo, kad nuo šiol ASP.NET MVC karkaso API praktiškai nesikeis, todėl mes galime jau pereidinėti prie verslo aplikacijų kūrimo su ASP.NET MVC. Šiandien gi pasirodė ir karkaso išeities tekstai, kurių aš laukiau labiausiai.



Taigi šiam momentui mes jau turime:



Rodyk draugams

IEnumerable praplėtimo metodas ToExcel savo rankomis

Parašė Sergejus | 2009-01-28 02:11

Šiandien galvojau apie galimybę paprastai ir greitai eksportuoti IEnumerable objektų sekas tiesiai į Excel failą. Pagrindinis noras buvo parašyti kuo paprastesnį praplėtimo metodą ToExcel, kuris tenkintu pagrindinius šiam momentui reikalavimus. Anksčiau aš nemažai naudojau trečių šalių eksporto bibliotekas, bet norėjosi kažko lengvo, be išorinių priklausomybių ir kad veiktų su Excel  2003 ir naujesnėmis versijomis.


Kadangi yra suderinamumo su Excel 2003 reikalavimas – OOXML SDK automatiškai atkrenta. Staiga aš prisimyniau, kad nuo Excel 2003 (ir vėliau nuo Excel 2000 su SP3) atsirado galimybė išsaugoti Office dokumentus XML formatu. Jeigu trumpai, tarkime mes turime tokią Excel lentelę:



Ją galime išsaugoti kaip Excel XML failą:



Atidarę XML failą redagavimui – matome, kad tai yra gana paprastas XML failas:



Minimaliai jį panagrinėjęs, nusprendžiau pats realizuoti praplėtimo metodą. Pradėjau nuo pagalbinės klasės HeaderCell:



Remiantis išnagrinėta Excel XML dokumento struktūra, sudariau minimalius dokumento griaučius:



Abi konstantas vėliau naudosiu String.Format metode, tam kad pakeisti {0} į reikalingas reikšmes. Viešai pasiekiamu aprašiau vienintelį metodą ToExcel:



Logika yra pakankamai paprasta: jeigu stulpelių pavadinimai nėra perduoti – aš juos sukuriu pagal perduotos esybės savybes. Toliau yra kviečiamas metodas GetExcelWorksheet:



GetExcelWorksheet naudoja du pagalbinius metodus GetExcelHeader ir GetExcelRow, kurie savo ruožtu kviečia GetExcelColumn, GetExcelHeaderCell ir GetExcelRowCell:



Matyti, kad nurodant Excel celės duomenų tipą, tenka vietomis jį modifikuoti. Tam aš aprašiau du pagalvinius praplėtimo metodus ToExcelShortDate ir ToExcelDecimalNumber:



Tiek! Du šimtai eilučių ir galite eksportuoti į Excel bet kokias esybes. Be abejo šį realizacija neapima visų galimų atvejų, bet kaip sako TDD – metodas turi daryti nedaugiau negu reikia konkrečiu metu, o kol kas man daugiau ir nereikia.


Aprašyto praplėtimo metodo ToExcel panaudojimas galėtų atrodyti taip:



Kur rezultate mes gausime visai tvarkingą Excel failą:



Klasės išeities tekstai prieinami čia.


UPD


Kaip buvo teisingai pastebėta komentaruose, duomenys nebuvo sutvarkomi, kad atitiktų XML formatą. Tam galima tiesiog prie case “System.String” eilutės prirašyti vietoje value - SecurityElement.Escape(value).

Rodyk draugams

Išleista Internet Explorer 8 Release Candidate 1!

Parašė Sergejus | 2009-01-27 00:42

Įvyko! Ką tik pagaliau pasirodė Internet Explorer 8 RC1 versija…

Rodyk draugams

asp:RegularExpressionValidator lietuvybės problemos

Parašė Sergejus | 2009-01-26 01:36

Vienam klientui iškilo problema, apie kurią aš niekad nebūčiau pagalvojęs. Tarkime, turime tokį reguliarių išraiškų validatorių:




asp:RegularExpressionValidator runat=”server” ControlToValidate=”Code” Text=”!” ValidationExpression=”[A-Z]{2}\d{2}” ErrorMessage=”Įveskite korektišką kodą”


Validatorius turi patikrinti, ar įvestas korektiškas kodas: dvi raidės ir du skaičiai. Problema yra tame, kad toks validatorius neapima lietuviškų raidžių, t.y. kodas AŽ02 bus traktuojamas nekorektišku. Išeitis - išreikštinai išvardinti lietuviškas raides:




asp:RegularExpressionValidator runat=”server” ControlToValidate=”Code” Text=”!” ValidationExpression=”[A-ZĄČĘĖĮŠŲŪŽ]{2}\d{2}” ErrorMessage=”Įveskite korektišką kodą”


Brrr… nesąmonė. Kiek skaičiau, kuriant RegEx objektą iš C# įmanoma nurodyti, kad būtų naudojamas Unicode, bet RegularExpressionValidator to nepalaiko. Gal jums irgi teko su tuo susidurti ir turite geresnį sprendimą?


Rodyk draugams

Naujos ASP.NET 4.0 galimybės - 2 dalis

Parašė Sergejus | 2009-01-23 02:10

Pagaliau susiruošiau parašyti antrą ASP.NET 4.0 naujų galimybių apžvalgos dalį. Šį kartą aš aprašysiu mažą, bet be galo svarbų patobulinimą – komponentų ID generavimo valdymą.


Kaip žinia, pagrindinės problemos kuriant šiuolaikiškas ASP.NET aplikacijas yra generuojami ID ir ViewState. Kadangi ID generavimo iki šiol valdyti buvo praktiškai neįmanoma, tai tekdavo dirbti su „ctl0_body_txtName“ tipo komponentų ID. Laimei, ASP.NET 4.0 atsiranda galimybė išreikštinai nusakyti komponento ID (kas žymiai palengvina darbą iš JavaScript pusės).


Šiame pavyzdyje aš naudosiu tokį MasterPage failą:



Ir tokį turinio puslapį:



Nesunku įsivaizduoti, kaip atrodys sugeneruotas HTML kodas:



Kaip matyti, visi komponentai prasideda prefiksu ctl00_body. Taip yra dėl to, kad ctl00 nurodo priklausomybę MasterPage failui, o body – tai ContentPlaceHolder komponento pavadinimas. Akivaizdu, kad su tokiais ID yra labai nepatogu dirbti iš JavaScript. ASP.NET 4.0 prie visų serverinių komponentų atsiranda savybė ClientIDMode, kuri leidžia nurodyti ID generavimo strategiją. Visas prieinamas opcijas aš aptarsiu vėliau, o kol kas verta žinoti, kad jeigu mes nurodysime ClientIDMode=Static, tai komponentų ID bus generuojami tokie kaip nurodyti ASPX faile.



Jeigu prie kiekvieno aukščiau išvardinto komponento nurodysime ClientIDMode=Static, sugeneruotas kodas atrodys taip:



Matote? HTML komponentų ID sutampa su ID nurodytais ASPX faile. Tikriausiai kyla natūralus klausimas – kodėl name atributas nepasikeitė. Esmė tame, kad ASPX PostBack, ViewState ir kitoms operacijoms naudoja ne komponentų ID, bet name atributus. Tai reiškia, kad galima pakeisti komponentų ID visiškai neįtakojant egzistuojančio ASPX funkcionalumo (ir kodėl tai anksčiau nebuvo padaryta?).


Taigi ClientIDMode – tai mūsų išgelbėjimas, bet ar galima jį naudoti pagal nutylėjimą, o nenurodinėti prie kiekvieno komponento? Atsakymas – taip, ir net keliuose vietose. Pirma jus galite nurodyti kokia ID generavimo strategija bus naudojame visama puslapyje:



Lygiai taip pat galima nurodyti ClientIDMode ir MaterPage faile. Jeigu norite nurodyti ID generavimo strategiją visai Web aplikacijai, tai galite padaryti Web.config faile:



Šiam momentui mes aptarėme ClientIDMode panaudojimo vietas ir galime grįžti prie jo opcijų. Iš viso yra keturios ID generavimo strategijos:



  • Legacy (naudojama pagal nutylėjimą) – senoji ASP.NET ID generavimo strategija;

  • Inherit – eina aukštyn komponentų hierarchija ir ieško pirmo išreikštinio ClientIDMode nustatymo, jeigu neranda prie komponentų – ieško Web.config faile ir jeigu ten nėra – naudoja Legacy;

  • Static – nurodo statinį komponento ID;

  • Predictable – Static netinka ListView ir GridView komponentuose, nes šiuo atveju kiekviena eilutė turės tą patį ID, todėl Predictable kiekvienos eilutės komponento ID prideda numeravimą.

Išnagrinėkime įdomesnį pavyzdį su ListView komponentu. Tarkime, turime tokį ASPX puslapį:



Sugeneruotas HTML kodas atrodys taip:



Pabandykime ListView komponentui nurodyti naudoti statinį ID:



Rezultatas gali mus nuvilti:



Matome, kad Static yra naudojamas tiek ListView komponente, tiek ir jo viduje esančiame Label. Norėdami padaryti DIV konteinerio elementų ID unikalius, bet tuo pačiu išlaikyti pirminį grožį – panaudokime ClientIDMode=Predictable:



Ir gauname žymiai geresnį rezultatą:



Paskutinis štrichas: dažnai patogu ListView ir GridView komponentuose naudoti ne atsitiktinį numeravimą, bet pririštą prie ID. ASP.NET 4.0 leidžia pasiekti ir tai RowClientIDSuffix pagalba:



Rezultate turime neįprastai grąžų ASP.NET puslapiams HTML kodą:



Tiek, kas liečia komponentų ID generavimo naujame ASP.NET 4.0. Tikiuosi, jus laukiate šitos galimybės taip pat kaip laukiu jos aš ir kaip visada labai laukiu jūsų komentarų!

Rodyk draugams

Software + Services vaizdžiai

Parašė Sergejus | 2009-01-19 19:42

Tikriausiai nemažai iš jūsų esate girdėję terminą Software as a Service (SaaS). O kas žinote kuom Microsoft Software + Services (S+S) skiriasi nuo SaaS? Žemiau pabandyta tai parodyti bei paaiškinti vaizdžiai:


Rodyk draugams

Asinchroninis validavimas jQuery ir CustomValidator pagalba

Parašė Sergejus | 2009-01-17 15:25

Kaip ir žadėjau praeitoje dalyje, šį kartą parodysiu kaip asinchroniškai validuoti duomenis jQuery ir CustomValidator komponento pagalba.


Iš praeitos dalies lieka nepakitę servisų metodas GetCategoryByName ir puslapio metodai HandleCallback, SendJson bei CategoryExists. Kadangi CustomValidator apibrėžia tiek klientinės pusės validavimą, tiek serverinės – mums reikės C# metodo ValidateCategory:



ASP.NET puslapio kodas irgi nedaug keičiasi nuo to kas buvo:



Kaip matyti, prisėdėjo CustomValidator komponentas ir mygtukas Saugoti. Serverinėje pusėje CustomValidator turi kviesti C# metodą ValidateCategory, o klientinėje pusėje – validateCategory.


Deja, bet klientinės pusės validatorius nemoka laukti, kol asinchroninė funkcija grąžins validavimo rezultatą. Kintamajam args.IsValid reikšmę būtina priskirti iš karto validavimo funkcijos kvietimo metu. Kas esate kūrę klientinės pusės validatorius žinote, kad funkcija kviečiama mažiausiai du kartus: kai laukelis praranda fokusą bei kai daromas HTTP Submit (mūsų atvejų tai saugojimas). Po tam tikro galvojimo ir tikrinimo, man atrodo radau išeitį. Reikia apibrėžti laikiną kintamąjį (kaip isCategoryValid), kuris ir saugos paskutinio validavimo rezultatą. Taip, kada kategorijos laukelis praras fokusą, args.IsValid įgaus isCategoryValid reikšmę (kuri yra true pagal nutylėjimą). Tada bus kviečiama mūsų asinchroninė funkcija, kuri ir priskirs isCategoryValid tikrąjį rezultatą. Bandant išsaugoti duomenis, kaip aš jau ir minėjau, dar kartą bus kviečiama validateCategory funkciją, kuri šį kartą gražins jau tikrąją reikšmę. Šaunu!



Nors iš funkcionalumo pusės viskas veikia visai neblogai, iš vartotojo patyrimo pusės būtų naudingiau pranešti apie klaidą iš karto kai laukelis praranda fokusą, o ne laukti mygtuko Saugoti paspaudimo. Aš išnagrinėjau ASP.NET klientinės pusės validavimo karkaso išeities tekstus ir radau keletą įdomių dalykų, kurie gali mums pagelbėti. Pirma kiekvienas validatorius turi savybę isvalid, kuri saugo jo būseną. Antra egzistuoja funkcija ValidatorUpdateDisplay, kuri moka atnaujinti validavimo pranešimą priklausomai nuo validatoriaus būsenos. Galutinis kodas atrodytų taip:



Tokiu būdu, kai tik laukelis praranda fokusą ir mes žinome validavimo rezultatą, galima atitinkamai atnaujinti ir validatoriaus pranešimą (t.y. arba jį rodyti, arba slėpti). Valio!


Kaip visada, labai laukiu jūsų komentarų, pastabų bei pasiūlymų…

Rodyk draugams

Šiandien išleista jQuery 1.3 versija!

Parašė Sergejus | 2009-01-14 20:49

Valio! Šiandien buvo išleista naujoji jQuery versija. Pagrindinis 1.3 versijos akcentas - greitaveika. Daugiau informacijos oficialiame puslapyje.

Rodyk draugams

Asinchroninis validavimas jQuery pagalba

Parašė Sergejus | 2009-01-14 01:26

Įsivaizduokite situaciją: turime klasifikatorių, pavyzdžiui, kategorijas. Kaip ir būdinga klasifikatoriams, kategorijos pavadinimas turi būti unikalus (t.y. turi būti neįmanoma įvesti dvi kategorijas tuo pačiu vardu). Viena programuotojų dalis tai sprendžia duomenų bazėje aprašant lauką kaip unikalų ir paskui bando gaudyti unikalumo klaidas. Kita programuotojų dalis aprašo CustomValidator komponentą ir vykdo tikrinimą serverinėje pusėje. Toks variantas man patinka labiau negu pirmasis, bet sutikit, iš vartoto patyrimo (angl. exprerience) pusės tai nėra geriausias sprendimas. Šiandien aš parodysiu paprasčiausią atvejį, kaip iš JavaScript galima tikrinti reikšmes naudojant serverinį metodą. Kitoje dalyje aš pratęsiu pavyzdį ir realizuosiu pilnai funkcionuojantį asinchroninį CustomValidator komponentą. Bet apie viską iš eilės…


Kategorijos egzistavimui tikrinti mums reikės servisų metodo:



ASPX kode mes tik turime vieną kategorijų įvedimo laukelį, validatoriaus analogą bei JavaScript funkciją:



Atkreipkite dėmesį į JavaScript kodą. Aš naudoju jQuery getJSON funkciją serverinio metodo CategoryExists iškvietimui. Kaip šios funkcijos argumentą aš perduodu kategorijos pavadinimą, o kaip rezultatą gaunu bool tipo reikšmę (egzistuoja arba ne). Pagal gautą reikšmę aš arba parodau raudona šauktuką, arba jį paslepiu.


C# pusėje aš turiu jau nekartą naudotus HandleCallback ir SendJson metodus bei CategoryExists metodą atsakingą už validavimą:



Kaip matyti, CategoryExists metodas yra trivialus, bet HandleCallback dabar žymiai sudėtingesnis. Jeigu atsimenate, anksčiau aš pats tikrinau reikalingus parametrus ir konvertavau juos į atitinkamą tipą. Supratau, kad tai nėra nei efektyvu, nei patogu, todėl parašiau sumanų HandleCallback metodą. Jis ieško nurodyto metodo argumentus Request.Params kolekcijoje ir automatiškai konvertuoja reikšmes į atitinkamą tipą. Konvertavimui aš naudoju prieš kurį laiką aprašytą savo universalų ConvertTo metodą:



Taigi taip lengvai ir paprastai dabar galima iškviesti serverinį metodą iš klientinės pusės! Kitoje dalyje parodysiu kaip tokią techniką galima panaudoti aprašant asinchroninį CustomValidator komponentą.


P.S. ConvertTo metodo kodą patalpinau čia.

Rodyk draugams