Switcheroo

Google usually has pretty clean user interfaces.  I saw something in Google contacts that I thought I’d like in something I’m building.  The form’s input fields are hidden until you click on one of the labels.  The label magically changes to a textbox or a dropdownlist or whatever.  So why don’t I have it in my toolbox??  Now I do. https://github.com/jvandyne/switcheroo

Using good jquery plugin form we’ll create an object literal

(function ($) {
    $.fn.switcheroo = function (options) {

        var self = $(this);

        var methods = {
            tb: function () {
                self.click(function () {
                    var container = self.parent();

                    // get remove the current control
                    self.toggle();

                    // replace with textbox
                    var tb = document.createElement('input');
                    tb.type = 'text';
                    var textBox = $(tb);

                    tb.value = self.text();
                    container.append(tb);
                    $(tb).focus();

                    $(tb).blur(function () {

                        self.text($(this).val());
                        self.toggle();
                        $(this).remove();
                    });
                });
            }

 

Textbox was fairly easy as we have all the info we need.  For the drop down list, we need to get the items for the list passed in via the options literal that we’ll get passed.

 ddl: function () {
                self.click(function () {
                    var container = self.parent();

                    // remove the current control
                    self.toggle();

                    var dl = document.createElement('select');
                    var $dl = $(dl);

                    // build out ddl
                    if (typeof (options) != 'undefined' && typeof (options.items) != 'undefined') {
                        $(options.items).each(function (ndx, data) {
                            var li = document.createElement('option');
                            li.selected = data == self.text();
                            li.value = data;
                            li.text = data;
                            $dl.append(li);
                        });
                    }

                    container.append(dl);
                    $dl.focus();
                    $dl.blur(function () {
                        self.text($dl.val());
                        self.toggle();
                        $dl.remove();
                    });

                    $dl.change(function () {
                        self.text($dl.val());
                        self.toggle();
                        $dl.remove();
                    });
                });
            }

 

A little more logic to figure out which to call and we’re on.

 if (typeof (options) == 'undefined' || typeof (options.type) == 'undefined') {
            methods.tb();
        }
        else {
            if (options.type == 'dropdownlist') {
                methods.ddl();
            }
            else {
                methods.tb();
            }
        }

Comments

WatiN Alleviated My Aggro

One of my biggest aggros when building web apps is the constant logging in, clicking that test row in the grid, and clicking on 55 things to get to the thing that I’m actually building.  So why not automate that thing that drives you nuts?  Automating a browser to enter whatever I want and to click where I want is perfect for this.  Launch my web app, do something minor, and let the thing drive itself to where I need to be to make sure that new super awesome thing I just built actually works as I expect.

Keep in mind that I’m not trying to build out a full on testing framework or really anything that should be useful outside the context of exactly where I am in the process of building.  I don’t need another distraction or thing to get aggro about.  I just want something to help make this easier.

There are few different options in the browser automation space.  WatiR, Visual Studio Coded UI tests, Selenium, hell even some wicked powershell will do this.  I’ve built things with WatiR before, but I don’t want the slowdown of installing the ruby runtime and then another distraction as I try to remember the ruby syntax.  I’m building an ASP.NET web forms app, so why not something in .NET.  That’s WatiN.  No special runtimes or different languages to remember.  Only a simple dll to reference from a disposable command line app.

 

Step 1 – Get WatiN

Cruise on over to the official WatiN download site.  Get zip.  Unpack.

 

Step 2 – Create Console App

Start another instance of Visual Studio and create a console app. 

Add a reference to the WatiN.Core.dll that we unpacked in Step 1.

Import the namespace into your Main.cs and we’re ready to get into the business.

 

Step 3 – Sling Some Code

The browser is central to automating the browser.  We’ll set ourselves up for maximum flexibility when we try to wire into the browser.  We’ll use IE for everything as it’s typically supported by everything.  (Note: WatiN does support FF and has some support for Chrome)

            string url = "http://localhost:50969/SomeSite/Login.aspx";

            IE browser = null;

            try
            {
                Log("Trying to find a browser to attach...");
                browser = IE.AttachTo<IE>(Find.ByUrl(url), 2);
            }
            catch
            {
                Log("Didn't find one.  I'll try to spin one up.");
            }

            browser = browser ?? new IE(url);

The results of this little bit of business is whatever version of IE launched and ready.  So in my case I can use this if I’m parked at the login already (think about debugging) or if I don’t already have an instance of the browser running at this page, I’ll have one ready.

Don’t worry much about the Log method as it really just wraps Console.WriteLine.  “Log” is a lot shorter on the keystrokes.

 

So now that we have a browser, we need it to start doing stuff.

            Log("I better wait for that to load.");
            browser.WaitForComplete(20);

            Log("Let's see where we are now.");
            var areWeAtItemSelection = browser.Elements.SingleOrDefault(e => e.Text == "Welcome") == null;

            if (!areWeAtItemSelection)
            {
                Log("Ok, that worked.  Now I'll try to select a project.");
                browser.Links.Single(b => b.Text == "Whatever Link Text").Click();

                Log("I better wait for that to load.");
                browser.WaitForComplete(20);
            }
My login page will remember me if I’ve logged in before, so I need to explore some to see where we are in the navigation tree.  I can look for objects in the rendered DOM using linq to objects in conjunction with the properties on the browser object. 

Not only do can I look for things in the DOM, but I can actually do stuff with what I find. 

So I want to click a link? 

browser.Links.Single( link => link.Text == "WhateverText").Click();

Add some text to a textbox?

browser.TextFields.Single( tf => tf.Id.Contains("Some_NonMunged_ID")).TypeText("WhateverText");

 

Step 4 – Compile and Add To Visual Studio

Because we compiled the code into a console app, we can pretty easily slide this guy into Visual Studio as an external tool.  In the Visual Studio menu, hit Tools –> External Tools to find this dialog:

image

 

Click Add and pick out the .exe we just compiled.  I suggest using the Debug folder and leaving it in place.  That way we can change the code, recompile, and not have to tool around in Visual Studio to get the changes picked up.

Now Visual Studio is going to give you some gnarly handle for this thing.  I suggest dropping into the Command Window and giving that thing an alias. 

alias Tools.ExternalTool34 dev_shortCut

 

Step 5 – Chill Your Nerves

Now you’ll be able to run this guy direct from the Visual Studio Command Window by giving it:

dev_ShortCut

Enjoy!

Comments

LANUG March Meeting Scheduled

The Lower Alabama .NET User Group meeting for March 2012 has been scheduled.  Have a look on the event registration for more info.

Comments

JimmyV

test comment

MetaWeblog API and C#

Not a meta post. Sort of a meta-post.  I’ll keep it shortsies.  Many thanks to Shiv Kumar over a Matlus for the platform to get this online.  He’s got a great post on an implementation of the MetaWebBlog API in C#.  With just a bit of EF Code first and some dancing in Visual Studio, I have code online in less than 16 hours of coding.  Bootstrap for the UI and we’re in.

The MetaWebBlog API is nice as it is one of the posting APIs supported by Windows Live Writer. Bear with me as the first couple of posts may deal with the ins and outs of getting a ASP.NET MVC app to handle Windows Live Writer and the Entity Framework Code First bits to make it all run.

I’ll post the code to BitBucket when I have it a little more stable, a little more feature-rich and a lot more secure.

 

For now we’ll do a walk-through.

If you’re still here, go read Shiv’s post first.  Scroll to the bottom for source.  It’s worth it.

Shiv gives us some a nice little domain object to work with. I decorated a couple of classes with some EF Code First attributes.

image_thumb2

 

That done, we need a context.

image_thumb6


Shiv has an interface we can implement. Simple as a right-click on the implementation class to generate the required bits.  I filled them in with some gear to make use of the MyBlogContext from step two.  Nothing sexy, just what you would expect.  (image clipped for brevity).  This is as straightforward is it gets on this code blog.

 

image_thumb14

 

Follow Shiv’s walkthrough for the Global.asax.cs wire-up and you’re in business.

Comments