SimoneB's Blog : Tools

New SQLite provider for ELMAH

simoneb — Wed, 05 Sep 2007 22:05:00 GMT

I bet you know what ELMAH is, don't you? ELMAH stands for Error Logging Modules and Handlers, and its main and only purpose is to log exceptions occurring in ASP.NET web applications, within which it integrates with just a couple of entries in the Web.config file. It's got a lot of documentation and it's open source, so for any additional information check out its website.

Until yesterday it let you log exceptions in memory, on xml files and SQL Server, but a highly requested feature was to use SQLite as a backing store. Although I didn't know SQLite much it has a cool .NET wrapper published on Sourceforge which exposes its features to the managed world, so I took on the reported feature request and implemented it. SQLite doesn't offer all of the features provided by SQL Server, but it's almost completely SQL92 compliant so it has all that's needed, and much more.

So why to use SQLite instead of SQL Server or xml files? SQLite is a relational database engine, so it's much faster than xml files, and compared with SQL Server at the moment our tests didn't show any performance penalty; plus, it's free! Paging through about 15.000 stored exceptions via ELMAH user interface resulted to be lightning fast!

Since SQLite syntax isn't widely documented, if anyone's interested I will blog about it and the steps I went through to integrate it with ELMAH. Otherwise, the source code is available on ELMAH Subversion repository.

ASP.NET Ajax UpdatePanelNotifier Builtin Effects

simoneb — Mon, 20 Nov 2006 02:50:00 GMT

Yesterday I wrote about a control I've written which lets you bind javascript functions to UpdatePanel's partial postbacks. I've been working on it some more today and I enhanced it with some builtin effects which can be applied to the UpdatePanel which is refreshed using the combination effects of the script.aculo.us library. The behavior is similar to the UpdatePanelAnimation control extender which can be found in the AjaxControlToolkit but this is easier to use and more flexible in that only the UpdatePanel which is actually refreshed is applied the effect. Furthermore using the Animation framework available with the toolkit can be tricky.

The control API becomes:

OnBeginRequest and OnEndRequest properties: enum of type ClientAction
CustomBeginRequest and CustomEndRequest properties: string which accepts the name of a javascript function declared in the page

The ClientAction enum defines the following values:

Custom
Appear
Fade
... [all the script.aculo.us combination effects]

The behavior is as following:

When an effect is specified via the OnBeginRequest and OnEndRequest properties the corresponding effect is applied to the UpdatePanel which is being refreshed during the corresponding event
When the value of one of those properties is set to Custom you can specify via the CustomBeginRequest and/or CustomEndRequest properties the name of a custom javascript function declared in your page which is called in response to the correspondng event (the function accepts as input parameter an DOM element which is the DIV element of the UpdatePanel as rendered in the browser).
If you don't want to do anything just set OnxxxRequest to Custom and leave the corresponding CustomxxxRequest empty.

The source code is available on my main project's svn repository.

ASP.NET Ajax UpdatePanelNotifier: get notified of partial updates

simoneb — Sun, 19 Nov 2006 00:26:00 GMT

UPDATE: The control has been added new features, check it out here.

Sometime ago I wrote a post about how to get the ID of the UpdatePanel which triggered an asynchronous postback using the ATLAS July CTP and how to execute a custom Javascript function whenever the postback initiated and when it sent back its results. With the release of ASP.NET Ajax Extensions Beta the API has changed a lot and that code is no longer working, while he new API exposes now a whole new set of facilities which make it really easier to achieve the same functionality.

I wrote the control I once called UpdateProgressSignup from scratch and changed its name to a more meaningful one: UpdatePanelNotifier. What this control does is very similar to the UpdateProgress standard control, in that it executes some client-side code whenever a partial update is triggered and when the results are returned from the server. The difference is that instead of executing a determined function (showing and hiding a <div> element by manipulating the DOM) you can bind your custom javascript functions to those events, which in turn receive as input parameter the concerned UpdatePanel DOM element so that you can directly act on it, making it blink when the beginRequest event is fired and then shake when the endRequestEvent is fired, for example.

The control exposes the same properties as the standard UpdateProgress control beyond two new properties which let you enter the name of the functions you want to execute:

OnBeginRequest
OnEndRequest

Each function executed in response to those events will be passed the DOM element of the UpdatePanel concerned in the partial update, so that if you set the OnBeginRequest property to "alertPanelId", you'll have to write a javascript function called "alertPanelId" in you page which will have the following signature and will eventually do something like this:

function alertPanelId(panelElement)
{
    alert(panelElement.id);
}

Note that the bound functions will be called only when the partial refresh is triggered by a control inside the UpdatePanel and not when it's an external trigger doing it, since in this case it's not yet possible to retrieve the Id(s) of the UpdatePanel(s) which will be refreshed in response to that action. Anyhow it seems that the ASP.NET Ajax Team is working on it and will eventually provide this facility in the final release.

You can watch a short screencast to get started fast. The source code is available on my main project's svn repository.

ASP.NET Ajax EnhancedUpdateProgress - choose the position of your UpdateProgress!

simoneb — Tue, 14 Nov 2006 00:00:00 GMT

I've been playing with the new bits of the ASP.NET Ajax framework lately; I like the enhancements pretty much, a much cleaner code and a very richer API to have fun with.

Since with the Beta 2 the UpdateProgress control is bundled into the main assembly I chose to enhance it a bit so that I can choose where to show it in my page. I inherited from the UpdateProgress control and exposed an additional property called Position, which accepts the following values:

Center (default)
TopLeft
TopRight
BottomLeft
BottomRight
None (same position as in the standard UpdateProgress, that is, where placed in the page)

I've recorded a short screencast to show how it works, and the source code is available on my main project's svn repository.

Getting the ID of the UpdatePanel which triggered an asynchronous postback

simoneb — Sat, 02 Sep 2006 18:44:00 GMT

UPDATE 19/11/2006: An updated version of the component compatible with ASP.NET Ajax Extensions Beta 2 has been released, details in this post.

UPDATE 11/11/2006: With the release of ASP.NET Ajax Extensions Beta this post is outdated, and the attached code is no longer working. I'll be posting a new version of the component soon.

Some time ago I wrote about a web control I created which let you bind two javascript functions to the postback and callback events of Atlas UpdatePanels, thus giving you the choice of executing custom code whenever any of the UpdatePanels of the page posted and called back.
I called it UpdateProgressSignup since its job is similar in some ways to the UpdateProgress built-in control's, in that it performs an action when the asynchronous request begins and another one when the response calls back.
More precisely, the component in charge of raising these events in Atlas is the Sys.WebForms.PageRequestManager, a client-side sealed singleton class which performs the asynchronous requests to the server and returns the results of the response (as well as much more).

How to intercept Atlas postbacks and callbacks
In the first implementation my control was based simply on two members exposed by the PageRequestManager class:

propertyChanged event
inPostBack boolean property

Thus, using an event handler to hookup the propertyChanged event we got notified whenever the PageRequestManager performed an action:

Sys.WebForms.PageRequestManager.propertyChanged.add(onPropertyChanged);

function onPropertyChanged(sender, args)
{ 
   [...] 
}

The args parameter which is passed to our event handler is an object containing, among others, the name of the property which has changed, and the one which concerns us is the inPostBack property of the PageRequestManager class.
If this is the property which has changed it means that either a postback has been initiated or a callback has been received.
To identify in which of the two situations we find ourselves we need to retrieve the actual value of that property, and for this we use the sender parameter, which is actually the singleton instance of the PageRequestManager class. If this property is true, then we are in postback mode, otherwise we are in callback mode. The body of the above function thus becomes:

function onPropertyChanged(sender, args)
{
    if(args.get_propertyName() == "inPostBack") 
    {
        if(sender.get_inPostBack()) 
        {
            // postback mode
        } 
        else 
        {
            // callback mode
        }
    }
}

All I did in my control is to make this if/else statement call the javascript functions provided by the user via the control's properties.
Credits for (part of) this solution to the ASP.NET forums.

How to retrieve the ID of the UpdatePanel which triggered the postback
So far so good. Now, a potential problem is: "Ok, I know when any of the UpdatePanels of my page post and call back, but how do I know which one did that?". That's legitimate, but there's no easy answer. The PageRequestManager keeps a list of the UpdatePanels which are on the page, as you can see from the xml-script generated whenever an Atlas ScriptManager control is on the page, which may look like the following fragment:

<script type="text/xml-script">
<page xmlns:script="http://schemas.microsoft.com/xml-script/2005">
  <components>
    <pageRequestManager id="_PageRequestManager"
                        updatePanelIDs="UpdatePanel1,UpdatePanel2"
                        asyncPostbackControlIDs="Button3"
                        scriptManagerID="ScriptManager1" 
                        form="form1" />
  </components>
</page>
</script>

There you can notice one more thing, the asyncPostBackControlIDs attribute. This is the list of controls which work as triggers for the UpdatePanels of the page, and which are thereby placed outside of the UpdatePanels themselves. We'll talk about this later, since it introduces some limits to what we are trying to achieve.
Back to our reasoning, I was gonna tell you that the PageRequestManager object doesn't expose the ID of the UpdatePanel which triggered the postback, so in the start I struggled about how the beneath mechanism got to know which was the UpdatePanel to be actually updated (let alone UpdatePanels whith mode=Always).
Using some tracing tools (FireBug for Firefox and Fiddler) I found out what an Atlas postback looks like when triggered by an UpdatePanel. As even children know already, it is a POST request performed exploiting an object called XMLHttpRequest, whose body look like this:

ScriptManager1=UpdatePanel1&__VIEWSTATE=[...]&__EVENTVALIDATION=[...]&Button1=Get%20Date!

As you can see, and as I had imagined, the ID of the UpdatePanel which triggered the postback is actually sent to the server, along with the actual state of the controls in the panel itself; so I though there should be a way to retrieve the ID of that panel myself, thus being able to pass it to the two custom javascript function in order to give the developer more control and some more information about what was happening.
So I started reading the very very long Atlas.js file, which contains all the required code needed to run Atlas, as well as the code of the PageRequestManager class.

My reasoning was that since the PageRequestManager object doesn't expose the ID of the UpdatePanel - while actually finding it out in order to supply it to the component which builds the request - there should at least be one way to reproduce the same steps that Atlas did to retrieve that coveted ID. And finally I got it!

What the PageRequestManager does in order to retrieve it is - in brief - listening to clicks on the page's form element, and then retrieving the element which was clicked.
With that element, it then navigates backwars all the DOM tree until it finds and UpdatePanel (the PageRequestManager keeps a list of all UpdatePanels of the page, as said before) or doesn't find any. After another bunch of checks, it is then able to know if that UpdatePanel needs to trigger the post back, and in this case, actually perform the task.
As easy as this!

Since the PageRequestManager object doesn't expose such functionality to the public, the only way is to reproduce it, thus listening to the clicks on the form element, and then navigating backwards the parents of that element until we find an UpdatePanel using the array which the PageRequestManager supplies (if one is ever found).
Omitting some minor details, the final step is then to pass the ID of that UpdatePanel to our two javascript functions as a parameter, so that whenever they are invoked we know exactly which UpdatePanel triggered the rountrip. The following functions do the lookup and retrieve that information:

for (var j = _updatePanelIDs.length - 1; j >= 0; j--) 
{
    var updatePanel = document.getElementById(uniqueIDToClientID(_updatePanelIDs[j]));
    
    if (updatePanel && updatePanel.contains(element)) {
        return createPostbackSettings(true, uniqueIDToClientID(_updatePanelIDs[j]));
    }
}

function createPostbackSettings(async, panelID) 
{
    return  { async:async, panelID:panelID };
}

Using this new functionality I updated the code of the original control so that it supplies this information to the custom javascript functions. The dowload links are at the bottom of the post.

What if a trigger initiated the postback?
As you should know, there's at least one more way an UpdatePanel can be updated, and it's by using triggers, which are controls placed outside the UpdatePanel. When these controls fire events or change the values of their properties the UpdatePanel/s bound to them can be updated. Under the point of view of the need of retrieving the ID of the panel which triggered the postback this represents a major issue, since in this case the asynchronous request sent to the server takes this form:

ScriptManager1=ScriptManager1&__VIEWSTATE=[...]&__EVENTVALIDATION=[...]Button3=I%20am%20a%20trigger%20for%20UpdatePanel2

As you can see there's no trace of the UpdatePanel bound to the trigger, and it's bad news since we are not able to retrieve its ID in this case.
The PageRequestManager mechanism, in this case, returns as the panelID property the ID of the ScriptManager object of the page, which furthermore is not an DOM element of the page, unlike the UpdatePanels which are rendered as DIVs, so it's completely useless.

In this situation, that is, when it's a trigger which performs the postback, we are still notified of the event, but we get no ID of any UpdatePanels, on which we could act since they are elements of the DOM, but instead the ID of the ScriptManager, which 99% is ScriptManager1 and most important not an element of the page. Thus, whatever action we want to perform on the parameter supplied to our javascript functions, we must first ensure if we are working on the ID of a page element or on a simple string, whch is the ID of nothing!

Ok, now that I've explained what the underlying framework is doing, I will just teach you how to use the control.

How to use the UpdateProgressSignup control
First, the control comes in two flavours, just like Atlas does. A client -side control and a server-side one. It's a matter of choice, but of course the server-side control is faster to set up. Here's the procedure to set up the server-side control:

Write your javascript functions
Remember what I told you before, the parameter passed to the functions is a string which can contain either the ID of the UpdatePanel in case the postback has been fired from inside the panel itself - which corresponds to the ID of the DIV element that the panel is rendered as - OR the ID of the ScriptManager, which doesn't correspond to any element of the page. Thus, in order to distinguish the two situations, a simple check using the dollar function is needed.
The code below shows a sample function I used in the demo supplied with the download, which uses MochiKit to apply a nice effect to the UpdatePanel:
```
<script type="text/javascript">   
function shake(elementID)
{
    if($(elementID))
        // UpdatePanel ID
        MochiKit.Visual.shake($(elementID));
    else
        // ScriptManager ID
        alert("I am a ScriptManager with ID " + elementID);
}  
</script>
```
Drag and drop the UpdateProgressSignup control from the toolbox or register it manually into the webform.
Set its two properties, OnPostback and OnCallback, to the name of the javascript functions you want the control to call on the respective events.

In case you want to use the client-side version of the control, there are the steps:

As before, create your javascript functions.
Make the UpdateProgressSignup.js file available to the page by importing it. It must be placed below the Atlas scripts, so the optimal place to include it is the bottom of the page, between the closing form and body tags:
```
<script type="text/javascript" src="Scripts/UpdateProgressSignup.js"></script>
```
Create an instance of the control by calling the contructor and supplying some parameters. You can put this right below the previous script include. Note that for coherence the instance of the control is given that long name, but any other name goes:
```
<script type="text/javascript">
    Sys.WebForms.UpdateProgressSignup = 
      new Sys.WebForms._UpdateProgressSignup({ postback: shake, callback: pulsate });
</script>
```

That's all, you're ready to go.

Just one final note and some Atlas background. Atlas can perform one request at a time, it won't accept two simultaneous asynchronous request. So if one request is being processed, you cannot trigger another UpdatePanel postback even if you click on a button inside it.
This brings to what I wanted to tell you. Downloading the code you may notice that there's an additional boolean property called Exclusive that can be used both in the client and server side implementations. It is true by default and 99% of times you'll leave it as is. It's hard for me to explain what it does since my English is not so perfect, so I'll give you an example, supposing that on postback we apply a shake effect and on callback a pulsating effect to the UpdatePanels. Ok, we have two UpdatePanels on the page which contain each a button, which in turn, on the server, sleep the thread for some seconds; you'll understand why in a sec.

Exclusive = true (default)
Click on button inside UpdatePanel1 -> UpdatePanel1 shakes.
While the thread is sleeping on the server click button inside UpdatePanel2.
When the thread wakes up, it returns the response and UpdatePanel1 pulses.
Exclusive = false
Click on button inside UpdatePanel1 -> UpdatePanel1 shakes.
While the thread is sleeping on the server click button inside UpdatePanel2.
When the thread wakes up, it returns the response and this time is the UpdatePanel2 which pulses.

Notice that it's always the UpdatePanel1 which gets the updated content, even in the second case. The only reason why in the second case it's the UpdatePanel2 which pulses is because the UpdateProgressSignup control registered that when the request triggered by the UpdatePanel1 was executing, we tried triggering the UpdatePanel2 too, and lets us know it by pulsing it instead of the UpdatePanel1.
I don't know if this may become useful, but well, it wasn't difficult to implement so I left it as a choice.

The download links can be found on my website at this page.

Cascading autocomplete made easy

simoneb — Mon, 28 Aug 2006 00:20:00 GMT

Over the last few days the API of the ScriptAculoUs.Net AutocompleteTextBox control has changed pretty much, since I've switched from a custom implementation based on reflection to the ASP.NET built-in callback mechanism.

I chose to do the switch because the former implementation, despite being much more flexible, lacked in that it didn't let you exploit the ASP.NET Page intrinsic objects like Session, ViewState, and web controls values inside the body of the method which supplied the suggestions, since that instance of the Page was instantiated via Reflection and didn't run through the pipeline at all.

Today I'm lazy about updating the original post - which has become a "patched post" - with the new details, and I chose instead to create a quick screencast to illustrate how easy and straightforward is to implement a cascading autocomplete pattern using the control.

I haven't released the binaries of the new version yet, because I want to do some more testing before, but the source can be found on the SVN repository by the project homepage.

Take a look at the screencast, and please forgive a little mistake I did. When I populate the Cars collection I check for IsPostBack, but it made much more sense if I simply checked for nullness.

ImageReflection with the Atlas Control Toolkit

simoneb — Wed, 16 Aug 2006 16:01:00 GMT

A few days ago I blogged about an ASP.NET control I wrote to apply a neat effect to the images of a web form. In the meanwhile I found another implementation of the same effect which is much lighter in the means of both kBytes and cpu work and does exactly the same, so I decided to write another control using this one instead of the script.aculo.us version.

Even I still don't like the Atlas Control Toolkit that much (suffice to say that it doesn't run in medium trust), I chose to try writing this new control using the MS framework. What I like about it is the way it extends the design mode representation of other controls, so that you don't need to create one extender for each of the controls you want to extend, but simply place one extender on the page and then hookup its properties via the wannabe-extended control's properties pane.

Let me tell you that writing an extender with the Atlas Control Toolkit isn't that easy in the starting - and mostly if you are just trying to port and existing script behavior - because you first have to know what the Atlas framework is going to do with your script, and I'm not sure I understand everything is going on behind the scenes yet.
That said, realizing the right way of doing it wasn't much difficult in this case and after some refactorings of the original script I came up with an extender called ImageReflectionExtender, which is built with the latest Atlas and Atlas Control Toolkit releases.

Binaries, source and a screencast are available.

LiteBox meets Flickr: LiteBoxFlickrAlbum

simoneb — Wed, 09 Aug 2006 23:17:00 GMT

Yesterday I got a link on my news aggregator pointing to a new article by Sam Judson on Coding4Fun, which talks about a .NET version of the API for the Flickr services.
A nice idea immediately came to my mind, why not extending the LiteBoxAlbum control to display photos retrieved via Flickr? This way I can have a LiteBox-like photo album which displays photos got from Flickr without writing a single line of code and by setting only a couple of properties, in order to tell the control which photos to look for.

So I wrote a new control derived from LiteBoxAlbum and called LiteBoxFlickrAlbum. They differ in that while the former displays photos placed in the same folder as the page in which the control is added, the other looks for photos on Flickr. It exposes some new properties which are pretty self-descriptive. The only thing to notice is that Flickr lets you use the service only via a Flickr API Key, which it uses for tracking purposes. You'll need to get one in order to use the control, and you can do it at this url. Once you have one, you can take a look at the screencast I recorded.

Watch the screencast!

Source available on the SVN repository (quickstart here) and binary available along with my Script.Aculo.Us.Net library (bottom of the post).

ScriptAculoUs.Net on Sourceforge Project Hosting

simoneb — Sat, 05 Aug 2006 16:55:00 GMT

All my projects are grouped under one main repository located on Sourceforge, together with my main project, BusyBoxDotNet. The source code can be accessed via Subversion.

Here are the links:

Project homepage: http://sourceforge.net/projects/busybox
SVN Trunk: http://busybox.svn.sourceforge.net/svnroot/busybox/trunk
(to be used for browsing the repository with a browser or with a SVN client)
SVN client: On Windows I suggest TortoiseSVN

QuickStart Guide to SVN

Getting (checking out) the source

Install TortoiseSVN
Create a new folder - preferably in the same directory where you keep your Visual Studio projects - called ScriptAculoUs.Net - or whathever
Right click on the folder just created
Click on "SVN Checkout"
Type "http://busybox.svn.sourceforge.net/svnroot/busybox/trunk" in the textbox "URL of repository"
Click OK. You should have all the source ready to be compiled

Staying up to date with code changes

Right click on the folder where you checked the sources out
Click on "SVN Update"

How do I submit a change I think you may find useful?

In version control jargon, this is called submitting a patch, that is, a small file containing only the changes made to the original code, so that it becomes easy and fast for the project members to review, evaluate and test them, and eventually include them in the code base.

These are the steps to create a patch using TortoiseSVN:

Get the latest version of the source code - important in order not to make changes which may already have been done
Make your changes to the code
Right click on the folder where you checked out the source
On the TortoiseSVN context menu click on "Create Patch..."
Select the files where you have made changes and continue
You are asked to save the file containing the patch, so save it and give it a meaningful name
Contact me and I'll be glad to review your patch!

Scott Hanselman furthermore wrote a more detailed post about creating a patches.

If you're interested in contributing the project or just give feedback or suggestions for future improvements you can even contact me via this link.

LiteBoxAlbum: Autogenerate LightBox-like photo albums

simoneb — Fri, 04 Aug 2006 13:28:00 GMT

UPDATE 10/08/06: A couple new features, read the bottom of the post for details.

Yesterday I posted about how I created a couple ASP.NET web controls to make it easy to generate a photo gallery using the LiteBox library. Ok now I have to make a confession, that was only a step to achieve something much more useful, an automated LighBox-like image slideshow!

Some time ago I downloaded the very nice PhotoHandler by Bertrand Le Roy, a control/handler which is very versatile and allows you to autogenerate image galleries on the fly, so I thought I would create something similar but instead using the functionality that LiteBox already gives us.

The concept is simple. The control I created is called LiteBoxAlbum, and when you drag it on a web form it automatically searches for images in the same folder of the page itself, and for each of them creates a LiteBoxImageLink and renders it on the page in a hidden fashion, associating each link the same Group (so that you can navigate through them). When you run the page, it simulates a click of the mouse on the first link and starts the slideshow. Now you can navigate through all the images of the folder using the LiteBox interface. That's cool, isn't it?
I recorded a short screencast to show how to use it, even if it's very very simple. It required some black magic to start the slideshow automatically, since the Gecko DOM doesn't allow calling the click method on anchors, so I had to find a workaround which I'm reporting here in case you're interested in the trick:

function simulateClick(elementID) 
{
    var el = $(elementID);

    if(!document.all)
    {
        var evt = document.createEvent('MouseEvents');
        evt.initMouseEvent('click', true, true, window, 0, 0, 
                           0, 0, 0, false, false, false, false, 0, null);

        el.dispatchEvent(evt);
    }
    else
        el.click(); 
}

UPDATE 10/08/06: By the way, now you can also call the function which starts the album manually. A property called ShowOnLoad lets you choose whether to show it automatically or not. To call the function manually the control exposes a property called StartFunction which returns the Javascript statement to execute in order to start the album. This statement can be triggered, for instance, by an Html input button (the control which triggers it mustn't perform a postback or the album, of course, won't be shown).
Suppose you have placed an Html Input Button called Button1 on your webform, set its runat="server" attribute so that you can retrieve and assign its properties on the server-side.
On The Page_Load event handler you can write the following:

protected void Page_Load(object sender, EventArgs e)
{
    Button1.Attributes["onclick"] = LiteBoxAlbum1.StartFunction;
}

Now whenever the button is clicked the album is started.

The screencast can be watched here, while sources and binaries can be downloaded along with my Script.Aculo.Us.Net bundle (bottom of the post).

LightBox with ASP.NET

simoneb — Fri, 04 Aug 2006 04:06:00 GMT

If you don't know what LightBoxes are check out the list at blinklist. Among them two implementantions caught my attention, the original LightBox JS 2.0 by Lokesh Dhakar and the lighter LiteBox by Tyler Mulligan.

The final result is exactly the same, they are able to show images in a really nice fashion, as well as create a slideshow out of them. They differ in some aspects by the way:

LightBox JS is based on script.aculo.us and prototype while LiteBox is based on moo.fx and prototype.lite, which are pratically a subset of the original libraries.
LightBox JS is heavy since its weight is about 100k, while LiteBox is much lighter, about 30k.

You might be wondering why the effect is exacly the same; well, script.aculo.us and prototype espose a great amount of functionality which LightBox JS doesn't exploit, so there's no need for such heavy libraries. That's why I chose LiteBox for my own port to ASP.NET.

Ok, so we want to get that effect with our images. In order to set LiteBox up you need to:

include the scripts into your page
import a stylesheet
make LiteBox images available in some folder of your website in order for it to be able to retrieve them (I mean the images which show up in the LiteBox to perform navigation and close the box)
place your anchors pointing to your images on the page
set the rel attribute of your anchor elements to "lightbox"
[optional] or set the rel attribute to "lightbox[group]" in order to group together a set of images so that you can surf through them
[optional] set the title attribute of the anchors to show a caption for the image.

Ok, too much to do in my opinion. Not very reusable. Let alone that if you want to show thumbnails of the images you have to wrap your anchors around img tags! (ASP.NET HyperLink controls instead expose a property called ImageUrl which does just the same, and it's what I've used for my implementation).

So here comes my wrapper. Nothing to read here the control LiteBoxExtender is obsolete, read on. I created a webcontrol called LiteBoxExtender which includes the scripts and the stylesheet for you, and which will come even more useful later. This control is a non visual control, and works together with another control called LiteBoxImageLink which is wired up automatically to the LiteBoxExtender once dragged on the webform and which represents a link to an image.
The LiteBoxImageLink is derived from HyperLink and behaves the same it does. It only exposes one more property called Group.
So in order to set it up all you have to do is:

Drag on the page as many LiteBoxImageLinks as you want. Each one will represent an image which will show up in the LiteBox.
Set the properties of the LiteBoxImageLink controls:

NavigateUrl: the url of the image which will show up in the LiteBox

[optional] Text: the text to show in the link to the image

[optional] ImageUrl: the url of the preview image (to be used instead of Text)

[optional] Group: a group name, in order to group images together and be able to surf through them.

It's that easy, no more scripts and styles to deal with, no images to copy in your website folders, and no manual editing of your anchors to wire up the LiteBox, the controls will do that by themselves. Of course it will work with normal HyperLink controls too as well as with anything that renders on the page as an html anchor tag, but in that case you'll have to follow the manual procedure and set the rel attributes yourself.

The control is available inside my Script.Aculo.Us.Net library.

UPDATE: sources are now only available via the SVN repository. Read here for details. If you download the library you'll find another control called LiteBoxAlbum. I'm not talking about it here since it deserves another post, but it is much cooler than the controls I've described in this post, so you may want to check it out. One advice only, create a blank webform, drag a LiteBox album control in it and place some images (.jpg or .gif) in the same directory as the webform. Then just browse to the page and enjoy!
UPDATE: The follow-up has been posted and is available here.

SweetTitles - fading tooltips (and my extender)

simoneb — Mon, 31 Jul 2006 01:12:00 GMT

Dustin Diaz, among other cool things, has written a nice Javascript library called SweetTitles to convert hyperlink's Title attribute (Tooltip property in ASP.NET HyperLink web controls) - those yellow popups appearing when you hover the mouse over them - into nice fading boxes.

The picture below shows the effect change when using it:

You should know I'm becoming the wrapper man so I thought I would ease its integration with ASP.NET into a draggable web control - as well as enhance it a bit. The control I created is a simple extender control and all you have to do is drag it onto your webform to see everything happen magically. All the HyperLinks and <a> tags on your page receive that nice effect for free.

<asp:hyperlink id="HyperLink1" runat="server" navigateurl="~/SomePage.aspx"
 tooltip="I link to SomePage.aspx">SomePage</asp:hyperlink>

<a title="I link somewhere else" href="/SomeWhereElse">SomeWhereElse</a>

The control is called SweetTitlesExtender, has no runtime appearance and exposes a single enum property called EmbeddedStyleSheet with 5 values:

None - no stylesheet will be embedded, you'll have to write your own
Classic - the one shipped by Dustin Diaz with the library
Dustin - the one Dustin Diaz uses on his own website
Blueish
Greenish
Reddish

That property allows to choose among some some stylesheets I have embedded into the assembly to provide some ready to use style options, which look like in the following picture (I'll let you guess which one corresponds to each enum value):

In case you want to provide your own style, set the property to None and create a stylesheet with the following structure:

body div#toolTip { position:absolute;z-index:1000; [...] }
body div#toolTip p { [...] }
body div#toolTip p em { [...] }
body div#toolTip p em span { [...] }

Since the original library is licensed under a Creative Commons Attribution Share Alike (by-sa) license, my control is under the same license.

Binary and source available.

Reflection for images... not that Reflection!

simoneb — Sun, 30 Jul 2006 01:38:00 GMT

First just relax, I'm not talking about *that* Reflection, instead about reflecting images.
Yes I said that. Thomas Fuchs, the inventor of script.aculo.us, whom you may have guessed I like pretty much, has an exciting post on his blog where he shows how he reflects images as if they were in front of a mirror. You should definitely check it out here.

He says it's not production code, in fact you will experience high load on the cpu and on the memory while the script is running (especially on IE), but the effect is incredibly nice.

Of course I couldn't restrain myself from writing an extender control for ASP.NET which lets you apply that effect to classic Image controls. I've bundled it into my Script.Aculo.Us.Net library, so that you can get the nice features all together. Oh, did you check out the new features? Now it can run side-by-side with Atlas...

By the way, I've called this control ImageReflectorExtender, and it exposes three properties, which make using it a cakewalk.

Image: a reference to an ASP.NET Image control on the page
Amount: the size of the reflected area
Opacity: the opacity of the reflected area

My advice is not to increase too much the values of Opacity and Amount because they lead to cpu and memory load as well as not to place more than one reflected image on a page and not much big too, for the same reason.

Download links can be found at the bottom of this post, all the controls working with script.aculo.us are bundled in a single assembly.

Registering scripts into the page header with ASP.NET 2.0

simoneb — Fri, 28 Jul 2006 19:09:00 GMT

UPDATE 19/08/2006: changed the API, no more public constructor but static property to access the instance of the HeadScriptManager.
UPDATE 03/08/2006: now the library allows to register stylesheets too. See class diagram below for details.

ASP.NET 2.0 pages expose a new property called ClientScript of type ClientScriptManager, which allows to manage client-side scripts, usually Javascript but not just that. Its public methods allow to render scripts in different parts of the page, as well as to register some client-side events.
In particular, scripts can be rendered just below the opening of the form tag or just before its closing, but it's not directly possible to include scripts into the head tag.
With ASP.NET 2.0 you may have noticed that web forms created with Visual Studio 2005 and family products automatically place the runat="server" attribute in the head tag of each page. That's why the Page class exposes a new property called Header, of type HtmlHead, which allows to interact with the page header and do something like including an external script:

HtmlGenericControl Include = new HtmlGenericControl("script");
Include.Attributes.Add("type", "text/javascript");
Include.Attributes.Add("src", "http://dev.virtualearth.net/mapcontrol/v3/mapcontrol.js");
this.Page.Header.Controls.Add(Include);

or like injecting code manually:

HtmlGenericControl Include2 = new HtmlGenericControl("script");
Include2.Attributes.Add("type", "text/javascript");
Include2.InnerHtml = "alert('JavaScript in Page Header');";
this.Page.Header.Controls.Add(Include2);

Looking at this post by Christopher Pietschmann (where I shamelessly got the above code) I had the idea of creating a library to extend the features of the ClientScriptManager class to the header of the page. Unluckily that class is sealed, it would have been nice to create a partial class to extend it... I always wonder why the guys at Microsoft don't let us exploit the power of the framework exposing some more of their internal, private, and sealed stuff. However what I came up with - thanks to Reflector to keep the API close to that exposed by the framework as well as to save time - is a simple class which can be used in the same way, and lets you render script blocks, script includes and embedded resources in the page header. To be more user-friendly it keeps the member names of its "parent" class. Here is the diagram:

UPDATE 03/08/2006: the class exposes a new set of methods with a similar signature which allow to inject stylesheets. The usage is the same, but they render the content inside <style> tags in case of embedded styles (RegisterHeadStyleBlock) or inside <link> tags in case of linked styles (RegisterHeadStyleInclude and RegisterHeadStyleResource). It comes useful mostly to control developers, so that you can inject embedded assembly resources.
UPDATE 19/08/2006: the API has changed and the constructor is not directly accessible. The instance of the HeadScriptManager can be accessed using the Current static property. The example below has been updated to reflect this change.

Now it can be used referencing the assembly in the project, creating an instance and calling its methods:

HeadScriptManager manager = HeadScriptManager.Current;

manager.RegisterHeadScriptBlock(this.GetType(), "scriptKey", "alert('hello');", true);

Source and binaries are available along with my main project, BusyBoxDotNet.

Debugging tools and tips for ASP.NET applications

simoneb — Mon, 24 Jul 2006 16:13:00 GMT

When I develop ASP.NET applications or test my controls I make use of some tools which I thought would be useful listing, along with some tips.

PocketSOAP TcpTrace and ProxyTrace are very simple tools which let you see the traffic flowing between you and a server (a local server too) in a raw fashion. They're almost identical in that they show what's passing through them, but when ProxyTrace acts as a proxy server (you choose a port to listen on and configure your browser to point to it), TcpTrace lets you choose both the port to listen on and the destination server:port pair; then it will redirect all the traffic coming from localhost:SourcePort to DestinationServer:DestinationPort.

I mostly use TcpTrace because it's faster to set up since you don't have to change the browser settings to make use of a proxy server. Suppose you are developing a web application with ASP.NET and want to see what's flowing between your browser and the ASP.NET Developement Server which comes with Visual Web Developer (asynchronous traffic too). As you know the VWD server starts on a dinamically chosen port, in order not to collide with other instances eventually running already. So you hold CTRL + F5 to start the all the stuff and you'll see that the browser points to http://localhost:SomePort/VirtualDirectory/PageName.aspx , where SomePort is the port it is listening on (in my case, at the moment, 3862). Now, in order to analyze the traffic, start TcpTrace and you are prompted to insert at least three parameters that you can set as follows:

Listen on Port #: set it to an arbitrary number, this is the port you will point to with your browser. For example, 8080, but anything goes.
Destination Server: set it to localhost.
Destination Port #: set it to the value SomePort we saw before. It is the port the VWD server is listening on, in my example, 3862.

Click OK and you'll have TcpTrace listening on port 8080 and redirecting to port 3862 (and vice-versa). All that's left to do is set your browser to point to the new port, so you'll change only the port of the url from SomePort (3862) to 8080. Hit Enter and you'll be able to see all the Request/Response pairs in the TcpTrace GUI.
These are very simple tools, and will let you see only the raw data, but they are as simple as useful.

Fiddler is a more advanced tool for debugging HTTP traffic. It acts in the same way as ProxyTrace does, except that when started it automatically configures Internet Explorer to make the traffic flow through the port it listens to (by default, 8888). In case you want to use it with another browser then you'll have to set its proxy settings to point to that port. Fiddler even installs itself as an IE plugin, so that you can start it directly from there.
Fiddler has many more features than the PocketSOAP suite, and the one I use most is its ability to show much more data about the Request/Response pair. In fact, it can show Request data as Headers, Text, Forms, Hex, Raw and Xml, and Response data as Headers, Text, Image, Hex, Caching, Privacy, Raw, Xml. It can even edit the response data, for example applying compression.
Another nice feature is the SyntaxView format, which is achieved installing a plugin which is available on its website and which shows Response data in the same fashion as you see it in the VWD editor. Very cool.
If you need advanced features Fiddler is absolutely the choice.

Internet Explorer Developer Toolbar and Firefox Web Developer Toolbar are two toolbars with so many features that would take a book to describe them all. They are a must have for web developers. Among hundreds features, validation of markup, CSS, accesibility and so on as well as partial page source view (remember Ajax?). Just check them out and you'll see how useful they are.

TamperIE and Tamped Data are two addins respectively for Internet Explorer and Firefox which allows editing the data submitted to the server either by GET or POST request. While GET requests can be easilly edited by hand since the name/value pairs are appended to the url, POST requests require such tools to be edited. Ok, maybe you thought you didn't need to validate POST data on the server because there was no way of tampering with it?...

ieHTTPHeaders is an Explorer Bar for Microsoft Internet Explorer that will display the HTTP Headers sent and received by Internet Explorer as you surf the web. It can be useful in debugging various web-development problems related to cookies, caching, etc.

Full Source is an Internet Explorer menu extension which displays the source Internet Explorer is displaying, directly from the Internet Explorer object model. This is useful wherever javascript is dynamically writing HTML into the DOM, or where XSLT has been used to generate HTML.

JSLint is a javascript code verifier. It's written by a JS guru, Douglas Crockford. When you write Javascript, you should use this online tool to verify its correctness. Besides checking the code for errors, it suggests best practices and common subtleties and supplies a lot other infos on the code.

Web Developement Helper by Nikhil Kotari is an Internet Explorer plugin that provides a set of useful tools to both Ajax/JavaScript developers as well as ASP.NET page and control developers.

Finally, just a couple of tips for debugging Javascript with VWD or Visual Studio 2005. When you start in debug mode (F5), you can see a window called Script Explorer (if not, you can show it up with Debug -> Windows -> Script Explorer). In that window you can see all the client-side code you can break into with breakpoints. As far as I've experimented it's a bit buggy, but sometimes it comes useful.
Another way of debugging Javascript is to write the keyword "debugger" in your script files. When you then enter the debug mode, the execution breaks exactly where you placed the keyword, so that you can debug your script starting from there.