if-sats + datalist = no no?

Hej,

Du kan enkelt göra en funktion som är publik. Sen anropar du genom function(DataBinder.Eval(Container.DataItem, "fält"))

Lite kod

<asp:DataList ID="xxx" runat="server" ...>
          <...template...>
                    <img src='<%# MyFunc(DataBinder.Eval(Container.DataItem, "fält")) %>' alt="blaha" />
          </...template>
</asp:DataList>

public string MyFunc(int input) {
          if (input != 0)
                    return "bild.gif";
          else
                    return "bild2.gif";
}

Typ så, finns givetvis enklare metoder att göra, men det är väl ungefär så här du kan göra.

Ps. Sorry för DataBinder.Eval :-D

/m

Annars är det väl bättre att använda OnItemCreated på DataListen. Det är så det är tänkt att användas.

Ps. Sorry för DataBinder.Eval :-D

Min svensklärarina sa alltid om man kände till de svenska skrivreglerna så fick man lov att bryta mot dem. Vilket jag ivrigt försökte påvisa att jag gjorde och det var därför som jag lyckades bryta mot dem så många gånger...

Så om man känner till den hemskhet som finns inbyggd i Databinder.Eval är det helt okej att rekomenderar den till andra så man själv framstår som ett geni när man skriver korrekt kod :)

- M

Gladh skrev:

Ps. Sorry för DataBinder.Eval :-D

Min svensklärarina sa alltid om man kände till de svenska skrivreglerna så fick man lov att bryta mot dem. Vilket jag ivrigt försökte påvisa att jag gjorde och det var därför som jag lyckades bryta mot dem så många gånger...

Så om man känner till den hemskhet som finns inbyggd i Databinder.Eval är det helt okej att rekomenderar den till andra så man själv framstår som ett geni när man skriver korrekt kod :)

- M

Vad är det för hemskheter som finns inbyggt i Databinder.Eval? :q :OO Och vad ska man använda/göra istället i samma eller liknande situationer?

mozilla skrev:

Vad är det för hemskheter som finns inbyggt i Databinder.Eval? :q :OO Och vad ska man använda/göra istället i samma eller liknande situationer?

DataBinder.Evil!!

Problemet är att DataBinder.Eval använder reflection i runtime för att plocka ut värden, dvs. att klasserna analyseras medan sidan körs, för att på rätt sätt plocka ut värdena, oavsett om data kommer från en DataTable, DataReader, array el. dylikt.

Fördelen är att man kan använda i princip samma kod oavsett datatypen. Nackdelen är att all denna analys tar en jäkla massa tid och kraft.

Det vore fel att säga att DataBinder.Eval är helt fel, för om man är medveten om vad den gör så kan man åtminstone medvetet välja den för att undvika att koppla designlagret till underliggande lager (datatyper).

För att köra snabb kod så gäller följande princip

Ex. DataRow

<%# MyFunc((int)((DataRow)Container.DataItem)["fält"]) %>' alt="blaha" />

dvs. med direkta typomvandlingar

Det vore fel att säga att DataBinder.Eval är helt fel, för om man är medveten om vad den gör så kan man åtminstone medvetet välja den för att undvika att koppla designlagret till underliggande lager (datatyper).

All sådan logik skall/bör ligga i codebehind, alltså så använder man sig av eventen OnItemCreated/OnItemDataBound (eller vad de nu heter) istället och du kan man på sin ASP: sida istället skriva

<ASP:Label id="Datum" runat="Server"/>

Och så låter man sin codebehind dina data till din label. Då slipper designer verkligen bry sig om vilken datakälla som används, han placerar bara kontrollerna och någonannan får som uppgift att fylla dem med data...

- M

Aha, där ser man :i Jag testade det igår kväll, men fick inte så stor framgång :OO, alla mina försök slutade i

System.InvalidCastException: Specified cast is not valid.

Det jag försöker göra är att hämta en text från en mySQL databas in i en DataReader(MySqlDataReader) och sedan skriva ut det i en repeater. Någon som kan peka mig i rätt riktning på hur koden bör ser ut då?

Och en fråga angående OnItemCreated, när och hur tycker ni man bör använda den? Själv gillar jag asp.nets möjligheter att separera koden med grafiken, och OnItemCreated ger ju möjligheten att lägga in asp:Label's i repeatern, och i koden lägga på texten. Det blir ju lite mer kod men bättre struktur(?)

Frågan är då om man kan använda OnItemCreated hela tiden, eller om man bara ska använda OnItemCreated när man måste?

edit: undertiden jag skrev kom Gladh med ett intressant inlägg som spinner på mina tankar. Vad tycker ni andra? Och om man ser till prestanda hur ligger det till då?

mozilla skrev:

Någon som kan peka mig i rätt riktning på hur koden bör ser ut då?

Om du kör typomvandlingsspåret så ska du typomvandla DataItem till en IDataRecord

((IDataRecord)Container.DataItem)["kolumnnamn"]

mozilla skrev:

undertiden jag skrev kom Gladh med ett intressant inlägg som spinner på mina tankar. Vad tycker ni andra? Och om man ser till prestanda hur ligger det till då?

Separationsmässigt är den modell Gladh nämner inte så bra (man skapar datatypsberoende på kontrollnivå i stället för på datanivå), men den kan vara bra för att separera arbetet mellan programmerare och designer. Fördelen är att designern kan göra lite vad som helst, utan att paja något, nackdelen är programmerararen måste veta vad designern gjort, eller vidta åtgärder i koden för att kolla att Label-kontrollen helt plötsligt inte blivit en TextBox.
Prestandafrågan är svår att svara på för för det beror på väldigt många faktorer. I den benchmarktester jag gjort är det dock generellt sett långsammast att sätta värdena i OnItemDataBound. Lite förvånande, måste jag säga, men resultaten var entydiga.

I den benchmarktester jag gjort är det dock generellt sett långsammast att sätta värdena i OnItemDataBound. Lite förvånande, måste jag säga, men resultaten var entydiga.

Det kanske inte är så konstigt eftersom det för varje rad i din datacollection kommer att skapas ett event som kastas och sedan därefter så läggs datan till kontrollen. Du slipper eventet och dess argumentklass om du sätter värdet direkt i ASP sidan.

Det skulle dock vara intressant och se hur MSIL koden ser ut för de olika exemplen och där jämföra varför det tar längre tid med eventen...

- M

Gladh skrev:

Det kanske inte är så konstigt eftersom det för varje rad i din datacollection kommer att skapas ett event som kastas och sedan därefter så läggs datan till kontrollen. Du slipper eventet och dess argumentklass om du sätter värdet direkt i ASP sidan.

Alldeles riktigt, men den massiva kod som körs vid en DataBinder.Eval skojar man inte bort, oavsett reflection eller inte. Jag kan nämna att jag byggde en egen Eval-funktion som cachade "reflektions-deskriptorerna". Skillnaden var alltså att min Eval utgick från att inom samma kontrolls DataBind så skilde sig inte datatyperna åt mellan bindningspunkterna (ett rimligt antagande). Detta gav en 30%-ig prestandavinst på überstora datamängder. I "vanlig" användning var den inte så intressant, även om man önskat att Eval var uppbyggd på något liknande sätt.

Gladh skrev:

Det skulle dock vara intressant och se hur MSIL koden ser ut för de olika exemplen och där jämföra varför det tar längre tid med eventen...

Ja, det vore intressant. Jag misstänker att typecasting av DataItem (sker överhuvud taget inte i Eval) samt FindControl kan sno en del.