ASP.NET

Tourney Pool Manager 2006 - A Quick Update

Joel Ross — Sat, 11 Feb 2006 17:46:00 GMT

Now that the Tourney Bracket Control is out the door, I've shifted my focus to the Tourney Pool Manager.

We have a pretty good idea of exactly what we want to do, but there are a few things still up in the air. Anyway, we do have a few obvious things we're doing. Let's list out the new features we've settled on:

We're implementing the new Tourney Bracket Control. As a part of that, we upgraded to ASP.NET 2.0.
New scoring options. Last year, we added a "underdog" mode - where the TPM would multiply the round's value by the seed. Or you could just go with the round's value. This year, it's much, much more flexible. For each round, you can assign a round value, and then a seeding bonus. You can select to multiply by seed, or you can add the seed. Each round can be different! Ultimate flexibility!
On the heels of the new scoring, we're also going to change the way our scoring engine saves results. Before, it was stored in the database, based on your licenses. We had some issues with that if the site was accessible from an alternate URL - the results could get calculated for a URL you didn't license, resulting in only 5 entries being scored, even if you bought 100 licenses. This year, the scoring is cached in memory by URL, so as long as you are coming from the valid URL, you'll see all results.
A new design. Much nicer! And more flexible. We're using ASP.NET's Themes, so you can just create your own skin, and point the Tourney Pool Manager to use the new skin.
A user page - yes, this means multiple entries per user! You can register once, and submit as many brackets as you want, and track them all in one place - a "Me" page.
Edit your bracket - Not quite as sure about picking IUPUI to the Final Four? Now you can edit your picks up until the first game starts. We've had numerous requests for this one!
RSS for standings. You have to have RSS, right?
Better administration. Upload your custom header directly from the software. An HTML editor for the email message, confirmation message, and the homepage message.

Interested? Want to give it a test run? Well, starting next week, we're running a beta for the Accenture Match Play golf tournament that starts on February 20th. We did this last year, and we are going to repeat it this year, as it went over very well. It gives us a great idea of how things are going for us, because the tournament is a 64 golfer tournament. Sound familiar? Once I get it up and running (we're to a point where it could be put out there), I'll post about it, and we'll get it on the web site. We're still determining what the prize will be, but we're hoping to offer something again this year.

Technorati Tags: Tourney+Pool+Mananger | NCAA | March+Madness | Basketball

Tourney Bracket Control 2.0 And XHTML

Joel Ross — Sat, 21 Jan 2006 20:39:00 GMT

I'm in the process of upgrading the Tourney Pool Manager to .NET 2.0, and ran into an interesting issue with the Tourney Bracket Control. We struggled to figure out what was going on - it was not displaying correctly. The farther you got down in the NCAA bracket, the less aligned it was.

But we knew it could work, because we have it working just fine in our Quickstarts. So I started comparing how the output was different there compared to the page in the TPM. I eliminated the output from the bracket because it was the same. Removing content around the bracket didn't help either.

Then, I tried one other thing: I noticed that in ASP.NET 2.0, the default head tag has an XML namespace in it. So I copied that and the doc type tags over, and suddenly, the rendering worked in the TPM. Even with adding in all of the surrounding content. So I looked at what was different, and it turns out that the upgraded TPM pages had a doc type of HTML 4.0, while newly added pages in Visual Studio 2005 have a doc type of XHTML 1.0 (transitional). That's the difference!

We use a lot of CSS and styles for our rendering now - something we didn't do in TBC 1.0. One of the side effects of that is that we now require XHTML rendering to be used.

And in case you were wondering, using XHTML rendering also allows it to display and work correctly in Firefox, something TBC 1.0 didn't do - it worked, but didn't display the lines correctly. Now, it looks the same in IE and Firefox.

Technorati Tags: Tourney+Bracket+Control | XHTML | DOCTYPE

Tourney Bracket Control 2.0 Released

Joel Ross — Fri, 13 Jan 2006 17:04:00 GMT

I remember sitting on a flight from Detroit to Orlando next to Brian back in June. Well, I sort of remember it. I had been up all night at the hospital with our two month old, who had come down with something. She had a temperature, and with very young kids (less than three months old), that can be very serious. It turns out it wasn't serious, but still not something you mess around with.

Anyway, on the flight, our plan was to talk about how we could simplify the Tourney Bracket Control. We'd already decided that the "1.0 way" wasn't the best we could do and an easier way would be to generate rounds and games based purely on the number of competitors. Now, all we had to do was figure out how to do that! So we spent part of the flight talking about it. And by the time we were done talking, we figured out the logical algorithm to take the number of teams and figure out how many rounds and games you'd need. We even figured out how to determine where the bye games should go.

Then I slept.

We then spent a week at Tech Ed learning about .NET 2.0 and the newly planned features there. We decided the best course for the Tourney Bracket Control would be to make it a .NET 2.0 control. It would be a great learning experience with Visual Studio 2005 and .NET 2.0, and it would ensure that our software was on the latest and greatest platform.

On the way back, we formulated a plan to conquer it. I mocked up a CSS-based bracket layout (which was later partially abandoned) while Brian worked on coding the algorithm.

Fast forward seven months. We're done! We've both been working nights and weekends to get this out, and we're very happy with how things turned out. I'll go into more technical details in posts to come, but for now, it's out there.

So what made it in the final version?

It's just plain easier!: This is the big one! You no longer have to worry about how the bracket should look. Or plan out your groups, rounds and match ups. You just tell it how many teams you want, and it builds the bracket for you.
CSS-based layout: We used to use a table approach, and while tables are still involved, it's not nearly as much as before. There's a few side effects of this change: First, the bracket no longer natively supports nice coloring and filling of rounds with specific colors. Before, you could specify a group or round to have a certain appearance, and that's no longer supported. Why did we think that was acceptable? Because, using your own CSS, you'll be able to go in and create any type of coloring you want (see the advanced styling sample for a look at what's possible now).
Databinding: We wanted to do this with 1.0, but never got around to it. With 2.0, you can now take a collection of competitors, and bind it to the Tourney Bracket Control. The Tourney Bracket Control will then use those teams to create the layout.
Pricing: We now have a professional licensing system instead of our homegrown system we were using. There are many benefits to the new licensing. First, because we can create all kinds of different limits, we are able to offer it to hobbiests for a very reasonable price - pricing starts at $19.99. But, it's flexible enough that it can also handle large installations easily too. The other benefit (and this is for both Tourney Logic and you!) is that licensing is automatic. Before, it required human intervention, and you were gauranteed a license within 48 hours. Now, once we receive confirmation of payment, you'll get an email with the licensing instructions included! I'm being intentionally vague here. It will either be attached or as a download. I'm not working on that part, so I'm not sure.
And more: There are a ton of other new things in this. It's basically almost a complete rewrite, and we fixed everything that we didn't like about the original. It renders faster. It self-validates results. It can even make toast! Ok. No toast. But there's a lot there that's new!

We are missing one glaring feature: double elimination. It's something that everyone's been clamoring for, and it's coming! We're actually very, very close. I had it almost working (the end of the tourney was giving me a hard time - when the losing and winning brackets come back together), but we ran out of time. We backed out those features and solidified the Tourney Bracket Control for release. Double elimination is coming, I promise. But not until this summer.

What timeframe did we run up against? The Tourney Pool Manager. We need to get that upgraded to the new Tourney Bracket Control and get that ready to go. March Madness isn't that far away!

Anyway, after a lot of hard work, it's out! Go download it now - there's a 30 day trial!

Technorati Tags: Tourney+Logic | Tourney+Bracket+Control | server+controls | aspnet

Databound Controls in ASP.NET 2.0

Joel Ross — Sat, 22 Oct 2005 20:12:00 GMT

As I've posted about previously, I'm working through the process updating our server control for Tourney Logic. Well, we made a pretty big design decision. Since the bracket is much easier to configure, we've decided to add databinding - we only have one main collection now, and it's only one level deep, so it makes perfect sense for us to do that. Before, we had two collections, and one was two levels deep, so while databinding was possible, it wasn't really viable to do so.

Having made the decision, I moved forward with what needed to be done. When I started, I had no idea! I'd never built a databound control before, so I started doing some digging. It turns out that ASP.NET 2.0 offers much better support for data bound controls than in 1.1. There's a whole new hierarchy of base classes that you can plug into where you want to. For us, we used the combination of the composite and data bound control - the DataBoundCompositeControl - as our base. It gives the same benefits of the new CompositeControl base class, but adds in the ability to databind.

Once you start from there, adding in databinding is pretty straight forward. It's a general recommendation, but it was especially useful here - if you want to learn how databinding should be implemented, use Reflector and see how Microsoft did it. Anyway, what we wanted was to let people create a collection of teams anyway they want, and then bind that collection to the TBC. Now, the collection could be any collection - not just a true collection, but also a DataTable, etc.

Anyway, databinding is actually pretty straight forward. First, you create properties to hold the names of the properties in the collection. That's confusing! To simplify things, let's think of the DropDownList. You can set two properties besides the datasource when databinding: DataTextField and DataValueField. Those are the names of the properties on your collection to use for the text and value field, respectively. So, for the Tourney Bracket Control, we actually have four fields you can bind to: CompetitorId, CompetitorName, SeedNumber, and NavigateUrl:

Bracket1.DataCompetitorNameField = "TeamName";

Obviously, we have three others for the other properties, but it's pretty straight forward. Here's where things get interesting. Instead of your ordinary CreateChildControls() method, you get a new CreateChildControls method that takes a couple of parameters. One of them is the IEnumerable datasource, and from this, you can get all of the data out of the datasource. To do this, you get an enumerator:

IEnumerator e = dataSource.GetEnumerator();

Then, you loop for each record, and get a reference to the data object:

object data = e.Current;

Then, to get the data out of the object, you use the DataBinder class:

competitor.CompetitorName = DataBinder.GetPropertyValue(data, this.DataCompetitorNameField, null);

The nice thing is that you never have to know the actual type that the control is databound to. And with that, we now have the ability to bind a bracket directly to a database table of teams, and the whole bracket structure can be completely dynamic, and the developer using the Tourney Bracket Control never has to know what the final bracket will look like.

All in all, setting up databinding turned out to be pretty simple. I'm glad we went through the process because next time, it won't be nearly as daunting as it was this time!

Embedded Resouces In ASP.NET 2.0

Joel Ross — Sun, 09 Oct 2005 18:41:00 GMT

In the Tourney Bracket Control, we have a few Javascript methods that allow for the control to be interactive on the client side. In version 1.0, that code was put right into our control - hardcoded into a StringBuilder and then registered to the page. It works for us, but it wasn't ideal.

With the next version, we wanted to be able to get two benefits that we don't have now: 1.) allow the standard javascript functions to be cached on the client, and 2.) maintain the Javascript code in a .js file rather than in a string. So we started looking at what it takes to embed resources into our DLL. We looked at it in .NET 1.1, and it looked like a bit of a pain to get the little bit of benefit we would have.

But along came .NET 2.0, and it becomes much simpler. We created a folder to hold our resources, and in it, we put a .js file with our standard functions in it, and a css file with our standard css styles that we want. Then, in the control, there's two steps we needed to perform. The first is to put an assembly level attribute that exposes that resource to the world:

[assembly: System.Web.UI.WebResource("Resources/BracketFunctions.js", "text/js")]

Then, in the PreRender event, we register this script to be put into the page:

string scriptLocation = this.Page.ClientScript.GetWebResourceUrl(this.GetType(), "BracketFunction.js");
this.Page.RegisterClientScriptInclude("BracketFunctions", scriptLocation);

Then, when the page is rendered, you end up with a script include in the HTML page:

All in all, it's pretty simple and straight forward, and it accomplishes both of our goals. Because it's included as an external script file, the browser can cache it, and since we can now manage it as a javascript file, it's much easier to modify. Same with the css file.

This is just one of the things that have made our life easier building the new control. I'm installing Visual Studio 2005 RC1 right now, and I'm looking forward to see how things have progressed. Once I get the TBC up and running on that, I'll give a quick update on how the migration process went (I expect it to be pretty easy), and what we have left to do.

Server Controls And Persistence

Joel Ross — Sun, 25 Sep 2005 12:42:00 GMT

As some of you may know, I'm one of the owners of Tourney Logic. We're working on the next version of the bracket control, and I'm having an issue that I'm trying to work through right now. The Tourney Bracket Control (TBC) is a server control that's a little different than most I've seen - especially with some of the changes we've made recently.

Here's why (I think) it's unique. In our control, you add a collection of one type of custom control (teams), and based on how many teams are in that collection, the bracket creates a whole set of other controls (rounds, matchups, etc.) and adds them to it's controls collection. Then, when rendering, it's up to each control to determine how it should render itself. From a programming stance, this makes the rendering fairly simple.

But here's where the issues come in. Because the CreateChildControls() method changes the control hierarchy, it's actually changing the markup in the aspx page, which is not what we want to happen. So, when you look at the markup, rather than seeing the teams you added, you see a whole hierarchy of rounds and matchups, which is not what we want.

I think I understand a little bit of what is going on: It's persisting the TBC's control collection, which is now different than what the designer specified it to be. Is there a way to control what gets persisted to the aspx page and what doesn't, separate from the way it's rendered? If you have any ideas, please let me know! I'm banging my head on a wall right now!

References in Web Projects in VS.NET 2005

Joel Ross — Thu, 11 Aug 2005 20:38:00 GMT

This is why I usually don't start posting until I'm caught up on my blog reading. I just posted tonight about one of the problems with the new project-less web projects in VS.NET 2005 - you can't easily manage updates to binary references (or, for that matter, references to other projects in the same solution).

Well, I just read a post from Paul Wilson stating that this has been fixed in post-beta 2. Now, when you add references, you'll get a "refresh" file, which will give VS.NET a list of references to refresh on compile. I guess that's something!

Projectless Web Projects in VS.NET 2005

Joel Ross — Thu, 11 Aug 2005 18:44:00 GMT

There's been a lot of talk about ASP.NET 2.0's model of project-less web sites (including from Jeffrey Palermo on the latest DotNetRocks show), and whether that's a good thing or a bad thing. The consensus seems to be that it's bad.

I'm still not sure. I haven't dug in enough, but I can think of some pitfalls already. How do you manage references and know to re-copy them if they've been updated? How can you exclude a file from a web site without deleting it? With a project file this is easy.

On the other hand, how many times has the project file come back to bite you? And I don't just mean two people needing access to it at the same time - that's an easy one. I'm talking about virtual folders and the pitfalls of dealing with those, editing project files by hand, getting a new developer the latest version, things like that. I've gotten intimately involved in the details of the csproj file, the .sln file and .csproj.webinfo files. Not something I should have to do, in my opinion.

So what's the best method? I have no idea. The pitfalls are potentially big to me, but the benefits are enticing too. Being able to open any folder as a web folder sounds pretty nice, but in practice, will it be used? If no project file is needed for web apps, why then do we need it for other project types? They still have them, right? Couldn't most of the problems have been solved by just removing the IIS binding information from the solution and projects, and using the "Cassini-esque" web server built in? That way, managing what files are included, references, where code is, etc. would all be easy. You could also then provide a way to handle compilation easier - yeah, the compile into 100s of DLLs may be useful for debugging (pseudo edit-and-continue!), but in release mode, you don't need this.

I'm sure this is too simplistic, and I haven't played as much as I should have, but to me, it sounds like we've gone from one extreme to another. Maybe in the next iteration, we'll settle somewhere in the middle.

Sharing Data Among Server Controls

Joel Ross — Wed, 20 Jul 2005 21:24:00 GMT

Jeff Cranford has an interesting post about how you can share data among server controls. It's interesting because it works at design-time too. If you've ever built a custom server control, you'll appreciate the difficulties that design-time support causes, as well as Jeff's solution.

Did you realize that ViewState was available at design-time?

Object Oriented Navigation In ASP.NET

Joel Ross — Wed, 13 Jul 2005 19:53:00 GMT

David Starr has a post highlighting what Craig Shoemaker said in his 2/7/05 podcast about object oriented pages, and how to handle redirects.

Redirects are an area that makes true object oriented web development difficult. Being able to move from page to page in a strongly-typed world is tough, and requires a bit of upfront thought and design to create something that is easy to use and easy to maintain.

Personally, while I think the solution Craig outlined is better than nothing, I would prefer to keep the knowledge about page locations and how to get to them away from the page itself. That way, other pages don't have to know about each other, nor do they have to know much about the site structure.

How do you achieve that? A UI Process layer. This way, your pages can concentrate on their task, which is (in most cases) to show data to the user, and collect user input. The page only needs to know how to take some data and display it, and then how to get the updated data back. Then, it takes that data, passes it off to a process layer, and the process layer is then responsible for determining what to do with the data passed to it.

Here's a real world example that I've done. On NationalCityHomeLoans.com, we had a UI Process layer that was responsible for everything that happened while the user was in the application. When a page loaded, it was given an object and it displayed the data from that object. When any action was taken, it put the updated data back in the object and determined the user's action (i.e., jump to page 4, go back, save, etc.). Then , the page took the object and the action, and passed it to our process layer. The process layer, based on what page the user was on, ran the necessary updates, and then used the action to determine where to go next. It then handed the object off to the next page, and the process started all over again.

So what do I think the advantages of the above approach is over Craig's? Mainly that the logic to move from page to page and the hard coding of page locations is maintained in one place - the process controller. Changes become easier as the site structure changes over time. And page development is easier. You just call into the process controller and tell it what you want to do. If that action ever changes - for example, after updating something, instead of going back to that item, you now take a user to a list - and this happens in multiple places - all of that logic can be encapsulated, and maintained in one place.