A TabContainer és a rejtélyes tábla esete

Jelenleg épp egy olyan ASP.NET alkalmazáson dolgozom, ami használja az AJAX Control Toolkit TabContainer kontrolját.

Tudni kell, hogy az adott alkalmazás esetében eléggé sarkalatos kérdés performancia. Magyarul lassú mint a csiga az akácerdőbe'. Ez részben annak köszönhető, hogy meglehetősen összetett és az összes létező technológiát használja, sőt néhány nem létezőt is :) Ennek megfelelően folyamatosan mérve van és a legkisebb további lassulás is eléggé mély ráncokat vés a homlokokra.

Az előzmények ismeretében érthető, hogy nem volt túl örömteli, mikor egy dizájn csiszolgatás után, ahol is kis kinézetbeli igazgatások történtek, bekerült egyszer csak valahonnan 4 másodperc (!) extra renderelési idő. Igaz, hogy a cucc nagyon lassú, de azért 4 másodperc még így is mintegy 70-80%-os lassulást jelentett. Azonnal elkezdődött a vad nyomozás, majd végül kiderült, hogy nem más tekeri meg ennyire a böngészőt, mint egyetlen egy darab dekorációs célból odabiggyesztett 1 pixeles vonal, ami ezzel a kóddal lett kivitelezve:

<table class="tab_top_decor">

<tbody>

<tr>

<td class="tab_top_decor_selected">

</td>

<td>

</td>

</tr>

</tbody>

</table>

Rendben, elismerem, nem a legjobb erre a célra táblázatot használni, de mivel az oldal teljes egészében old-school (és nem túl okos) módon táblázatokkal van formázva, így azt gondoltam, nem oszt nem szoroz, ráadásul akkor még nem tudtam erről a trükkről, ami a 6os explorernek is megmondja, hogy márpedig mekkora az akkora.
Érthető módon majd megölt a kíváncsiság és szanaszét teszteltük az oldalt, míg végül kiderült, hogy az adott tábla csak a TabContainer belsejébe helyezve okozza ezt a durva lassulást. Idő híján nem nyomoztunk tovább, de valószínűleg a TabContainer javascriptjei között van valami ordenáré módon lebaltázva, aminek ezt a 4 másodpercet köszönhettük.

Miután a korábban említett trükköt kiderítettem átírtam DIV-re a dekorációs csíkot és így már minden rendben volt. Na meg természetesen eldöntöttük, hogy ha egy mód van rá megszabadulunk a tebkonténertől, mielőtt még egy időzítet bomba az arcunkba robban.

IE6 és a DIV méretezése

Jelenleg egy olyan projektben dolgozom, ahol az egyetlen és kizárólagos webkliens az Internet Explorer, annak is az öregecske 6-os verziója. Mint tudjuk az IE mindig is arról volt hírhedt, hogy nagyvonalúan kezeli a szabványokat, de különösen hírhedt ez a verzió a DIV elementek érdekes kezeléséről. Nálam ez most éppen azért okozott fejtörést, mert dekorációs célzattal egy 1px-es vonalat kellett elhelyeznem, ami dinamikusan alakulgat. Lényeg az, hogy a leglogikusabb megoldásnak egy 1px magas DIV tűnt. Volna. Ha az IE hajlandó lett volna 10px-nél kisebb elemet megjeleníteni.
Hosszas guglizás után kisült, hogy ez a csacsi IE nem hajlandó az aktuális fontméretnél alacsonyabb lenni, csak, ha ezt külön megmondjuk neki. Hm. Ez vajon kinek a fejéből pattanhatott ki? Vagy csak mellékhatás? Bizonyíték gyanánt nézd meg ezt a kódot IE6 alól:

<div style="background-color: #FF0000; height: 1px"></div>

Ime:

Ha a fentit tudjuk, akkor már könnyen rá lehet jönni, hogy milyen beállításokkal lehet elérni a kíván 1px magasságot.
Logikusnak tűnik a DIV számára az 1px-es fontméret beállítása.

<div style="background-color: #FF0000; height: 1px; font-size: 1px"></div>

Ez a megoldás majdnem jó, de nem teljesen. Így már tudunk egész kicsi magasságot beállítani, de 1px-et mégsem.
Az igazi okosság az overflow tulajdonság beállítása, ami azt jelenti, hogy lekezeljük a kilógó részeket.

<div style="background-color: #FF0000; height: 1px;overflow: hidden"></div>

Így már tökéletes 1px-es csíkunk van. Fentieket teszteléséhez kiválóan lehet alkalmazni az IETester nevű segédprogramot, ami 5.5-től felfelé bármelyik IE verziót tudja nekünk prezentálni.

Levélküldés tesztelése SMTP nélkül

A legtöbb webes alkalmazásban van egy-két olyan sztori, amikor levelet szándékozunk kiküldeni a rendszerből. A végleges változatban általában SMTP szerver felhasználásával tesszük ezt, de fejlesztés közben meglehetősen kényelmetlen minden tesztfuttatás alkalmával ellenőrizni egy postaládát. Ráadásul korántsem biztos, hogy rendelkezésre áll a megfelelő szerver, a fejlesztői gépre sem feltétlenül tudunk vagy akarunk telepíteni.
Ilyenkor az SmtpClient osztály beállításával megtehetjük, hogy a saját fájlrendszerünkkel "levelezünk".
Fentiekhez a web.config állományban a következő beállítások szükségesek:

<system.net>

<mailSettings>

<smtp deliveryMethod="SpecifiedPickupDirectory">

<specifiedPickupDirectory pickupDirectoryLocation="c:\temp\mailpickup"/>

</smtp>

</mailSettings>

</system.net>

Így azonnal ellenőrizhetjük, hogy az üzenet a megfelelő tartalommal előállt-e.

[Test]

public void SendMailTest()

{

SmtpClient smtpclt = new SmtpClient();

MailMessage message = new MailMessage("from@server.com", "to@server.com");

message.Body = "Body";

message.Subject = "subject";

smtpclt.Send(message);

}

A kliensnek egyébként futás közben is megmondhatjuk, hogy a levelet ebbe a könyvtárba küldje:

smtpclt.DeliveryMethod = SmtpDeliveryMethod.SpecifiedPickupDirectory;

smtpclt.PickupDirectoryLocation = "c:\\temp\\mailpickup";

jQuery intellisense tipp

FRISSÍTÉS:
Tegnap olvastam, hogy a Microsoft a VS2008-hoz megjelentette ezt a frissítést, ami lehetővé teszi, hogy trükközés nélkül használjuk a jQuery intellisense támogatást.

Kettővel ezelőtt írtam, hogy van már VS intellisense részére kommentelt jQuery.
Van egy okos trükk, hogy véletlenül se felejtődhessen benne a végső kódban a kommentekkel tűzdelt js állomány.

<script src="jquery-1.2.6.js" type="text/javascript"/>

<% if (false) { %> <script src="jquery-1.2.6-vsdoc.js" type="text/javascript"/>

<% } %>

A fenti módon inkludálva a scriptet az intellisense látni fogja, viszont rendereléskor nem kerül be az oldalba.
(A tipp az ASP.NET Debugging blogról származik)

Gyalogos útvonaltervezés API reloaded

A múltkoriban írtam a témában egy rövidet. Akkor idemásoltam egy kódrészletet, ami elvben szemléltetné a használatot. Nos szemléltetésre épp jó csak nem működik :)
Amikor élesben akartam használni a függvényt, mégpedig úgy, hogy az útvonalat ÉN MAGAM rajzoltatom ki és nem adok meg sem panelt az itinernek, sem pedig map paramétert kiderült, hogy ez bizony így nem megy:

var directions = new GDirections();

Nem tudom bug-e vagy feature, de az ititnert feldolgozó DIV megadása nélkül nem működik.

var directions = new GDirections(map, directionsPanel);

Az, hogy az itiner ne legyen látható, elég egyszerű hack.

<div id="route" style="width: 0px; height:0px; display: none;">

Ha (úgy ahogy én) csak a polyline-t akarjuk beszerezni, akkor a konstruktorban lehet null-t adni a map helyén:

var directions = new GDirections(null, directionsPanel);

Egészében a működő cucc:

Bár ennél a megjelenítésnél nem látszik, de az irány több helyen egyirányú utcákban szemben megy, bizonyítván ezzel, hogy tényleg gyalogos útvonalterv készült :)
Íme a forrás:

var map;

var directionsPanel;

var directions;

function initialize() {

map = new GMap2(document.getElementById("map_canvas"));

map.enableScrollWheelZoom();

geocoder = new GClientGeocoder();

geocoder.getLocations("Hungary, Budapest Jókai tér 5", function(response) {

var place = response.Placemark[0];

var p = new GLatLng(place.Point.coordinates[1], place.Point.coordinates[0]);

map.setCenter(p, 17);

}

);

directionsPanel = document.getElementById("route");

directions = new GDirections(null, directionsPanel);

GEvent.addListener(directions, "load", function() {

var gdpolyline = directions.getPolyline();

map.addOverlay(gdpolyline);

});

var opts = { getPolyline: true, getSteps: true, preserveViewport: false, travelMode: G_TRAVEL_MODE_WALKING };

directions.load("from: Hungary, Budapest Jókai tér 5 to: Hungary, Budapest Hernád utca 48", opts);

}