My Resume

  • My Resume (MS Word) My Resume (PDF)


Affiliations

  • Microsoft Most Valuable Professional
  • INETA Community Champion
  • Leader, NJDOTNET: Central New Jersey .NET User Group

Sunday, April 20, 2008

Central New Jersey MS Certification Study Group

We had our inaugural meeting of the "NJDOTNET Spring '08 MCTS Study Group" this past Thursday, and I thought it was a wild success!  I had just under 30 people register (express interest) over the past few weeks, about 5 email me before the meeting to let me know that they wouldn't be able to attend this first one (but, yes, they are very excited!), and an even 20 people actually show up.  I sure am happy with those numbers!  My favorite part about the whole thing is the positive energy and just raw desire to dive deep into .NET that all of the members are showing.  It really is a great thing to know that you'll be able to meet up with these people (and this energy) for at least a few hours every week.

For those of you who haven't heard through the various other channels, we can still squeeze a few more members in.  So, if you're interested in getting your MCTS certification in Windows Forms or ASP.NET, please feel free to let me know.  We meet every Thursday night at 6:30 PM at the Infragistics headquarters just outside of Princeton, NJ.  Check the NJDOTNET Website for more information, including directions.

Using Plain Old WebForms Controls in your ASP.NET MVC Views

Still wanna use all those nifty controls that you had access to back when you were developing in the Dark Ages of WebForms?  Well, you can!  ... sort of.

If you're like me, one of the first things you did when you started writing your first ASP.NET MVC app was say to yourself, "Hmmm... wonder what happens when I drop this TextBox control on my View?"  I don't think anyone is surprised when you see something along the lines of "[...] type 'TextBox' must be placed inside a form tag with runat=server."  I'm sure most seasoned ASP.NET developers have gotten this error at some point in your coding life when you're writing a new page from scratch and forget to wrap your page in that oh-so-important "<form runat='server'>" tag.  What you may or may not know (I didn't realize this until I got into MVC Land and tried it) is that not all tags have this constraint.  Tags such as the Image tag (and a handful of others) are just there to generate markup and don't really care whether or not they're in a form.  Feel free to litter your pages with them and they should do some pretty good work for you.  Unfortunately, tags like TextBox and his cronies really like the secure feeling they get by having that nice warm <form> tag wrapped around them.  And - after all - things like <input> tags are "form" elements, right?  It's understandable that they need the <form> tag to live.

...or do they?

The short answer is, "Yes, they do."  In order to use these controls - the visual representatives of the Web Forms Way - the way that you're used to, they do need that <form> tag and all that it entails (like ViewState - ech!).  However, that answer simply wasn't enough for me.  When I switched over to ASP.NET MVC, I knew that I was going to lose a lot of the convenience that WebForms and ViewState gave me... but I also knew (or at least hoped!) I'd be getting rid of the problems that came with it, too.  So, I'm already in that mindset when I'm working on my MVC app, but I get frustrated when I have to copy code all over the place to generate "static" HTML like image buttons and the like.  Like I am with the MVC framework in general, I am more than willing to give up the advanced features of the Web Forms controls (like event handling and the like) if only I could just continue to utilize the markup they generated so well.

So, my mission was simple: I needed a way to get rid of that error message and allow these controls to generate the HTML I so desperately missed.  And - lucky for me - I found a way!  here's the magic:

Avoiding the Error
    public class BaseViewPage : ViewPage
{
public override void VerifyRenderingInServerForm(Control control)
{
return;
}
}



That's it.  Just overriding "VerifyRenderingInServerForm" on the ViewPage keeps the error from occurring and lets the controls try to output the markup they are tasked to. 



I'll be the first to say - this works with varying degrees of success, depending heavily on which control you're trying to use and how you're trying to use it.  But, hey - anything is more than you had before, right?  It's a neat little trick that may end up saving you from having to duplicate some of the work that those bright folks at Microsoft have already done for you.  And, it may just help you make your markup a bit cleaner.

Tuesday, April 15, 2008

Unit Test Project Structure

I recently came across Phil Haack's interesting blog post and associated poll about structuring your unit test projects - do you have separate unit test assemblies or not? - and was not entirely surprised by the results.  They were more or less in line what what I'd expect.  At the beginning of my TDD "career" I'd actually considered for a brief second whether it'd be better to put my unit tests in line with the code they're testing (not "inline" as in the same file, but close) or in a completely separate assembly.  After a few minutes of thought, I came away with what it seems most other people come away with - and emphatic "NO!"  I'm honestly left wondering - and I don't mean any disdain, but - what are these 8% of "Yes" voters are thinking!?  Is it laziness, or some other motive that I'm not getting?  Really - I'd love to know!

Sunday, April 13, 2008

NHibernate Lazy Loading Snafu

Oh, man did I get thrown for a loop last night... 

I've got a test project I'm working on that uses NHibernate.  In this project, I've got a Building class, which has an Address attribute, of type Address, for which I overrode the ToString() method like so:

image

I've also got a page that grabs a bunch of Buildings from the NHibernate session and binds them to a Repeater.  For my initial tests, just to see if everything worked, I just bound right to the Address property on the Building in my markup and everything worked fine.  That is, the address printed out just as it was supposed to - in just the right format I'd set in the ToString() overload.  Then I went to refactor the page and break the address out into it's individual bits to show them in a slightly different way...  and was greeted with a null reference exception!

I was troubleshooting for a good half hour or so before I came across this dialog:

image

WTF!?  How in the world could my ToString() overload be generated correctly when all of its properties are null!?  And then I realized - lazy loading!  D'oh!  I went to my NHibernate mapping file for the Building class and updated it, adding the "lazy='false'" attribute, so it ended up looking like so:

image

and now everything works like a charm!  This fix doesn't really bother me because the Address probably shouldn't have been lazily loaded to begin with, but I never did end up figuring out how exactly that AddressProxy was able to give info to my ToString() override but was not nice enough to populate my properties for me!  Looks like I've got to learn about lazy loading and NHibernate Proxy classes!

If you've got some ideas on how this happened, please leave a comment - I'd love to know!  But for now, I'm just happy I figured it out!