Dukes' Web Development Postings

ReSharper is an irreplaceable tool in my coding arsenal.  One of its myriad of amazingly useful tools is Live Templates, a much enhanced version of Visual Studio’s code snippets.  When defining a live template you can specify a number of placeholders in the template, and choose from a variety of “macros” to determine how ReSharper fills that field in.  We use this to automate putting the current year number and filename in the copyright header in new files, and to have ReSharper suggest appropriate types or variables names.

In a new template that I was writing, I wanted to be able to choose from a list of SQL Server types.  Looking through the list of available macros, I was pleased to see that there was an option for a comma-delimited list of options.  I started creating this list, and then came across decimal(18,2) as a type, and realized quickly that it was coming as two options in the list (decimal(18 and 2)), so I started looking for a way to escape that comma.  After finding nothing in Google with a couple of searches, I tried a few guesses.  It only took two guesses to find that you can use a backslash to escape the comma, ending up with decimal(18\,2).

Thanks, JetBrains, for ReSharper and its ability to do what I need it to do without even trying.

Saturday, October 2nd was the Day of DotNetNuke in Chicago.  A number of us from Engage attended and spoke.  I gave two presentations, which are now available on SlideShare (linked below).  I’ve added some notes (be sure to click the “Notes on slide 1” tab when viewing on SlideShare) to give context if you weren’t able to attend the session.

Considerations with Writing JavaScript in your DotNetNuke^® site

Packaging DNN^® extensions

Overall, we definitely were glad to participate in the event.  The logistics were pulled off excellently (you certainly couldn’t tell that none of the organizers had organized an event of this magnitude before).  I was also great to see the number of community leaders that were presenting and available.  It really was a treasure-trove of DNN knowledge.

Nik Kalyani, the keynote speaker, did a great job of emphasizing the role that the community needs to play in guiding the development of DNN.  A lot of us walked away excited about what we could contribute to move the community and platform forward.

Nik introduced the concept of a DNN Meme.  This is an idea about DNN that catches on with the community in a way that it cannot be ignored.  The basic idea is that if an idea is too good to resist, we need to share it so that something actually happens with it.  Nik suggested that we use the hashtag #dnnmeme on twitter, and post bigger ideas to dnnmeme.com (via emailing post@dnnmeme.posterous.com).  I’m not sure that the “DNN Meme” name is going to take off, but I can definitely get behind getting our ideas out there, gauging community interest, and pursuing the things that we all know that DNN needs.

In Nik’s session at the end of the day, we discussed a couple of things (documented on dnnmeme.com).  The biggest of which was the need for module developers to get together and see where we can come to some agreements on how to implement our modules (whether that be a more standard set of markup/CSS, new features in the DNN core, or an agreement on how to implement large amounts of settings).  Based on that discussion, Will Morgenweck created the DotNetNuke Module Standards project on CodePlex, where we can start the discussion of standardizing our approaches to modules.

If you are a module developer, we’d love your input on the patterns that you use when developing modules.  Specifically, where you find yourself working around what the core provides, or find that the core doesn’t provide anything to support what you’re doing.  We’ve gotten the discussion started with what we do and would like to do, but we need more voices so that we can come up with some real consensus on how to reconcile our different approaches.

This past week was the St. Louis DotNetNuke Hackathon.  This was a competition for DNN developers to create a mobile application which interacts with DNN.  We had one week to create something worth showing off.  So, I, along with another developer at Engage, Abadi, took the challenge.

Abadi has experience developing games for Android phones, so we decided to write a Java application (rather than using Appcelerator’s Titanium Mobile product) which could connect with the Messaging feature introduced in DotNetNuke 5.3.  If you have a DNN 5.3+ site, you’ll see a module titled “My Messages” on your profile page, which you can use to send messages to other users on the site.

As we were brainstorming what would make a good DNN mobile application, Rich Campbell, Engage’s president/CEO, tossed out the scenario of being notified of a football game being rained out.  We all decided that going mobile would add a lot of value to DNN Messaging, and My Messages Inbox was born.

Before I go into the technical details, let me first point out that the Hackathon is currently in the voting phase (until tomorrow, August 31st, at 6:00 Central), so head on over to view the entries, and vote for your favorite!

So, technically, the application comes in two parts.  I worked on an extension to your DNN site that enables communication with the Android application that Abadi wrote.  The extension contains a WCF web service which allows a user of the site to authenticate and then get a listing of their messages.  I’m very happy with how cleanly I was able to interface with the Messaging code (thanks, in large part, to the separation enforced by use of the Web Forms MVP pattern in the Messaging module).  This was also my first big leap into using WCF, so it was great to be able to figure out how to integrate it with DNN without needing tons of configuration and setup (with much thanks to Justin Etheredge’s timely blog post on the subject, as well as Steve Fabian’s WCF DNN Security post).

Abadi was a wizard at figuring out the best way to integrate with the Android interface.  He’d never worked with web services in Android before, so we had to catch up on how to get connected, how to parse JSON (and, especially, dates in JSON), and how to layout a standard interface.  The most awesome feature of the entry, I think, is the ability for our application to check for new messages in the background, while you’re using other applications on your phone, and receive a notification (just like email).  Since we were using Android itself, and not the common iPhone/Android abstraction that Titanium provides, we were able to take full advantage of the multi-tasking built into Android to make that happen.

Overall, it was a lot of fun, and a great learning experience all around.  Many thanks for Pat Renner for his management, guidance, ideas, and filming (that’s his voice in the YouTube video), and for Anthony Overkamp for the great images we used on the Hackathon Entries page and the Codeplex site.  Remember to go to the Hackathon page and vote!

On Twitter yesterday, Brad Abrams mentioned String.IsNullOrWhiteSpace, to awesome new helper to replace compliment String.IsNullOrEmpty.  I'm really excited to get to use this, since it seems like it makes more sense in the majority of cases than IsNullOrEmpty.

But that's not the point of this blog post.  After Brad made that comment, Josh Einstein replied and asked why Enum.HasFlag wasn't getting any love, and I have to agree, having not heard this mentioned before.  Just the other day I was working with a GridView and had to check the rows' RowState, which is a Flags enum.  After having to remember the right way to check a flag enum, I thought to myself, "why isn't this part of the framework?  I shouldn't have to do bitwise logic to check this..."  That's why I get excited learning about this new method in .NET 4.)

However, as I read the MSDN documentation for the method, I realized that it has the same pitfall that I ran into when doing it myself.  Basically, the right way to check whether a flag is set is to use the bitwise AND operator (&) on the value and the desired flag, and then compare that to the desired flag, i.e. (value & DataControlRowState.Alternate) == DataControlRowState.Alternate will check if value contains the Alternate flag.  When Enum.FlagValue is zero (i.e. DataControlRowState.Normal), then this algorithm always returns true, regardless of the value you are checking, which is rarely the result that you want.

So, the result is that Enum.HasFlag is a great addition to the framework (so long as people know about it, so that it gets used in place of the old manual method), however, you have to know what you're doing, and specifically you will need to do something different when you're checking against an enum value that is zero (the best check in that case is probably just equality, i.e. value == DataControlRowState.Normal).

Earlier this week, Shaun Walker, [DotNetNuke]'s Co-Founder and Chief Architect, caused a bit of a ruckus in the blogosphere/twitterverse with his blog post ASP.NET MVC and DotNetNuke.  I think many disagreed with his representation of ASP.NET MVC, whether or not they agreed with the actual point of the blog post (to announce that [DNN] is not going to be ported to ASP.NET MVC).  Unfortunately, much of the discussion became a little too heated, so I think we are all glad to be able to move on to more productive discussions now that the backlash has died down some.  Charles Nurse has led the way forward for productive discussions by blogging about his recent work integrating an ASP.NET MVC application into a [DNN] site as a real [DNN] module.  It's very exciting stuff, even with the list of known issues.  Hopefully we can move forward on this front and allow both WebForms and MVC-style development within the [DNN] ecosystem, making it richer for its diversity.

Also, if you are interested in learning about MVC, TekPub's Rob Conery has donated coupons for their ASP.NET MVC series to [DNN].  All you need to do to get some free (excellent) training on ASP.NET MVC is to blog about [DNN] and leave a comment about it.

One of the biggest gaps between developers and designers at our company is the disconnect between ASP.NET web controls and HTML markup.

Our designers are very comfortable working in HTML, and passionate about using semantic markup to communicate the structure and meaning of web sites.  Our developers, on the other hand, understand the functionality of most of the web controls that ASP.NET provides, but are usually more concerned with the functionality that they provide, rather than the markup that the produce.

To help begin bridging this gap, I created an interactive guide to the markup produced by the various standard ASP.NET web controls.  You can take a look and contribute at the repository on GitHub.

Right now, when you pull the files down from the repository, you'll have a control with the actual guide on it, another control which you can register with [DotNetNuke] to make it into a [DNN] module, and a plain ASP page, Default.aspx, which you can use to view the guide outside of [DNN] (Phil Haack's Web Server Here shell extension might be useful for viewing that page without having to setup any real website).

The guide consists of three columns in a table.  The left column contains some ASP.NET markup.  The right column contains the rendering of that markup.  The middle column contains a list of the HTML elements and their attributes which the control renders.  The contents of the middle column are dynamically generated when the page loads, using jQuery.  This means that the results are always accurate for your current situation (whether you're using a downlevel browser, ASP.NET 4.0's new cleaner markup, the CSS Friendly Control Adapters, or just want to see how the control tree on your site affects the rendered Client IDs).  Also, when you hover your mouse over that middle column, the entirety of the HTML is displayed in a tooltip.

At this point, I think the guide is useful and helpful, but there are definitely improvements to be made.  Firstly, some styling, so that it's not painful to the eyes to find this information.  Secondly, some of the more complicated controls could probably use some more examples, and the controls that aren't in the "Standard" toolbox also need to be represented (e.g. GridView, ListView, etc).  Also, some sort of navigation or searching, especially with the addition of more examples.

If you find this useful, leave a comment, and consider forking the repository on GitHub and implementing an extra example, or a new feature.

Hopefully this can help us all get on the same page, and know when an <asp:Label/> is a <label> and when it's a <span>.

Earlier this year, my wife, Nikki, and I started her own photography business, Purple Lemon Photography.  We've had a lot of fun getting setup and figuring out how to run a busines, as well as seeing how people respond to the images that Nikki takes.

Tonight marks a special night for us, and myself especially, because we finally launched her public facing website!  Go take a look.  This was a lot of fun for me, since it was the first site where I've been fully responsible for most every aspect.  I've had fun figuring out how to mold HTML & CSS in ways I'd never tried before, and am still working through getting everything out of IIS that I can.  I've also used the opportunity to start getting familiar with Git (aided by Jason Meridth's introductory Git for Windows Developers series and a free Unfuddle account).

We still have a lot of ideas for improvements that we'll be rolling out over the next weeks and months, but we're glad to finally have somewhere nice to point people.  Let us know what you think!

One concept that I don’t see people using, understanding, or even being aware of much in .NET development circles is the Embedded Resource.  Declaring a file as an embedded resource within your project means that it will be compiled into the assembly, so that you don’t have to distribute the actual file with the assembly.

In our projects, we embed many of the resources that we use, in order to reduce the number of files that we have to distribute.  The biggest use of this policy is towards JavaScript files.  We use a lot of JavaScript in our modules, but we don’t have to distribute any .js files, they all live in a .dll.  This also makes it a lot easier to automatically minify the JavaScript files when building, but that’s a story for another time.

Down at the end of this post, I’ll also talk about embedding files that are intended to be loaded in memory to be used, rather than accessed through the web.  In that case, it’s much more convenient to already have the file in the assembly, rather than having to search through the file system for it.

So, how do you invoke this magic to place regular, non-compiled files into your compiled assemblies?  It all starts, as many things do, in Visual Studio.  With the file added to your project, take a gander at the file’s properties  (by pressing F4 if you don’t have some crazy keyboard setup).  The property page for a file is rather short, and we need to look no farther than the first property of the file to accomplish our purpose.  The Build Action property of the file is usually set to Content, meaning “[the] file is not compiled, but is included in the Content output group.”  By changing this to Embedded Resource, “[the] file is embedded in the main project build output as a DLL or executable.”  This is most of the magic we need, but we’re not quite done yet.

Since this is a JavaScript file that we’ll want to access on the web, we need to tell the assembly that it’s okay to give the web access to the file.  If you miss this step, you’re going to get an error page instead of JavaScript when you try to reference it (and everything that depended on the script will be throwing errors both left and right).

So, to accomplish this, we need to add an assembly-level attribute.  These usually live in the AssemblyInfo file, which, by default, is under the Properties folder of your project.  After adding a using/Imports of System.Web.UI, we can add the following WebResource attribute to our project (given a default namespace of “Engage.Demos.EmbeddedResources” and the file “swfobject.2.1.js” placed in a “JavaScript” folder):

    [assembly: WebResource("Engage.Demos.EmbeddedResources.JavaScript.swfobject.2.1.js", "text/javascript")]

So, this brings us to the issue of naming.  The file is assigned a name when it is embedded into the assembly.  This name is the default namespace of the project, plus the folder path, plus the file name itself, all joined together with periods.  One important thing to note is that VB.NET assemblies do not have default namespaces (they have root namespaces, a source of continual confusion and frustration for C# programmers who switch back and forth).  Therefore, the resource names just start with the folder path.  In this case, the name would be "JavaScript.swfobject.2.1.js".

Now that we’ve handled that, how do we actually get the script on the page?  The same way you get any script on the page, you use the ClientScriptManager (you do use the ClientScriptManager to manage your client scripts, right?).  This is accessible through the page’s ClientScript property, from which you can call RegisterClientScriptResource (when using an embedded resource, you don’t get to choose whether it is a “startup script” [added at the bottom of the page] or “script block,” [added at the top¹] it’s always a “block”, so you can’t use the ClientScriptManager if you want to use this technique for a “startup script”).

The RegisterClientScriptResource method takes a Type and the name of the resource.  The Type, as far as I can tell, is just used to provide an additional “namespace” for the include, i.e. trying to include the same resource twice with the same Type will result in only one script being added to the page, but if they have different Types specified, the script’ll be added twice.  So, in our case (working with a class called DemoPage), this looks like the following call during the page’s Load event:

    this.Page.ClientScript.RegisterClientScriptResource(typeof(DemoPage),
                                                        "Engage.Demos.EmbeddedResources.JavaScript.swfobject.2.1.js");

One notable time where this won’t work is when you are trying to add a script to the page during a partial postback.  In truth, you’ll probably have the same issue whether you’re embedding your JavaScript or not, but either way, the fix is to move from the ClientScriptManager to the ScriptManager (great naming for these two, don’t you think?).  For embedded scripts, use the static RegisterClientScriptResource method like you would with a ClientScriptManager instance, otherwise, pick between RegisterClientScriptBlock, RegisterClientScriptInclude, and RegisterStartupScript.  When using the ScriptManager methods, you’re required to add a line to the end of your script to notify the manager control that you’re script is done loading, but if your script is embedded into the assembly, it can do it for you and you’ll never have to wonder why the stupid thing isn’t working the way (you think) it’s supposed to work.

If you have a case where you want to add a reference to an embedded script but the provided methods don’t work for you, you can use the ClientScriptManager.GetWebResourceUrl method to get a URL to that resource that you can use anywhere URLs are accepted, worldwide.

Now, finally, what about files that aren’t JavaScript?  What if you have an XML schema that you want to load up to valid XML against?  Or what if you have an image that you want to add as a watermark to user-uploaded pictures?  In those cases, when you really want to load up the file within memory, rather than expose it to the web, the workflow is rather different.  At the most basic level, you’re going to use Assembly.GetManifestResourceStream to get a stream of the file.  The easiest way to get an assembly reference is to start with the type you’re in, and then access its Assembly property, like so:

    using (var schemaStream = typeof(DemoPage).Assembly.GetManifestResourceStream(typeof(DemoPage), 
                                                                                  "Schemas.DemoSchema.xsd"))
    {
        // validate something...
    }

One further note about naming.  In this situation, the first Type parameter is used to lend its namespace to the resource, so, in this case, since the full name of DemoPage is Engage.Demos.EmbeddedResources.DemoPage, I don’t have to specify the Engage.Demos.EmbeddedResources part of the resource’s name. 

From there, you can go wild, doing whatever you want to do with the stream of your file.

Hopefully this clears some things up, and hopefully introduces you to a tool that you may not have known about or may not have known enough about.  Make sure and let me know if you have any questions, or see any better ways to go about this stuff.

¹ The ClientScriptManager actually only messes with the form element on the page, so it’s really the top and bottom of the page’s form that’s where the scripts get placed.