Oktató Portál teljes forráskódja elérhető…

Ma délelőtt, sikeresen feltöltöttem az ASP.NET Mindenkinek Portál teljes forráskódját a CodePlex-re.

SQL Server 2000 illetve SQL Server 2005 kompatiblis az alkalmazás, így bárki kipróbálhatja otthon a mellékelt példa adatbázisokkal.

 

A web project illetve a példaadatbázisok letölthetőek az alábbi címről:
http://www.codeplex.com/trainerportal/
/itt válasszátok a Release fület/

 

A portál célja bemutatni az ASP.NET 2.0 illetve az AJAX használtát a gyakorlatban.

 

A portál működés közben is megtekinthető az msiskola.jedlik.hu/aspnet cím alatt!

(az első oldal generálás kicsit lassú, ez a sávszél hibája is, de már dolgozunk az ügyön!)

---

Egy vélemény a codeplex-ről

Az első benyomásom a codeplex oldalról először pozitív volt, sajnos most már nem annyira. Én tényleg jó 5letnek tartom, hogy meg lehet osztani projekteket és végre a Microsoft is rájött arra, hogy az Open Source jó dolog. 
Viszont magával a codeplex oldal-lal elégedtelen vagyok.
– A jelszó emlékeztető rendszer nem működik
– Új projekt indítását megtalálni nem egyszerű dolog, nekem 15 percbe telett, mert annyira nem feltűnő helyen van.
– A project leírásban a szöveget nem lehet formázni
– Más helyeken a szövegek formázása eléggé maceráns, nem a megszokott php-s [b] illetve [i] formula, hanem * meg _ illetve egyéb idító jelek használtára köteleznek…
– A fájl feltöltés is eléggé érdekes
– A projektnek kétfajta release állapota: planned (tervezett), illetve release (kiadott). Kiadottra csak úgy lehet váltani, ha megadjuk a kiadás dátumát, amit szerintem lehetetlen teljesíteni. Ha a mellete lévő calander-t használjuk, akkor a lokalizáció miatt, nem az angol formába írja ki a dátumot, ami úgyebár nem felel meg a sémának, így nem lehet releaselni. Ha kézzel beírom a specifikációnak megfelelő (mm/dd/yyyy) dátumot, akkor szintén nem történtik semmi..
– Még mindig nem sikerült arra rájönnöm, hogy hogyan lehet megadni a tag-eket, vagyis, hogy milyen csoportba tartozzon a project.

– Van egy úgynevezett wiki rendszer, ami igazándiból egy napló, ami rögzíti mit is csináltunk a project weboldalán. Szerintem ezt nem kénne mások számára is publikussá tenni…

Az egyetlen igazi pozitív dolog, amit feltudok mellette hozni: az rövid url címek használta. Vagyis a QueryString-es ?id=… helyett projektnév alapján lehet navigálni a weboldalon. (ezt iis-ben kell beállítani, és tényleg jó dolog)

Szerintem még egy jó pár órát rá kell szánnom a codeplex megismerésére, de az biztos, hogy nem fogom megszeretni 

AJAX Control Toolkit III. – AlwaysVisibleControlExtender

AJAX Control Toolkit –
AlwaysVisibleControlExtender

 

Ez egy példaalkalmazáshoz tartozó leírás! Az alkalmazás erről a címről tölthető el:

http://www.devportal.hu/portal/Detailed.aspx?NewsId=32a886da-0e5b-48e4-80b8-06fa6cb6d1cb vagy

http://cid-8dcaf3b0da4fb828.skydrive.live.com/embedrowdetail.aspx/ACTsorozat/ACT|_III|_AlwaysVisibleControlExtender.zip

Ezen a héten az AlwaysVisibleControlExtender-ről, illetve általánosságban az Extender-ről lesz szó! Vágjunk is bele!

 

Extender alapok
Az extender-ekhez az egyik alap 5letet a custom control adta, ezen belül is az, amikor egy meglévő vezérlőből származtatjuk az új egyedi vezérlőnket, nem pedig az absztrakt Control ősosztályból. Ha valamilyen plusz funkcionalitást szeretnénk adni pl.: mondjuk a textbox-hoz, hogy csak numerikus karaktereket lehessen bevenni a beviteli mezőbe, akkor ehhez a feladathoz létre kellett hoznunk egy új vezérlőt, ami sok idő és + erőforrás.
Az Extender vezérlők egy teljesen új elgondolásnak köszönhetően sokkal hatékonyabb fejlesztést eredményeznek. A kiterjesztők egy úgynevezett behavior objektum segítségével megváltoztatják a vezérlő alatt lévő DOM-ot (Document Object Model) és kliens oldali eseményekre regisztrálnak fel. (emlékezzünk vissza, a behavior a kliens oldali logikáért felelős, míg az extender egy szerver oldali vezérlő!) Fontos azt is látnunk, hogy ettől még a programozói interfésze nem változik meg a kiterjesztett vezérlőnek.
Azt is érdemes észrevenni, hogy az Extenderek sokban hasonlítanak a DHTML-re. A nagy különbség csupán annyi, hogy míg a Dynamic HTML egy HTML tag viselkedését, kinézetét változtatja meg, addig az Extender egy markup blokkot bővíti ki, amit egy ASP.NET vezérlő generált.
Az igazi nagy előnye az extender-eknek az, hogy általában nem csak egyféle vezérlő típust támogatnak, hanem többet is. Ezzel megspóroljuk azt a sok plusz munkát, hogy minden egyes kiterjesztendő vezérlőből készítünk egy-egy szuper vezérlőt.
(Az extender-ök használnak kliens oldali kódot is, így ahhoz ezek helyesen működjenek, szükségük van az AJAX Framework-re és az AJAX Extensions-szel együtt települő ScriptManager-re!)

 

Az extender vezérlők mindegyike az úgynevezett ExtenderControl osztályból van származtatva, mely tartalmazza a közös tulajdonságokat is, pl.: Enabled, TargetControlID. Az utóbbi tulajdonság egy string-et vár értékül, mely az azonosítója a kiterjesztendő vezérlőnek, tehát például: TextBox1.

 

Így már van egy körülbelüli képünk arról, mik is azok az Extender-ek és hogyan is működnek.

 

Extender csoportok
Az extender vezérlőket, aszerint szokás csoportosítani, hogy milyen típusú vezérlőket képesek kibővíteni. Ezek alapján az alábbi osztályokat különböztetjük meg:
– Panel Extenders: CollapsiblePanelExtender, DragPanelExtender, DropDownExtender
– Button Extenders: ConfirmButtonExtender, MutuallyExclusiveCheckBoxExtender, ToggleButtonExtender
– Pop-up Extenders: HoverMenuExtender, ModulPopupExtender, PopupControlExtender
– User-Interface Extenders: AlwaysVisibleControlExtender, CascadingDropDownExtender, DropShadowExtender, DynamicPopulateExtender, PagingBulletedListExtender, ResizableControlExtender, RoundedCornersExtender

– Input Extenders: AutoCompleteExtender, CalendarExtender, FilteredTextBoxExtender, MaskedEditExtender, NoBotExtender, NumericUpDownExtender, PasswordStrengthExtender, SliderExtender, TextBoxWatermarkExtender, ValidatorCalloutExtender
– Animation Extenders: AnimationExtender, UpdatePanelAnimationExtender

 

Én nem mindenhol értek teljesen egyet ezzel az osztályozással (pl.: a MutuallyExclusiveCheckBoxExtender-nek semmi köze a gombok; a RoundedCornersExtender panel típusú /ebbe beletartozik még a webpart is, legjobb tudomásom szerint/ vezérlőkhöz lett kitalálva, stb.), de ez senkit se zavarjon, ez csak olyan elméleti csoportosítás, vagyis kódszinten nincsen ilyesfajta megkülönböztetés a kiterjesztők között.    

 

AlwaysVisibleControlExtender használata
Mint ahogy a fentebbi csoportosításból is látszik az AlwaysVisibleControlExtender egy felhasználói-felület változtató extender. Gondolom már mindenkivel megtörtént, hogy amikor egy hosszú weboldalt lefelé görgetett, akkor a scrollozást követette a képernyőn egy panel. Vagyis mindig látszott a panel. Ezek általában baromi idegesítők tudnak lenni, hiszen sokszor olyan részre csúsznak rá, amelyet el szeretnénk érni. Nem is beszélve arról, hogy ezek általában reklámot tartalmaznak.
Azért létezik értelmes felhasználásuk, bár nem túl gyakori. Tegyük fel, hogy az oldalunk tartalmi része csak a 80%-át foglalja el a képernyőnek  Így a maradék 20%-ban tud szabadon „mozogni” az ACVE panel, anélkül, hogy különösebb gondot okoznak. A tartalomnak, pedig nem feltétlenül kell reklámnak lennie, lehet kezelési útmutató (short keys), határidő figyelmeztetés, vagy akár szavazógép, stb..

 

Nézzük, hogyan is történik az ACVE használata a gyakorlatban!
Itt szerencsénkre van már design módú támogatás, amelyet ki is fogunk használni. Tehát design nézetben húzzunk a forumnak egy AlwaysVisibleControlExtender-t. Egy panel-t szeretnénk megjeleníteni mindig a képernyő jobb felső sarkában. Így adjunk egy panel-t az oldalhoz. Fontos, hogy csak a tartalmát adjuk meg, (illetve formázzuk meg), esetleg a kinézetét szabjuk testre, de az elhelyezkedését ne állítsuk be, azt majd az AVCE-vel tesszük!
Állítsuk be az AVCE TargetControlId-ját a panelünk id-jára:

A dropdownlist-ben megjelenő vezérlőlistán lenne még mit javítaniuk az ACT fejlesztőinek, hiszen olyan vezérlőket is felajánl, mint például a ScriptManager.
Ezek után, válasszuk ki az av_panel-t, majd F4. Megjelent a tulajdonság ablakában egy új csoport, avce(AlwaysVisibleControlExtender) néven. Nyissuk ki:

A BehaviorID az Extender azonosítóját szabja meg.
A HorizontalSide a vízszintes elhelyezkedését állítja be a Panel-nek, ami lehet jobbra, középre illetve balra zárt (right, center, left).
A VerticalSide tulajdonság értelemszerűen a vertikális, függőleges helyzetet szabja meg, ami lehet fent, lent vagy középen (top, bottom, middle).
A HorizontalOffset a pixelekben megadott távolság a böngésző adott széle és a panel között. Ez alapértelmezés szerint 10px.
A VerticalOffset hasonlóan a böngésző szélétől való távolságot állítja be, pl.: ha a VerticalSide=Top, akkor a böngésző menüsorától 10px-lel lesz lejjebb a panel teteje.
Végül a ScrollEffectDuration tulajdonság segítségével azt tudjuk szabályozni, hogy a panel hány másodperc alatt tegye meg azt az utat, hogy szinkronban legyen a scroll mozgásával. Az alapértelmezett érték a .1.

 

Adjunk valami hosszú szöveget az oldalunkhoz, állítsuk a szöveg szélességét 80%-ra, majd futassuk!

 

Érdekesség CodeBehind-ban!
Tegyük fel, hogy dinamikusan szeretnénk állítani a panelünk elhelyezkedését. Amikor a codebehind fájlban beírjuk az av_panel. -ot, majd sasoljuk az IntelliSence-t, akkor láthatjuk, hogy nincsen se VerticalSide, se HorizontalOffset, stb. tulajdonság. Akkor még is hol keressük őket?
A válasz: az Exentder-nél. Az exentder-en keresztül a behavior paramétereit állítjuk be, majd ezt ragasztjuk rá a vezérlőnkre. Ha megnézzük a markup fájlunk source nézetét, ott is látni fogjuk, hogy az AVCE attribútumai lesznek a fentebb felsorolt tulajdonságok. Magyarul az csak egy design módbeli feature, hogy a kiterjesztendő vezérlő tulajdonságainál tudjuk beállítani a behavior objektumot.
Visszatérve az extender programozására, így állíthatjuk át a vízszintes elhelyezkedést:

 

avce.HorizontalSide = AjaxControlToolkit.HorizontalSide.Right;
 
 

AJAX Control Toolkit II. – Accordion

AJAX Control Toolkit – Accordion

 

Ez egy példaalkalmazáshoz tartozó leírás! Az alkalmazás erről a címről tölthető el:

http://www.devportal.hu/portal/Detailed.aspx?NewsId=1e944e4b-9a04-4c4c-b853-48556f874e52 vagy

http://cid-8dcaf3b0da4fb828.skydrive.live.com/embedrowdetail.aspx/ACTsorozat/ACT|_II|_Accordion.zip

Ebben a cikkben az Accordion vezérlővel fogunk megismerkedni! Ígérem nem fog fájni!

 

Accordion alapok
Az Accordion vezérlőnek, ha szeretnénk valami szép magyar nevet adni, akkor a harmonika vezérlő lenne talán a legtalálóbb. Ezt a tényt az támassza alá a legjobban, hogy ha egy ASP.NET 2.0-ás vezérlővel szeretnénk párhuzamba állítani, akkor ez a vezérlő a MultiView lenne. Hiszen mindkettő ugyanazt a célt szolgálja, vagyis több előre definiált panel (nézet) között tudunk egyszerűen navigálni, egy oldalon, úgy hogy egyszerre mindig csak egy látható! Egyik másik közös vonás az , hogy mindketten a MultiView illetve az Accordion is, valójában csak Container vezérlők, vagyis ők a navigációért felelősek, a lényeg valójában a bennük lévő elemekben van: View illetve AccordionPane (lentebb bővebben).
Akkor mégis mi a különbség, vagy egy által minek kell még egy ilyen vezérlő?
A válasz egyszerű, azért mert ez AJAX enabled (tehát a navigációnál nem frissül a teljes oldal, hála a Java script-nek és az aszinkron oldalkérésnek), illetve praktikusabb/szebb, mivel minden panel fejléce egyszerre látható (ebben hasonlít egy kicsit a wizard-ra ), amelyeket animációval körítve ki lehet nyitni, illetve össze lehet csukni. Tehát egy CollapsiblePanel (későbbi cikkben) kombinálva egy MultiView-val, és kész is az Accordion.

 

Accordion használta
Az Accordion sajnos azon CT vezérlők közé tartozik, melyeket nem lehet design módban „beállítani”, vagyis muszáj a markup fájlban turkálnunk. Kezdjünk is hozzá!
Húzzunk bele, a markup fájl egy megfelelő helyére, egy Accordion vezérlőt. Ezek után az alábbi tulajdonságokat állítsuk be:

<ajaxToolkit:Accordion ID="SampleAccord" runat="server" SelectedIndex="0"
    HeaderCssClass="accordionHeader" ContentCssClass="accordionContent"
    FadeTransitions="false" FramesPerSecond="40" AutoSize="None"
    RequireOpenedPane="false" SuppressHeaderPostbacks="true">
</ajaxToolkit:Accordion>

 

Megjelenésre vonatkozó beállítások:
– A SelectedIndex attribútum értelemszerűen azt állítja be, melyik legyen az alapértelmezetten kiválasztott, azaz megjelenő, panelünk. Most ez a legelső panel lesz.
– A HeaderCssClass a panel, (amit innentől kezdve nevezzünk AccordioPane-nek), fejlécének a stílusát állítja be. /A kövi bekezdésnél, láthattunk erre egy példa css-t!/ Mi most az accordionHeader osztály használjuk.
– A ContentCssClass-ban megadott osztály, az AccordionPane-k content-jeinek (megjelenő szövegrész) formázásáért felelős.
– Az AutoSize segítségével azt tudjuk megszabni, hogy a vezérlőnövekedése automatikus legyen-e vagy sem. Valóban három lehetőség közül választhatunk a None, a Fill és a Limit közül. IE6 illetve IE7 alatt a Fill és a Limit ugyanazt eredményezi, mivel nem támogatják a max-height CSS tulajdonságot. FF alatt a kettő között a különbség az, hogy a Limit-nél nincs autoresize, így maximum a height tulajdonságban megadott teret töltheti csak ki, és ha túl lógna, akkor jelenik meg a scroll. Míg Fill esetén az Accordion mindig ugyanakkora helyet tölt ki (max Height). Pl.: content-500, accordion-700 magas. Fill esetén accordion 700px mindig, Limit esetén 500 + fejlécek magasságú!
Értelemszerűen a None pedig engedélyezi az autoresize-t, vagyis az alatta lévő vezérlőket lejjebb csúsztatja.
 
Viselkedéssel kapcsolatos beállítások:
– A FadeTransitions beállítás egy bináris értéket vár értékül, aszerint hogy szeretnénk-e fade effektet használni (tehát amikor összecsukjuk, vagy kinyitjuk valamelyik accordionpane-t, akkor szépen elhalványodjon, illetve előtűnjön a kiválasztott panel). Ha true-ra állítjuk, akkor lesz fade effect is, ha false-ra, akkor csak az alap animáció lesz pane váltáskor.
Mi erre most nem tartunk igényt, de ha mégis szükségünk lenne rá, akkor a TransitionDuration tulajdonságon keresztül tudjuk beállítani milliszekundumokban a fade effect időtartamát. Ezt általában 250-re szokás állítani!
– A FramePerSecond az fps-t szabja meg, vagyis hogy hány kép/másodperc frissítéssel hajtódjon végre az animáció. A neten található példákban, mindenhol 40 fps a standard, bár a szem 25 fps felett már folyamatosnak látja a képet.
– A RequireOpenedPane tulajdonsággal az Accordion két állapotát (egy van nyitva, egy sincs nyitva) le tudjuk csökkenteni egy állapotúra, mindig van egy nyitott Pane-re. Magyarul, ha a kinyitott Pane fejlécére kattintunk és ez a tulajdonság true értéket vesz fel, akkor nem tudjuk összecsukni!
– A SuppressHeaderPostbacks egy alternatíva arra, hogy hogyan kezeljük a fejlécben megadott hyperlinket (lentebb bővebben). A Hyperlink accessibility szempontból lényeges, hiszen így az oldalt felolvasó program tudja, hogy erre rá lehet kattintani. De mi nem szeretnénk teljes PostBack-et, ha valaki rákattint a fejlécre, ezért ezt a tulajdonságot állítsuk true-ra! Lentebb látható majd egy másik alternatíva is erre.

 

Ha ilyenkor átváltunk design módba, akkor egy 5*5 pixeles kis placeholder-t fogunk látni az oldalon. Ahhoz, hogy meg is jelenjen valami tartalom, menjünk vissza ismét source nézetbe.

 

AccordionPane
Nos, itt az ideje, hogy lelket leheljünk a vezérlőnkbe! Először létre kell hozunk egy Panes template contaiter tag-et az accordion-on belül. Ezen belül hozhatunk csak létre AccordionPane-ket, ha ezen kívülre kerülne véletlen egy Pane, akkor már design módban Render Error-t fogunk kapni.
Húzzunk három-négy AccordionPane vezérlőt a Panes tageken belül. Itt definiálnunk egy-egy Header illetve egy-egy Content részt. Nézzünk először a Header-re egy példát:

<Header><a href="" class="accordionLink">AJAX Extensions</a></Header>

 

A példából látszik, hogy egy hivatkozást helyezünk el a header szekción belül, amely blink, vagyis nincs megadva semmilyen url. Íme a másik alternatíva, arra hogy elkerüljük a PostBack-et: tehát az a tag-ünket egészítsük ki az alábbi kis Java Script kóddal:

onclick="return false;".

Most már csak a Content részeket kell megírnunk. Ide bármilyen HTML vagy ASP.NET markup kódot írhatunk, tehát teljesen ugyanúgy viselkedik, mint egy ContentPlaceHolder. Íme egy példa:

<Content><br/>
  <strong>ASP.NET AJAX Extensions</strong> – Ez egy olyan keretrendszer, mely segítségével készíthetünk és futatthatunk AJAX-típusú alkalmazásokat.
  A framework nem csak a szerver-centrikus fejlesztésben nyújt támogatást, hanem kliens-centrikusban is!</br>
<Content>

És ennyi, készen is vagyunk!

 

Két dolgot jegyeznék még meg:
1. Szerencsénkre ez a vezérlő is adat-köthető, így előszeretettel használjuk a DataSource, DataMember illetve DataSourceID tulajdonságokat.
2. Remélem a példaalkalmazás alapján, látszik mindenkinek, hogy ez nem EXTENDER, hanem Control, mivel ez egy önálló vezérlő, nem pedig egy meglévő funkcionalitását bővíti ki! Azok lesznek extender vezérlők, melyeknek a végén ’extender’ áll, a többi control!

 

Accordion-hoz tartozó sytlesheet beállítások – példa
Fontos, hogy a markup fájl head részében legyen egy hivatkozás a stylesheet fájlunkra. Íme egy példa:

<head runat="server">
  <title>Accordion példaalkalmazás</title>
  <link href="StyleSheet.css" rel="stylesheet" type="text/css"/>
</head>

 

Ezek után nézzük meg mi rejtőzik a StyleSheet stílusfájlba:

 

.accordionContent
{
    background-color: #f2f9fe;
    border: 1px dashed #2F4F4F;
    border-top: none;
    padding: 5px;
    padding-top: 10px;
    font-family: Verdana;
    font-size: small;
}
.accordionHeader
{
    border: 1px solid #2F4F4F;
    color: white;
    background: #f2f9fe url("Images/pattern.gif") repeat-x center center;
    font-family: Arial, Sans-Serif;
    font-size: small;
    font-weight: bold;
    padding: 2px;
    margin-top: 5px;
    cursor: pointer;
}
.accordionLink
{

    color:White;

}

 

AJAX Control Toolkit I. – Alapok

ASP.NET AJAX Control ToolKit – Alapok

 

Ez egy példaalkalmazáshoz tartozó leírás! Az alkalmazás erről a címről tölthető el:

http://devportal.hu/Portal/Detailed.aspx?NewsId=0f030e08-bb4d-4242-a509-7328d4ff70d7 vagy

http://cid-8dcaf3b0da4fb828.skydrive.live.com/embedrowdetail.aspx/ACTsorozat/ACT|_I|_basics.pdf

A most induló cikksorozattal szeretném bemutatni nektek az ASP.NET AJAX Control Toolkit használatát a gyakorlatban. Az első cikkben azt próbálom megmutatni, hogy mit kell tennünk ahhoz, hogy elkezdhessük a fejlesztést, majd az utána jövő cikkekben pedig mindig egyszerre csak egy vezérlőt fogunk majd tárgyalni. De ennyire még ne fussunk előre, kezdjük az alapoknál!

 

Mi is az AJAX Control Toolkit?
Az AJAX Control Toolkit egy nyílt forráskódú community project, vagyis MS-en belüli és MS-en kívüli fejlesztők együttműködésének eredménye. Így olyan eszközöket sikerült kifejleszteniük, melyek segítik a fejlesztőket mindennapi munkájukban, hogy AJAX-enabled weboldalakat készíthessen, egyszerűen. Tehát a Control Toolkit komponensek-gyűjteménye, melyek azt teszik lehetővé, hogy RIA-t (Rich Internet Application) fejleszthessük, gazdag kliens oldali felülettel. A CT egyik legnagyobb előnye az, hogy nem csak IE6-ra optimalizált kódról van szó, hanem IE7, illetve FF, Safari alatt is garantált működésről és helyes megjelenítésről! (ellentétben az ASP.NET 2.0-val )
Mint ahogy a nevéből is látszik, főleg az AJAX Extensions-re, illetve az AJAX Library Framework-re épül. Nem okoz nagy meglepetést számunkra az a tény, hogy a CT is szintén egy keretrendszer, ha tudjuk, hogy az AJAX Extensions illetve AJAX Library is tartalmaz vagy maga is egy framework. Ebből az az előnyük származik, hogy akár saját komponenseket is fejleszthetünk gyorsan és hatékonyan, melyhez egy eléggé nagy SDK nyújt segítséget.
A teljesség kedvéért még annyit érdemes megemlíteni az AJAX Control Toolkit-ről, hogy régebben az „AJAX projekt” része volt, mely Atlas fedőnév alatt futott. De jó MS szokáshoz híven megjelenés előtt egy pár hónappal átnevezték és szétszedték, így lett az Atlas-ból: AJAX Extensions, AJAX Library illetve AJAX Control Toolkit.

 

Milyen részekből áll?
Alapjában háromféle komponens található a Control Toolkit-ben: Control, Behavior, Extender.

A Controlok olyan vezérlők, melyek AJAX-os funkcionalitással rendelkeznek.
A Behavior, mint ahogy a nevéből következik, egy már meglévő ASP.NET 2.0-ás vezérlő viselkedését, funkcionalitását változtatja meg, (általában kibővíti). Ez felelős a kliens oldali részért, így egyértelmű, hogy JavaScript-ben lett megírva.
A Behavior-öket általában együtt fogjuk használni az Extender-ökkel. Ennek oka az, hogy az Extender a szerver oldali párja a dolognak.
Ez a sok dolog egyetlen egy dll-ben kapott helyet, amelyet nem kell a GAC-ban (global assembly cache) tárolnunk, hogy használhassuk. (lentebb bővebben)

 

Honnan tölthetem le?
Az AJAX Extensions-szel ellentétben ez nem az MSDC-ről (download center) tölthető le, hanem a CodePlex-ről! Ennek az az oka, hogy ez egy community project. Tehát az alábbi címről tölthető le:
http://www.codeplex.com/AtlasControlToolkit/
Itt válasszuk a Releases fület. 4 tömörített állományt tölthetünk le, aszerint hogy .NET Framework 2.0-át vagy .NET Framework 3.5-öt (beta2) használunk. Ezen belül még eldönthetjük, hogy van-e szükségünk a forráskódokra, ha nincs a NoSoucre-s verziót válasszuk.
(Természetesen azért innen is el lehet jutni az oldalra: http://www.asp.net/ajax/downloads/)

 

????Telepítés????
Miután letöltöttük valamelyik zip fájlt, látni fogjuk, hogy nincsen semmilyen telepítő program (msi, exe) a csomagban. Akkor mégis hogyan telepítsük fel? Ahhoz, hogy erre a kérdésre tudjuk válaszolni, először meg kell néznünk miket is rejt ez a sok mappa.
A zip fájlokat érdemes az ASP.NET AJAX Extensions mellé kicsomagolni, vagyis a %systemroot%\Program Files\Microsoft ASP.NET\ mappába. A forráskóddal együtt letöltött verzió 6 mappát tartalmaz: AjaxControlExtender, AjaxControlToolkit, Binaries, SampleWebSite, TemplateVSI,ToolkitTests.

– AjaxControlExtender: Egyetlen egy VSI-t tartalmaz, amely segítségével telepíthetjük az ajax control toolkit template-ket. Ezeknek, a sablonoknak az az egyetlen előnyük, hogy alapban tartalmazni fogja már a projekt Bin mappája az egyetlen szükséges dll fájlt (erre a használatnál külön kitérek majd, hogy az egy szerelvény, mégse egy szerelvény). Illetve meg lesz adva egy alapértelmezett tagprefix-e a vezérlőknek. A tagprefix nem más, mint a markup fájlban lévő tagekhez tartozó névtér, pl.: a <asp:TextBox> esetén az asp a tagprefix. A template-knél az alapértelmezett névtér az AjaxControlToolkit. Telepítése next, next, finish elven történik: (A VSI fájl elérhető a TemplateVSI\Bin mappából is!)

– AjaxControlToolkit: Ez a mappa tartalmazza az összes Control teljes forráskódját, beleértve a kliens és szerver oldali logikát illetve a szükséges resource fájlokat (css, képek). A szerver oldali kód C# nyelven érhető csak el! Ezeken kívül még található itt 4 mappa, én csak az ExtenderBase mappára hívnám fel a figyelmet, mely tartalmazza az Interfészeket, Attribútumokat, Eseménykezelőket, stb. (érdemes egyszer egy kis időt szakítani a kódokra!)

–  Binaries, TemplateVSI: Itt 3 szerelvény található. A BuildVSI.dll azért felölős, hogy a TemplateVSI mappában lévő lefordítatlan sablonokat le tudjuk fordítani. A másik kettő assembly-ről semmilyen infót nem találtam, így inkább róluk nem mondok most semmit. Aki akarja visszafejtheti a bennünk lévő kódot Reflector-ral, és láthatja, hogy nagyon sok Token objektum van .

– SampleWebSite, ToolKitTest: Ebben a mappában található az SDK, ami egy az egyben a http://www.asp.net/ajax/control-toolkit/live/ oldal. Tehát kipróbálhatjuk az összes vezérlőt a sajátgépünk anélkül, hogy bármit programoznánk. Ehhez a Control Toolkit gyökérmappájában lévő solution (sln) fájlt nyissuk meg, majd futtassuk a SampleWebSite project-et. A ToolkitTest projekt egy olyan webalkalmazás, mely automatikusan teszteli a Control Toolkit vezérlőket.
 
A NoSource-os verziókba csak az AjaxControlExtender mappa illetve a SampleWebSite mappa került bele!
A .NET Framework 3.5 Beta2-höz kiadott CT csomagok, első látásra annyival nyújtanak többet, hogy már van a Toolbox-ban minden vezérlőnek saját képe. Ha másért nem, akkor ezért biztosan megéri már venni Windows Vistát!

 

Használata
Kétféleképpen használhatjuk az AJAX Control Toolkit-et: Template segítségével, vagy anélkül. Csak a másodikat mutatom meg, hiszen az első használata teljesen egyértelmű, illetve valószínűleg egy már meglévő webalkalmazásunkat szeretnénk, majd felturbózni a CT-vel.

Ahhoz, hogy kényelmesen tudjuk használni az AJAX Control Toolkit vezérlőket érdemes hozzáadni őket a Toolbox-hoz. Ezt úgy tehetjük meg, hogy először létrehozunk egy új csoportot a CT vezérlőknek: Toolbox, jobb klikk >> Add Tab, majd csattogjuk be AJAX Control Toolkit.

Ez után kattintsunk ismét jobb egérgombbal a Toolbox-ra, majd helyi menüből válasszuk ki a Choose Items.. menüpontot. A felugró Choose Toolbox Items ablakban válasszuk a .NET Framework Components fület. Legalul kattintsunk a Browse gombra, és keressük ki az AjaxControlToolkit.dll szerelvényt. Ezt a SampleWebSite projekt Bin mappájában találhatjuk meg! Tehát ha az AJAX Extensions mellé csomagoltuk ki a CT-t, akkor az elérési út:
%systemroot%\Program Files\Microsoft ASP.NET\ASPNET Control Toolkit\SampleWebSite\Bin\AjaxControlToolkit.dll.
(A mappában még van egy jó pár szerelvény, amelyek arra szolgálnak, hogy a CalendarExtender lokalizációja automatikus legyen!).
Kattintsunk az Open gombra, majd láthatjuk a felsorolt listában, hogy mind a 35 vezérlő (folyamatosan bővül) ki van pipálva. Végül kattintsunk az OK gombra, és a Toolbox-ból máris elérhetővé tettük az összes CT vezérlőt.

 

Ha most ráhúzzuk valamelyik vezérlőt az egyik oldalunkra, akkor bekerül egy Register direktíva a markup fájlba. Ezt elkerülendő a web.config-ban beállítjuk, hogy minden oldalról elérhető legyen a szerelvény, illetve még a Tagprefix-et is megszabjuk. Ehhez először természetesen be kell másolnunk a webalkalmazásunk Bin mappájába az AjaxControlToolkit.dll fájlt. Utána a web.config system.web/pages konfig-szekción belül a controls elem alatt definiálunk egy új bejegyzést, íme:

 

<system.web>
  <pages>
    <controls>
       <add namespace="AjaxControlToolkit" assembly="AjaxControlToolkit" tagPrefix="ajaxtoolkit"/>
    </controls>
  </pages>
…
</system.web>

 

És ennyi! Most már mindent tudunk a CT alapjairól, így a következő cikkben bele is vágunk az Accodion vezérlő elemzésébe.

 

 

Külön köszönet Virág Andrásnak a Control Toolkit-es preziért!
 

3 okosság, 4 megoldás, 5 kerék, 6 gyerek, …

ASP.NET Tippek, Trükkök I. rész

 

Ma ismét egy kicsit rendhagyó blog bejegyzést olvashattok. Ennek több oka is van. Az egyik és legfontosabb a globalizációval kapcsolatban még gyűjtök anyagot. A másik szintén értelmetlen indok az, hogy ezeket tényleg hétköznapi problémákra lehet megoldásként alkalmazni. Ebben a bejegyzés három okosságról fogom lerántani a leplet, ígyvágjunk is bele!

 

 

1.Trick

Biztos mindenkivel előfordult már az, hogy egy saját osztályból (tehát nem apsx-ról, hanem App_Code mappában lévő üzleti logikából) próbálta meg volna elérni, mondjuk a Cache-t, vagy a Response objektumot. Hát igen, nem is olyan egyszerű a dolog. Direktbe nem tudjuk elérni ugyebár, ezért el kezdünk egy kicsit gondolkodni. A Response egy tulajdonság, nem pedig egy objektum. A Response a Page osztály egy tulajdonsága! De mintha már olvastunk volna valahol arról, hogy a Response egy HttpResponse objektumot valósít meg.
Na ugye, hogy mégse vagyunk elveszett emberek. Vagy mégis? Bepötyögjük szépen http, majd IntelliSence segítségével kiválaszt a HttpResponse objektumot és jön ismét a nagy pofára esés. Itt csak három tagfüggvényt tudunk elérni, amelyek teljesen általánosak és semmire se jók (legalábbis most biztos). Jön ismét a nagy 5let, létre kell hoznunk belőle egy példányt. Létre is hozunk belőle egy példányt, majd látjuk, hogy a konstruktora vár egy TextWriter objektumot. Oké legyen, implementáljuk a System.IO névteret is, ezen ne múljék.
Mivel a TextWriter egy absztrakt osztály, ezért konkrétan egy TextWriter objektumot nem tudunk neki odaadni. De egy belőle leszármaztatott osztályt már simán, pl.: StringWriter-t.
Na nézzük hol állunk most kód ügyileg:

TextWriter tw = new StringWriter();
HttpResponse hr = new HttpResponse(tw);
hr.Write(”Teszt”);

 

Futtatjuk és nagy megdöbbenésünkre nem ír ki semmit az oldalra az alábbi pár sor kód. Megint gondolkodunk, majd szétvet minket az ideg, és gondolunk egy merészet. Mi lenne, ha egy HtmlTextWriter objektum segítségével akarnánk kiírni. Okés, átírjuk a StringWriter-t HtmlTextWriter-re és látjuk, hogy mindkét túlterhelése a konstruktorának egy TextWriter obejktumot vár. És már fel is robbantunk.
Ezt úgy tudjuk elkerülni, hogy tovább olvassuk a blogot! Most kicsit félretéve a mese részt, elég hamar rájöttünk arra, hogy rossz helyen kopogtattunk. A nekünk kellő osztály nem a HttpResponse, hanem a HttpContext. Ennek van egyetlen egy baromi hasznos tulajdonsága, még pedig a Current. Ezzel eltudjuk érni az weboldal által használt kontextust és innen mintha már egy aspx oldal Page objektum-át sasolnánk. Tehát elérhetjük a Request-et, a Cache-t, a Session-t, stb. Egy oldal átirányítás az alábbi egyetlen sorral megoldható, ahelyett hogy ismét a HttpServerUtility vagy HttpUtility osztályokkal szenvednénk:

HttpContext.Current.Server.Transfer(„AndItsWorks.apx”);

 

 

2.Trick

Egy másik gyakori probléma, amibe bele futottunk már egy párszor, vagy ha még akkor fogunk az az, hogy egy Null értéket tartalmazó cellát akarunk olvasni. Hát igen, jön a szép Exception, mi meg ismét nagyon örülünk. Most már csak mese nélkül vázolom a rossz megoldást. Van a System.String objektum-nak egy IsNullOrEmpty() metódusa. Ezzel az a baj, hogy csak stringet lehet vele vizsgálni, így konvertálnunk kéne egy null értéket, ami lássuk be nem megoldható jelen esetben.

Viszont két jó megoldás közül is választhatunk, hogy elkerüljük a NullReferenceException-t. Az egyik megoldás az, hogy a DataReader (legyen mondjunk most SQL) IsDBNull() tagfüggvényét meghívjuk, amely egy bool értékkel tér vissza. Így egy egyszerű elágazásban letudjuk kezelni , ha null értéket tartalmazott az adott cella. Íme egy példa:

string result;
if(reader.IsDBNull(0)) result=”It was null!”;
else result=reader.GetString(0);

 

Az IsDBNull, illetve az összes Get-es tagfüggvénye az SqlDataReader objektumnak, mind egy oszlopazonosító számot várnak paraméterül. Ne feledjük 0-tól kezdődik a számozás és a lekérdezésben megadott mezősorrend érvényes itt is!

A másik jó megoldás a null értékű cellák olvasásra, az NVL sql függvény. Mivel sql függvény, ezért magába a lekérdezésbe kell beleágyazni. Két paramétert vár, az első egy mezőnév, melyben a null értékeket le szeretnénk ideiglenesen cserélni, a második paraméterként megadott értékre. Nézzünk egy példát:

 

SELECT Fizu + NVL(premium,0) FROM Ceg WHERE…

 

Tehát csak a null értékek lesznek lecserélve ilyenkor 0-ára.  Most már tudunk két alternatívát is a null értékek kezelésére.

 

 

3.Trick

A mai harmadik okosság a tárolt eljárásokkal kapcsolatos. Ugyebár, amikor egy tárolt eljárást akarunk meghívni, akkor a Command objektumnak be kell állítani a CommandType tulajdonságát is. Hát velem nem egyszer történt meg az, hogy ez a sor kimaradt a kódból. Aki nem tudja, hogy miről beszélek, annak itt egy példa:

MySqlCommand.CommandText = ”Insert_News”;
MySqlCommand.CommandType = CommandType.StoredProcedure;

 

Majd utána jönnek a paraméterek. Erre egy alternatíva az Execute utasítás, amely után meg kell adni a tárolt eljárásnevét. Előnye, hogy ilyenkor nem kell beállítani a CommandType-ot, mivel ilyenkor indirekt hajtatunk végre egy tárolt eljárást már. Hátránya az, hogy ilyenkor viszont fel kell sorolnunk az összes bemenő paramétert, természetesen a bekérésnek megfelelő sorrendben. Íme a fentebbi kód módosítása:

MySqlCommand.CommandText = ”EXECUTE Insert_News @Author, @Title, @News, @Date”;

 

 

Remélem ezzel a három kis okossággal sikerült újat mondanom nektek! A kövi ilyen Tips & Tricks blog bejegyzés még nem tudom mikor lesz, így ezen a héten befejezem még a 70-536-os könyv vesézést.   
 

Egy mail -nem mail, sok mail – spam

Chapter XV. Mail (E-mail)

 

Hát őszintén szólva bajban vagyok, hogy ehhez a témához még mit lehetne hozzáfűzni. De azért megpróbálkozok a lehetetlennel.

Egy kis terminológia  ASP.NET 1.X esetén a levelező rendszer még nem a System.Net.Mail névtér alatt volt található, hanem a System.Web.Mail. Az elnevezésben is történt egy kis változás, régi névtérben SmtpMail volt az objektum mely képes volt küldeni mailt, míg ASP.NET 2.0 esetén már SmtpClient. Ezen kívül még különbség van a két objektum között:
– SmtpClient.Host = SmtpMail.SmtpServer
– Az SmtpMail még nem támogatta az AlternativeView-t, vagyis hogy automatikusan eldöntse képes-e fogadni a címzett HTML alapú levelet.

 

A történelmi áttekintés után térjünk át a lényegesebb dolgokra. Két dolgot emelnénk ma csak ki, az egyik Web.Config-gal kapcsolatos, a másik pedig az csatolt fájlokkal.

 

Web.Config-ban van lehetőségünk arra, hogy  pl.: beállítsuk egy alapértelmezett feladót, vagy megadjuk a smtp server eléréséhez szükséges információkat. Ez azért hasznos, mert például, ha nem állítjuk be a PasswordRecovery tulajdonságait, tehát hagyunk mindent default-on, akkor innen olvassa ki a neki szükséges információkat.
Ezeket beállíthatjuk akár a Web Administration Tool segítségével is, de nézzük mi is a végeredmény a web.config-ban:

 

 <system.net>
    <mailSettings>
      <smtp from="noreply@jedlik.hu">
        <network  host="localhost"  port="25"  userName=""  password="" />
      </smtp>
    </mailSettings>
 </system.net>

 

A network elemen belül csak akkor muszáj megadnunk a port számot, ha az alapértelmezett nem a 25-ös.
Az smtp elemnek 3 fontos attribútuma van. Az egyik a from, amely az alapértelmezett küldőt adja meg. A második a DeliveryMethod, amely az alábbi 3 érték egyikét veheti fel: network, pickupDirectoryFromIis, illletve specifiedPickupDirectory. Az alapértelmezett a network, ilyenkor a network gyermek objektumot kell beállítani. Ha a harmadikat válasszuk, akkor a network gyerek elem helyett a specifiedPickupDirectory elemet kell deklarálni, amely arra szolgál, hogy megszabja mely könyvtárba legyenek eltárolva a feldolgozásra váró üzenetek.
Íme egy példa:

 

  <system.net>
    <mailSettings>
      <smtp deliveryMethod="specifiedPickupDirectory">
        <specifiedPickupDirectory
          pickupDirectoryLocation="c:\maildrop" />
      </smtp>
    </mailSettings>
  </system.net>

 

A harmadik smtp attribútum a configSource, mely használatát sötét homály fedi. Na jó nem, csak vicceltem, de nem fogjátok megtalálni így az MSDN-ben, vagy bárhol ahol rákerestek. Ennek az oka, hogy ez csak néhány configsection-nél extra attribútum. Ez az attribútum arra szolgál, hogy a web.config fájlt szétdarabolva több fájlban tárolhatjuk. Olyan configsection-öknél van ez az attribútum, amelyek nagy valószínűséggel eltérnek a fejlesztő gépen és a szerveren, ilyenek pl.: a connectionStrings, profile, smtp, authentication, sitemap,…. Előnye egyértelmű: rövidebb, ezáltal átláthatóbb a web.config fájl. Szerkesztéskor nem kell a teljes web.config-ot módosítani, csak pl.: a profile.config-ot. Íme egy példa a használatára:

 

Web.config
 <system.web>
      <profile configSource="profile config" />
 </system.web>

 

Profile.config
 <profile>
   <properties>
     <add name="Name" type="String" />
     <add name="Age" type="Int32" />
   </properties>
 </profile>

 

Ajánlom mindenki előszeretettel, hogy használja ezt a feature-t, mert megkönnyíti a deployment-et!

 

A másik dolog, amiről ma egy picit mesélek nektek az az Attachment osztály CreateAttachmentFromString() metódusa. A metódusnak 3 túlterhelése van, mi csak a (string context, ContentType contenttype)-es verziót nézzük most meg. Az első paraméter a csatolandó fájl elérési útja a második pedig a MIME type-ja. Nem biztos, hogy jobb alternatíva, mint használni az Attachment osztály konstruktorát, de érdemes tudni, hogy van ilyen.

 

Végül két cikket szeretnék a figyelmetek ajánlani. Az elsőnek inkább a vége érdekes, amely egy nagyon jó példát mutat arra (sajnos csak VB-ben), hogy miként kezelhetjük le a kivételeket. A másik cikk, pedig azt mutatja be, hogy tudunk szöveg üzenetet küldeni (nem SMS-t!!!) mobil telefonra. Íme a linkek:
http://aspnet.4guysfromrolla.com/articles/080206-1.aspx
http://www.c-sharpcorner.com/UploadFile/scottlysle/TextMsgToCellPhone12112006002339AM/TextMsgToCellPhone.aspx

 

Elkészült a 2.2-es Portál engine!!!

Elnézéseteket kérem, hogy kicsit rég írtam már a blogba, de nagyon el voltam foglalva a portál fejlesztéssel. A portál nagy újdonsága az, hogy AJAX-enabled lett. Ezt azért emelem ki, mert hamarosan indítok majd, egy ASP.NET AJAX Control Toolkit-et bemutató cikksorozatot, amely itt és a devportalon is elérhető lesz. De már most lecsekkolhatjátok az egyes új vezérlőket működés közben!
 
A Portál betöltésének lassúságán sajnos nem tudtam túl sokat javítani, mert nem maga a Portál lassú, hanem a jedlik sávszéle nem erre lett tervezve! 

Még egy kis titkot elárulok, ha minden jól megy és a fejesek is rábollintanak, akkor fel fogom tenni a teljes portál forráskódját, hogy bárki tanulhasson belőle! Ezt leghamarabb szeptember közepe, végefele lehetséges!

Holnap jövök a Mail fejezet kivesézésével, de addig is nézzétek meg az új portált, és esetleg osszátok meg a véleményeteket!

 

http://msiskola.jedlik.hu/aspnet