Category: Programming
You can find several ways of putting some sample text in a HTML input text which fades away when you click it. Some of them use a few lines of javascript, others take advantage of Javascript frameworks, and there are even ways to achieve it using just CSS (but it doesn’t work in IE anyway). But I haven’t found any guidance on doing it to password inputs. So I did it my way.
The problem
The image bellow shows the desired behavior. When you open the webpage you can see an input with a grayed out message on it, telling the user that it is a password field. When you click the input, you can type your password (without being displayed on the page). If you click outside the input, and it is empty, the “Password” message appears again.
The solution I present is based in Javascript, and you can achieve it without using any server-side technology. But since I had to do this using ASP.NET, I’ll show you an example using this technology.
ASP.NET markup
First of all let’s take a look at the markup. I’ve create 2 textboxes, one using the Password text mode, where you can type text without displaying it on the browser, and another one which is a simple textbox with our “Password” message. I’ve grayed out this message and left the input as readonly, since we don’t need its value.
Disclaimer
As you may know I am a fan of C#, and I don’t like VB.NET that much… But since while writing this demo I accidentally created an VB.NET project, instead of creating another one I took advantage of the opportunity to test my VB.NET skills. 
Now I love C# even more…
Javascript Injection
Now lets the the Javascript part of the solution. I use ASP.NET to inject the Javascript into the page in the server-side. I use the Attributes property of the textboxes to set styles and client-site event handlers. In order to hide the real password input when the page is rendered, I set the style attribute of the input element with the value “display:none”. When the fake password input gets focus, the browser hides it, shows the real password input and changes the focus to it. The user doesn’t even notice the input switch, at least if you make sure that the two inputs have the same style. When the password input loses focus (onblur event), if it is empty, the fake input is shown again .
About ClientID
If you are not that familiar with ASP.NET, or at least with client-side scripting used with ASP.NET, you may be wondering that is ClientID. Well, in this example it has the server-side name of the textbox, but when you use User Controls or Master Pages, not always the server-side name of a control is the same that the name/id in the client-side. So the ClientID property gives you the name/id that will be valid while trying to access the control on the client.
What if there is no Javascript support…
Ok, it works fine. And it is pretty clean. But what if by some reason the Javascript is disabled in the client browser? Well… The user won’t have access to the real password input, and will get stuck with the fake input which has the “Password” text and is read only. Even if he could write on it, in the server side the password wasn’t expected from that input anyway. So we need a solution that works even when Javascript is disabled. The user will not have the fancy sample text inside the input, but he will be able to type and send the password to the server. How?
First of all the default visibility status of the inputs will have to change. When the page is rendered the real password input must be visible and the fake one invisible. This way if Javascript is disabled, the user will get a standard password input. After the page is loaded, if Javascript is enabled, we switch the inputs. This switch occurs before the user sees the page, so the final result is the same (while using a Javascript-enabled browser).
The code that the “…” hides is the code of the first VB.NET block.
RegisterStartupScript
This is the method used in order to register script that is supposed to be used in the client side. Page.ClientScript has other nice methods, that allow your to attach onSubmit client-side event handlers and do other client-side Javascript related tasks. Two nice links about RegisterStartupScript are this an this.
You can download the complete source-code of this post.
Today I had to generate files in ASP.NET for download which was supposed to open a save file dialog in the web brower. The file name was based on a title field extracted from a database. The title had spaces which I allowed to be used in the file name (I replaced accents and other invalid characters). In the source code bellow you can see a simple illustrative example.
Perhaps you have noticed that I am generating a plain text file, but I am not using the “text/plain” mime type. When you use “text/plain” the browser automatically knows which application to use for opening the file. If you use “application/octet-stream” instead, the browser uses the file extension in order to find out which is the operating system default program for that file extension. But when you have spaces in you file name as in the example above, you get different behaviours from different browsers.
In Internet Explorer 7, the spaces are replaced by underscores, the the browser recognizes the file extension “.txt”.
If you download the same generated file using Firefox, it cuts the file name ending at the first space. This way the browser considers that your file name is “Just” which has no extension. As a consequence Firefox doesn’t know which application to suggest you for opening the file.
I haven’t tried other browsers, but I took a safe approach. In the server side, while defining the file name I replace the spaces by underscores, this way the download has a consistent behavior in both browsers.
I’ve been writing about Windows Live Agents recently, as you recall. Finally I had the time to leave some more tips.
First Goal: Trigger a notification (procedure that is scheduled to run some time after it has been triggered and which generate messages to the current user) based on a timer event. The notification will be triggered by the current user.
How to achieve this goal?
The code bellow is contained in the Main.ddl file. First of all I declare a global variable to count the number of notifications that were made to a specific user (counter1). Then I declare a procedure that increments the counter, sends the counter value to the user as a friendly message (Notify), and then the magic happens! 
I declare a notification, which is composed by a time interval and the script that will be executed, in the example bellow the time interval is 10 seconds and the script to be executed is a call to the same procedure.
The usage of this recursive approach makes the notification to run every 10 seconds starting from the first call to the Notify procedure. The fist call is made when the user types “notify” and sends this message to our agent. Pretty simple.
Second Goal: Start a conversation with an user
If you want to start a conversation with a user, instead of reacting to the user input, BuddyScript allows you to achieve that objective. But be careful about the License Agreement and make sure you read it before you start developing a agent with this kind of behavior. In spite of this issue I’ll show an example for educational purposes only. 
How to achieve this goal?
While declaring a procedure you can add the startup keyword to run this procedure when the agent is loaded, and you can specify a time interval between calls to this procedure. In the example bellow we have a timer-based procedure running every one minute since the agent is loaded.
To start a conversation with a user you can use the initiate command, which receives a user id (e-mail) and a procedure name to be called (this command can be used for other purposes, check the documentation in MSDN). The engine will start a conversation with the requested user and call the procedure in that user’s context (this way only that user will receive the messages sent by this call). You can initiate conversations with several users, just add several lines like the last one in the example above.
I had a bug in pagination when navigating through categories or dates 
It was due to a customization I made sometime ago to make Wordpress 2.5 work o a IIS web server.
Instead of
$_SERVER[’REQUEST_URI’]=’/page/1′;
It must be
if($_SERVER['REQUEST_URI']=='')
$_SERVER[’REQUEST_URI’]=’/page/1′;
Shame on me
After I wrote about getting started with Windows Live Agents, it’s time to go deeper into BuddyScript, the script language that is used in agents development.
To make your code easier to manage and even to make it reusable you can create package files. These are files that aggregate functions, procedures and data sources that are strongly connected. These packages can be referenced in your scripts using the package statement in the beginning of your script file. To create a new package right click you solution and add a new item based on the PKG File template. The name you give to your package file will be also the package name.
I’ve created a package named DataSources.pkg in which I will write sample code related to data sources usage. You can have several kinds of data sources which are listed in the official documentation. Today I’ll talk about 2 of them. First of all the HTTP data source. It Allows you to download data from the web to use in your scripts. When you declare a data source you must give it a name, return type and if you wish you can add parameters. The example bellow is called GetRSSFeedDataSource, has no parameters and the result type is composed by three fields: title, description and link of a RSS feed entry.
In the data source body I define the source file on the web, the timeout for the HTTP request and the expiration time (for caching purposes). You can even define HTTP headers like the user-agent in the example bellow. Now, lets take a look at the source code.
The data that is downloaded by this HTTP data source is parsed using a simple xml filter (there are other like script-based, XSLT, etc). This kind of filter allows you to filter and format your data source results. In this case you can dive into the returned XML and return particular parts of it. This data source only returns the first entry on my RSS feed, but as you can see in the commented code, you can iterate over the XML using loops.
Now lets see an example of usage of my data source.
I defined a procedure where I call the data source, extract the title and link, and send it to the default output device (which will be the Windows Live Messenger conversation window).
Another nice kind of data source that can be configured and used is based on SOAP web services. The example bellow uses a silly web service that I wrote in .NET that sums two numbers and return the result. This data source has 2 parameters (the operands) that are used as input to the web service. I had to define the proxy parameter (URL of the web service), the name of the operation to be performed (and the respective action) and also the namespace of the web service.
SendSum() is a simple procedure that outputs the sum of two parameters. I’ll use it later. The demo web service is packaged with the rest of the project that I made as an example for this post. Download project source code and take a look at it.
Now that we have defined these two data sources, I’ll show you how to use them during a conversation of an agent with an user. The next lines of code were added to the Main.ddl script file. First of all the the reference to the new package, adding the “package DataSources” line to the beginning of the file.
I have chosen to show the first entry of my blog when the user types “news” into the conversation window. When I recognize that pattern, I call the SendLatestRSSEntry procedure that I’ve defined before.
The second example is great to show how simple it is to recognize patterns and split them into variables. The second expression matches with messages that have the format sum <integer> and <integer>. And store the two integer in two variables: OP1 and OP2, which are used as parameters to the procedure SendSum. You can learn more about matching expressions in MSDN.
Feel free to download the project source code and change it at will.
Recently I’ve been exploring the Windows Live Agents SDK. This framework allows you to develop interactive Windows Live Messenger bots. You may already talked to a messenger bot like encarta@conversagent.com which allows you to search information from Encarta Encyclopedia or if you are Portuguese maybe you use info@destakes.com which gives you news about topics you choose, using data from several news websites.
To start developing your Agent/Bot/Buddy you must have Visual Studio 2005/2008 installed as well as .NET Framework 3.0. More details about requirements can be found in the Installation Requirements web page.
After fulfilling the requirements you can download the Windows Live Agents SDK and install it.
Now you are able to start developing your first agent! Open Visual Studio and open the “New Project” window. There will be a new project template under the “BuddyScript” project type. After choosing the “Windows Live Agent” project template, and typing your project name, you will be prompted for some project settings. You can choose several languages for your Agent and define if it will be able to do some default chatting with users. The only problem I found is that a project created this way is way too complex for a beginner, and if (like me) your target language is not supported or if you want your agent being able just to respond to specific messages, it is pretty difficult to use this template.
After hours trying to find out that was really relevant, I’ve created a Simple Project Template from which I removed a lot of files and settings from the original project. It has only some usage examples in Main.ddl (main BuddyScript file). This project is testable out of the box
The examples I left on the file are pretty simple. They cover how to set an expected input and how the bot is supposed to react. It also uses a package that makes available information about the current user, like his user name. I left some comments in the code. There are a lot of possibilities that can be explored. Something I tried already and that I will share in future posts is the usage of data sources like XML, Databases, RSS, etc. If you are curious about BuddyScript capabilities take a look at the BuddyScript Language Reference.
In order to test your agents you must have a license key, which is easy to obtain from within Visual Studio. Check out How to: Install the License Key.
You can test your agents directly in Visual Studio (Menu View > Other Windows > Conversation Window) with the interface showed bellow.
More information about this kind of testing can be found on the How to: Launch the Agent in the Windows Live Agents IDE article.
Another way of testing your Agent which is much more fun, since you can ask your friends to test it too, is deploying your Agent on the Windows Live Messenger network.
Read How to: Launch the Agent in IM Environment to learn how achieve it.
More detailed information can be found in the Windows Live Agents SDK documentation at MSDN.
Next time I will talk about using data sources, background procedure (code that runs detached from user conversations), notifications (scheduling messages) and how to create pro-active agents that starts conversations instead of responding to user requests.
