A Rose by Any Other Name...

by coatta 2/25/2012 10:22:00 AM
Actually, in coding names do matter. A few months back we moved our application from one hosting provider to another and everything worked except OpenID authentication. In fact, we had both applications running simultaneously and talking to the same OpenID provider, and one worked and the other didn't.
We were actually getting an error message that indicated a packet had been rejected due to a problem with a "nonce". Here's a definition from Wikipedia: nonce is an arbitrary number used only once to sign a cryptographic communication. That pretty much matches my notion of what a nonce is as well.
I figured this must be due to some peculiar packet duplication that was causing a nonce to be used twice. Seemed like it should be easy to sort out with a network trace, so we slapped one on and collected the traces. They were isomorphic until they weren't. When OpenId failed, it appeared to be because they simply just stopped talking.
OK, so time to dive into the code.
We trace through the code looking for where the nonce was processed. I kept expecting to run into a table that preserved nonce values so the code could check if a nonce had been seen more than once. I couldn't find one. Eventually we got to exact place in the code where the error originated. The "nonce" was actually a timestamp, and the error was because of clock drift between the OpenID provider and the new server we were running on.
Needless to say, this would have all been a lot more straightforward if they had used the right word! An error message along the lines of "the timestamp on message X is out of date" would have made this a lot easier to figure out. Having the field called "timestamp" rather than "nonce" would have made the code a lot easier to understand.

Reusable Domain Controls in MS MVC

by coatta 2/2/2012 9:39:00 AM

Most of the example code for MVC that I have seen out there isn't well-suited to creating re-usable UI components -- in particular components that are application specific, but may want to be used in multiple contexts within the applications. For example, a component that displays a list of customers might be used on a number of different pages within the application. But it is possible to build re-usable components of this sort, you just have to follow a few rules which help ensure that the component is not coupled to the page that it resides on.

So, the rules are:

  • View models should always include a field for the ID of the target element
  • Always use RenderPartial() - Links need to be rendered with Ajax.ActionLink()
  • Forms need to be rendered with Ajax.BeginForm()
  • Forms/Links need AjaxActions with the target element set appropriately

Components always need to render into a specific HTML element on the page. The container (the page using the control) determines where it wants the control to display and passes this in as a parameter. The component thus knows where it should be rendered, but is ignorant of anything else on the page. If the component needs to include other components as part of its display, these should be rendered via Html.RenderAction(). In this case, the component is acting as the container, and so it must determine which HTML element the sub-component will render into. Obviously, this should be an HTML element defined in its cshtml file.

In general, components should not include links that would navigate to completely new pages. Instead, these links should simply route back to controllers/actions that have been given to the component as parameters -- it is the container's job to deal with global navigation, not the component.


<<  June 2017  >>

View posts in large calendar


My opinions are my own, but you can borrow them if you like.

© Copyright 2017

Sign in