Posted 06 Nov 2007
Link to this post
I wasn't subscribed for this thread (now I am) so I didn't see your questions. On the public-facing pages I am using a standard calendar at this time. To be honest, I haven't even investigated whether or not there would be any advantages to using radCalendar on the public-facing pages.
On the administration pages, though, the racCalendar makes its appearance all over the place - mostly because of its appearance, but also to leverage its client-side capabilities.
To your other question, about dynamically loading user controls, this is the method I have always used since it allows for easy customization of the *structure* of the site by the end-user. The DB stores the navigational structure for the site, with one of the fields being the name of the user control to load. To add a new page to the site's navigation then simply requires adding a new row to the DB table, storing the page ID, name, user control, and custom content. The user control that loads can take additional information from the querystring to display additional information. For example, the "Static.ascx" control is loaded when "Content=Static", which then looks for the ID of the page to go grab the custom content from the same row in the DB.
The disadvantages of this, people tell me, is that this is not very SEO friendly. Poppycock. I can do a search for one of the players on one of the teams on a site, and google will correctly take me directly to that player's profile - with the url something like huronperthlakers.ca/Default.aspx?Team=1010&Content=Player&ID=1252 (I made up those numbers, btw, so that's probably not a real page).
Another disadvantage is the "cryptic" addresses that this can create - like the one above. People tell me that an address like huronperthlakers.da/Teams/1010/Players/1252/ would be easier to remember. I'm not sure how many people would be able to directly navigate to either address by "guessing" the url.
There may be other disadvantages, but the one huge advantage is the ability to link to any of the pages, deep within the site, from anywhere else - including other sites. Each page is instantiated fresh upon loading using the parameters in the querystring, so there's no need to worry about the context when loading the page, no need use use Session or any other variables, etc. Additionally, if you are loading several user controls on the page (like I am), they can all use the same parameters brought in by the querystring.
It also makes archiving, in the case of the hockey organizations, really easy. The only thing that the organization needs to do is set the current season that the site is working with to get the list of all that current season's teams. All the other past (and future) teams are available by passing that team's ID in the querystring at any time. I have a part of the page which detects whether or not the current team's ID is associated with the organization's current season, and if not, displays a message alerting the user.