Posted on

Älä uudelleenohjaa virheen sattuessa

ASP.NET:ssä voi asettaa mukautetun virheilmoitussivun kullekin HTTP:n tilakoodille (esimerkiksi 404 tai 500). Kun virhe sattuu, käyttäjä uudelleenohjataan sopivalle sivulle. Tässä tavassa on ainakin kolme asiaa väärin:

  1. Jos kävijä kirjoitti osoitteen käsin ja teki virheen, ei tuota virhettä voi helposti korjata, koska osoite vaihtuu.
  2. HTTP-viestiketju on kummallinen. Pyydetty resurssi löytyi, mutta osoitteessa, jota ei ole tai jossa sattui palvelinvirhe. Anteeksi mitä?
  3. Palvelinvirheen (500) sattuessa olisi fiksua näyttää viesti, jossa yhtenä vinkkinä kehotetaan yrittämään hetken kuluttua uudelleen. Jos tälle sivulle on uudelleenohjattu, ei toimintoa voikaan enää yrittää vain sivua päivittämällä. Käyttäjä saattaisi odottaa jotain muuta.

Esimerkki: MSDN:n kotisivu on msdn.microsoft.com. Voisi siis hyvin arvata, että ladattavat tiedostot löytyisivät osoitteesta http://msdn.microsoft.com/download/. Kokeile tuota osoitetta ja katso mitä tapahtuu. Oikea polku olisi ollut “downloads”, mutta yritäpä korjata se yhdellä näppäimellä nyt, kun osoite onkin http://msdn.microsoft.com/404/default.aspx.

(ASP.NET:ssä tämän voi korjata tarttumalla virheeseen Application_Error-metodissa global.asax:n codebehindissa ja tekemällä Server.Transfer:n oikeaan osoitteeseen. IIS:ssä ei ole tätä ongelmaa, vain ASP.NET:ssä.)

Posted on

Code inline vai code behind?

Richard Tallent linkkasi (9.7.2009: toimimaton linkki poistettu) jo vähän aikaa sitten lyhyeen keskusteluun code inlinen ja code behindin välisestä paremmuudesta, jossa oli itse antanut ainoan viisaan kommentin. Muut eivät taida lainkaan välittää siitä millä ennestään pahasti rikkonaista webiä rikkovat.

ASP.NET:in code behind -mallia perustellaan useimmiten sillä, että se mahdollistaa koodin eriyttämisen esityskerroksesta. Tilanne saattoi vielä muutama vuosi sitten taulukko- ja pikselitaiton kulta-aikana ollakin näin. Alati kasvava CSS:n hyödyntäminen on johtanut siihen, että HTML tekee yhä useammin sitä mitä sen suunniteltiinkin tekevän: kuvaa dokumentin rakennetta. Esityskerroksen visuaalinen osa, eli CSS, on jo luonteeltaan erotettu selkeästi sisällöstä, joten ASP.NET:in mallille on käyttöä enää vain pikselitaittoa suosivien ajastaan jälkeen jääneiden kehittäjien käsissä. Kaikki ulkoasumuutokset tehdään CSS-tiedostoon, ja jos HTML:ää on tarve muokata ollaan muokkamassa dokumentin rakennetta. Rakennetta muokattessa myös esityslogiikka on vaarassa muuttua, mikä tekee näistä kahdesta käytännössä erottamattomat.

Toinen Code Behind -mallin käytön perustelu on tuottavuuden lisääntyminen. Se saavutetaan muka sillä, että web designer ja ohjelmoija voivat työskennellä saman sivun parissa toisiaan häiritsemättä. Saavutettava hyöty on todellisuudessa minimaalinen, sillä käytännössä vain kaikkein tarpeellinen esitysrakenteeseen liittyvä koodi jää “kehittymättömimmissäkin” tekniikoissa sivun yhteyteen. Kaikki muu koodi sijoitetaan sivun ulkopuolelle yksinkertaisimmillaan SSI:n avulla, jos suunnittelussa on käytetään edes vähän järkeä.

Visual Studio 2005 tulee ymmärtääkseni tarjoamaan Code In Page -mallia oletusarvoisena, mikä on loistava juttu. Kunhan vain kehittäjäyhteisön enemmistö tajuaisi tämän.

Posted on

Mikä ASP.NETissä on tehty oikein

Huomasin narisevani aivan liikaa ASP.NETistä, sillä pidän teknologiasta ja käytän sitä vapaaehtoisesti. Päätin siis listata ne osat, joihin olen siinä ja ylipäätään koko .NETissä mieltynyt.

1. C#

Erittäin loppuun asti mietitty kieli. Puhdasta nautintoa vuosien VBScriptin vääntämisen jälkeen. Microsoftin sitoutuminen kielen kehittämiseen on myös hyvä asia.

2. Olio-ohjelmointi

Oliomallia on hyödynnetty ja sitä pääsee hyödyntämään ASP.NETissä erinomaisesti.

3. Framework

VBScriptin jälkeen tietysti melkein mikä tahansa tuntuu hyvältä, mutta joka tapauksessa .NETin framework on todella monipuolinen ja suurimmaksi osaksi hyvin suunniteltu paketti. Menneitä ovat ne ajat, jolloin melkein mitä tahansa tehdäkseen oli ostettava komponentti.

5. Omien kontrollien tekeminen

Vaikka web-kontrolleilla voi saada pahaakin jälkeä aikaan, on uudelleenkäytettävyys ja eristäminen muusta sovelluksesta merkittävä etu verrattuna esimerkiksi vanhan ASP:n include-malliin. Includeita silti välillä kaipaa edelleen, niilläkin kun on käyttönsä.

6. Ohjelmakoodin erottaminen merkkauskielestä

Aina tuota eroa on mahdoton tehdä, mutta useimmiten se selkeyttää sovelluskehitystä ja helpottaa työskentelyä ei-ohjelmoijien kanssa. Välillä tämä ero tehdään DataGrideillä ja muilla pirullisilla keksinnöillä, mutta asiat voi tietysti yhtä hyvin tehdä järkevästikin.

Muita hyviä puolia on kovaa vautia tulossa Whidbeyn muodossa. Arkistosta löytyy itse poimimani ennalta parhaalta kuulostavat puolet.

Nyt jos höpisisi jostain ihan muusta seuraavaksi.

Posted on

Anteeksipyyntöjä

Absum.netin nimetön blogaaja loukkaantui eilisestä kirjoituksestani. Pahoittelut tarpeettoman ilkeästä tekstistäni.

Sinänsähän vika ei ollut ratkaisussa eikä kysyjässäkään, sillä ongelma ja sen ratkaisumalli olivat ihan loogisia tuollaisessa tilanteessa. Vikaa voisi kai hakea enemmän siitä teknologian tarjoajassa, joka on päättänyt tuollaisen ohjelmointimallin ulos pulauttaa ja sitä kautta ikäviä ongelmia aiheuttaa.

Jos kontrolleita sidotaan johonkin datalähteeseen ne joudutaan oikeasti lataamaan joka sivulatauksella uudelleen, vaikka siltä ei ohjelmoijasta ehkä näytä. Kun rakennetaan verkkopalveluita, joilla on potentiaalisesti rajaton käyttäjäkunta, on joka ikisen tietokantakutsun oltava varmasti tarpeellinen. ASP.NETin malli taas johtaa siihen, että sivulatauksia ja tietokantahakuja tehdään helposti lukuisia täysin turhaan. Käyttöliittymät saattavat parantua jonkin verran, kun isojen ja monimutkaisten lomakkeiden rakentaminen on helpompaa, mutta toisaalta web ei ehkä ole oikea ympäristö isoille lomakkeille. Tämä nyt vain yhtenä esimerkkinä mallin heikkouksista.

Kenties olen vain vanha jäärä.

Posted on

Mikä ASP.Netissä on vikana

Tällaiset ongelmat (toimimaton linkki poistettu 9.7.2009) ja niiden ratkaisut saavat minut välillä repimään hiuksiani. Selvästi sekä kysyjä että vastaaja ovat ymmärtäneet väärin koko webin toiminnan. Tilattoman webin pakonomainen muokkaaminen toimimaan kuin VB:n lomakkeet johtaa vain lukukelvottomaan, tehottomaan ja typerään koodiin. Kyseisessä tilanteessa voisi kenties harkita vaikkapa sellaista uutta keksintöä kuin <input type=”reset”/>.

Netti on pullollaan ohjelmointivinkkejä, ja .NET tuntuu keränneen valtavan määrän eritasoisia ohjelmoijia teksturin ääreen. Intialasen Saravana Kumarin artikkeli Redirecting User to Login Page After Session Timeouts on yksi huonoimmista koskaan lukemistani. Kirjoittajan eduksi sanottakoon, että asia on esitetty ihan selkeästi. Missään vaiheessa hän ei kuitenkaan ole ilmeisesti tullut ajatelleeksi, että artikkelissa ei ole mitään järkeä. Mies on toisaalla sivuilla esitellyn mukaan kerännyt kasan Microsoftin sertifikaatteja. Katosi moisten arvostus minulta ennätysajassa.

Ai mitäkö artikkelissa on vikana? Muun muassa se, että käyttäjältä kysymättä sivun uudelleen lataaminen on hyvin todennäköisesti erittäin ärsyttävää. Toisekseen se, että joku yksittäinen sivu on ollut selaimessa auki session keston ajan ei vielä tarkoita, ettäkö sessio olisi todella päättynyt. Käyttäjällä kun voi olla auki vaikka kuinka monta ikkunaa. Jos yksi niistä jää vähän pienemmälle huomiolle joksikin ajaksi ja sitten sen pariin palataan, ei väärä ilmoitus katkenneesta sessiosta ole järkevä. Jälleen kerran webin todellinen luonne on täysin hukassa VB-ohjelmoijalta.

Tätä webin luonnon vastaista, huonoa HTML:ää tuottavaa, potentiaalisten tietoturva-aukkojen täyttämää ohjelmoitimallia ei Whidbeykään tule korjaamaan. Sitä odotellessa käytän vain ja ainoastaan ASP:Repeateria ja hyvin säästeliäästi mitään "palvelinpäässä ajettavia" kontrolleja. Niinkin käytettynä ASP.Net hakkaa vanhan ASP-mallin mennen tullen.