SimoneB's Blog : ASP.NET

CS2 - a personal source code search engine

simoneb — Thu, 13 Sep 2007 15:16:00 GMT

As I blogged some time ago I have been developing a source code search engine called CS2. I completed it lately and, although it's not as feature-rich as others - say, Koders Pro Edition - it works pretty fine and suites the needs of whomever needs to search through code stored on its machine. Actually, it's neither as heavy as Koders Pro as well, and plus it's free and open source.

It works as an ASP.NET 2.0 website and lets you request indexing folders and singular files, as well as search through them with a simple syntax. By default searches are performed in full-text fashion, but you can restrict queries on particular fields. The syntax is documented in the website. It's multithreaded so indexing and searches can occur at the same time.

It can be customized using the Properties.config file in the Configuration directory, by setting the folder where the files of the index are stored as well as the update interval. It's capable of automatically removing from the index files which no longer exist on the file system as well as update those which have been edited.

At the moment it can parse and index only C# source code but it's written upon Windsor inversion of control container and can be easily extended just by adding a new parser. If anyone's interested I will post about the complete process of adding a new parser.

To get started just download the zipped website from the project homepage and run it. Then type the path of a folder containing C# source code files on your machine in the corresponding input field and wait some time for the indexing process to complete (you won't see the progress since it occurs on another thread so that you can perform searches concurrently with indexing). Its duration depends upon the number of files to be parsed and indexed. Once indexing is complete updating the page shows the number of documents the index contains. Click on the link on the upper-right edge of the page to show the search syntax.

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 Internals - the second article is available for reading

simoneb — Sat, 16 Jun 2007 01:38:00 GMT

The second article of my series about ASP.NET Internals is up. Before reading I reccomend giving a look at the first one however.

It took me a while to write it since I had to fiddle into the ASP.NET infrastructure with several profilers to get to understand the undocumented parts, but it was fun. In this article I've talked about the interaction between ISAPI extensions and managed code as well as the setup mechanism of AppDomains.

Next part will cover the principal managed part of ASP.NET, the HTTP Pipeline.

ASP.NET Internals - follow my article series

simoneb — Wed, 02 May 2007 08:39:00 GMT

A few days ago I wrote about the chance of writing technical articles for DotNetSlackers. My article has been published today and it's the first of a series of 3 or 4 about the ASP.NET infrastructure. In this article I talked about IIS and the process model implemented by ASP.NET when running on different versions of IIS. In the next one I'll tackle the ASP.NET pipeline and in the last one the compilation mode and page lifecycle, thus trying to cover all the aspects concerning the life cycle of a web request. I kept one eventual fourth article to talk about topics I didn't cover in the former three, like the new features introduced by ISS 7 and threading.

You can read the first article here. If you like the article please leave a vote, and well, feel free to leave a comment for any questions.

ASP.NET Singleton-per-Page pattern

simoneb — Mon, 16 Apr 2007 23:18:00 GMT

A while ago I blogged about a pattern useful to ensure that just a single instance of a class was created and used during a unique request-response pair. That seemed to make sense, since using the HttpContext.Items property prevents a single pipeline from instantiating that class more than once.

At the time I didn't realize that actually one could need a little more granularity and may incur in some issues when that instance needs logically to be bound to a single page instead of a single request-response. One might be wondering where's the difference, since usually during a single request just a single page is executed. That's true most of the times unless you use a subtle method of the HttpServerUtility class called Transfer.

When that method is called, usually via the Server property of the Page class, the execution of the current page is interrupted and the control is passed to the new page specified as input parameter, which executes its whole life cycle from the beginning.

In this case both the pages share the same HttpContext, and if in the singleton-per-request instance of the class you got a reference to the currently executing page (that's what I needed to do in the HeadScriptManager), when you transfer the control to the new page your singleton instance still keeps a reference to the old page.

This seems enough to introduce a sub pattern of the singleton-per-request which might be called singleton-per-page. The only problem is to find a place where to store information which is exclusive to a single page and not shared between pages, even if they are executed in the scope of the same context.

The Page class features a property called Items, an instance of the HybridDictionary class, and that's where we'll store the singleton instance. Here's a sample code to implement the Singleton-per-Page pattern:

public class SingletonPerPage
{
    public static SingletonPerPage Current
    {
        get
        {
            Page currentPage = HttpContext.Current.Handler as Page;      

            if(currentPage == null)
                throw new NullReferenceException("The page is null");

            return (currentPage.Items["SingletonPerPage"] ??
                   (currentPage.Items["SingletonPerPage"] = 
                    new SingletonPerPage())) as SingletonPerPage;
        }
    }
}

From a mere performance point of view this seems a slightly better solution compared to the singleton-per-request, since the Items properties of the HttpContext and Page classes make use of different bags for storing data. As I said, the Page class uses HybridDictionary, a dictionary which internally makes use of the lightweight ListDictionary class until the number of items stored reaches 9, when it switches over to a HashTable; HttpContext instead makes directly use of a HashTable. What's essential here is to be aware of the scope of the stuff you place there.

Using an HttpModule to detect page refresh

simoneb — Sun, 07 Jan 2007 00:21:00 GMT

While reading through the excellent ASP.NET book written by Dino Esposito I've come across a solution to detect page refreshes using an HttpModule. When I read it I couldn't understand a line of the code and it seemed to me that it couldn't work, so I started experimenting with it using the code available to download from MS Press website. I discovered that I had been a good runtime, since the code in fact doesn't work very well. In particular, if you have more than one page opened concurrently you can see that the code behaves strangely, and the same can be said for the other couple of methods I've found out there (by Joel Thoms and Jared Evans), which are mostly complex and unreliable.

I started thinking about it from scratch and the question was: "How do I distinct between requests caused by the F5 or refresh button and normal requests?" That's not an easy question, since the stateless nature of the HTTP protocol doesn't allow to maintain state across requests, and maybe it has no answer, or, if you prefer, "You can't".

So I restricted the problem; do I care about all requests or just the ones which POST something to the server? I think most people care just about POST requests, those which usually perform some kind of action on the server, like working with database data, and the same actions we don't want to see duplicated because of a page refresh.
Therefore the question became: "How do I distinct between POST requests triggered by the interaction with the page and those fired by the F5 button?". Luckily, in this case the DOM comes to help and a simple detail becomes the lifesaver. When you POST something to the server in the canonical way, the onsubmit event of the page form is fired; when you try reposting the same page to the server using F5 that event isn't fired.
As far as I know this mechanism depends on the browser implementation, but I've tested it in IE7, FF 2.0.1 and Opera 9.10 and the all behave the same.

This is the trick:

Each time a page's form posts back we create on the client side a Guid (using Javascript) which is then assigned to a hidden field, so that when the request reaches the server we can retrieve that value. This means that if a page posts back via F5 it keeps the Guid which was generated during the last submission, since the onsumbit event is not fired again and thus no new Guid is generated.
On the server we keep a queue of all the Guids we have retrieved from the pages which posted back. Each time a page posts back we retrieve its Guid reading from the hidden field, and if it's already in our queue it means that the page is a refresh.

That's simple, isn't it? Much simpler than all the methods which rely on Session state, Cookies. HttpContext.Items or whatever.

Implementation details

The idea seems good! Let's write it in code. We need to intercept requests, so we need an HttpModule. Each time a request arrives we add dynamically a HiddenField control to the page to keep our Guid value and then retrieve the Guid of the page (if one exists). If the Guid is in our queue then the page is refreshed, otherwise it's a good clean postback. The only place where we can store this boolean value is the Items collection of the current HttpContext, so that it can be retrieved in the page code.
The queue where all the guids are kept resided in memory, so we need a way to define how many elements it can contain at most. It obviously depends on how many visitors the website has. The default value is 100; it means that if I do a postback, wait a bit before pressing F5 and during that time 100 genuine postbacks are fired by other users (or by myself but in another window/tab/browser) then my refresh is considered as a genuine postback because its Guid has already been dequeued (and I don't want this to happen!).

Setting up

Place the assembly binary in the Bin directory of the website.
Since implemented as an HttpModule it has to be registered in the web.config file:

<httpModules>
    <add name="RefreshModule" type="BusyBoxDotNet.RefreshModule"/>
</httpModules>

You can configure the size of the queue to fit your needs, otherwise the default value will be set to 100:

<configSections>
    <section name="refresh" type="BusyBoxDotNet.RefreshSection, RefreshModule" />
</configSections>

<refresh queueSize="50"/>

Using

The IsRefreshed key of the Context.Items collection is set during the page PreLoad phase, so it can be read starting from the Load phase in the page code, otherwise it will always return false.
To retrieve its value just check the Context.Items["IsRefreshed"] boolean value, or use the base page class I've written for those who love strong typing, which exposes the wrapper boolean property IsRefreshed.

NOTE: if you missed it before, remember that IsRefreshed (or Context.Items["IsRefreshed"]) notifies you when a POST request is refreshed, not a GET request. That is, if you write a url in your browser's address bar and then push F5, IsRefreshed will be false, because they are GET requests. Usually you care about detecting POST requests being refreshed, but in case you need GET requests refresh detection so this method doesn't work for you.

Attached to the post is a demo website which includes the binary.
The source code of this and all my other works is on the subversion repository of my main project: http://sourceforge.net/projects/busybox

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.

The ASP.NET Singleton-per-Request pattern

simoneb — Mon, 21 Aug 2006 04:58:00 GMT

Lately I needed to have an instance of a class to be unique for a certain amount of time, that is, one instance only of that class should exist for that time interval in my app domain.
In these cases what comes to my mind is the Singleton Design Pattern, which imposes that one instance only of a class can be loaded into an app domain and is alive as long as the app domain is.
My problem was that I needed that object to be unique only for a small time interval, which later I identified as being the life of a single request. That's when I recalled of a very useful IDictionary collection whose lifetime corresponds to the request-response cycle, and where you can store items which are then available during all the stages of the pipeline. This object is the Items instance property of the HttpContext class, and is defined as following:

System.Collections.IDictionary HttpContext.Items

Let me say it again: into this collection you can store items that are then made available during all the request-response process, and are unique to that particular request-response. To enfore this and make it even clearer, the description of this object as given by the intellisense is:

Gets a key/value collection that can be used to organize and share data between
an System.Web.IHttpModule interface and an System.Web.IHttpHandler interface
during an HTTP request.

You understand how powerful this object is, and the ASP.NET engine uses this mechanism itself to mantain some state information, like the session id and something more.
Going back to my problem, what I wanted to achieve is a lazy load (created only when necessary) instance of a class being unique to my request, so I came up with this code.

public class SingletonPerRequest
{
    public static SingletonPerRequest Current
    {
        get
        {
            return (HttpContext.Current.Items["SingletonPerRequest"] ??
                (HttpContext.Current.Items["SingletonPerRequest"] = 
                new SingletonPerRequest())) as SingletonPerRequest;

        }
    }
}

which can be used calling the static Current property of the class. What this code does is check if an instance of the class is already in the Items collection. In that case, it returns a reference to that instance, otherwise a new instance is created and placed in the Items collection, so that the next time it is requested during this same request it's already there.
Note that here we don't need any synchronization mechanism, since a single request is not executed concurrently by more than one thread.

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.