views:

343

answers:

4

I would like to build a calendar 'component' for my website. I want to make it manageable and easy to extend in the future. I will not be using it for any other website but it want to make it solid independent of the rest of the website. The website is built with ASP.NET MVC.

I want to include different views (month, week, day [maybe even year]). I'm planning on using different ways to present information to the users:

  • Icons
  • Colorization (weeks, hours, periods[!])
  • Popup screens

The information needs to be displayed based on information contained in other (.NET) models. I want this logic to be separated correctly.

I'm fairly good at javascript, so I will be able to build a nice interface for dragging and dropping events on the calendar and navigating through the calendar dates. However I want the component to work without javascript too.

Should I build this component from scratch? If so, can you name the different parts which you would create to build the component?

OR

Can I alter the .NET Calendar control to fit my needs?

Thanks for the input!

+1  A: 

why reinventing the wheel if you can reuse and maybe improve an already good one ?

try to look at the DHTMLxScheduler it uses a Javascript API so you can do everything you need ...

you can read more on WebAppers entry

In the world we are today, we should reuse instead of inventing again and again the some thing over and over... at least I'm apologist from this idea.

Open Source - GPL allows you to use dhtmlxScheduler in GPL projects for free.

balexandre
+3  A: 

I'm heavily biased here, but have a look at what Google Calendar does. To my mind it's a really, really nice web UI for calendaring.

My main advice would be to expect it to be a pain. In particular, each of these "axes" adds an extra order of magnitude of complexity:

  • Interoperating with other calendar clients (e.g. iCal or ActiveSync)
  • Interoperating with other calendar servers (e.g. Google Calendar)
  • Handling time zones (do not assume that a time zone is just an offset from UTC! You need to know more information so you can predict when daylight saving kicks in, account for historical/future changes etc)
  • Handling recurrent events (which can end up being arbitrarily complicated if you're not careful)
  • Handling shared events (e.g. meetings)
  • Handling shared access (e.g. user X is user Y's secretary and has permission to do various things)
  • Handling localization (every culture displays its dates in different ways)
  • Handling different calendar types (do you need to support Coptic calendars etc?)

When you combine all of them, you end up with a huge pain. Work out what you really need to cover, and rule out everything else. Try to rule it out permanently (and explicitly - keep a document of things you're just not going to support, with management approval).

Full disclosure: I work on Google Sync for mobile devices, mostly on the calendar side. You wouldn't believe some of the corner cases that come up. My development space is mostly made up of corners, basically.

Jon Skeet
Good stuff. My calendar will be used for scheduling/tracking (diets/physical activities) so it's not the conventional meeting/task/workspace calendar. Best input though, thanks.
Ropstah
+1  A: 

I would definitely discourage you from building your own. Think about this for a minute.

If you expect building a calendar will take you say X hours, then you should spend X/10 hours looking for a calendar that:

  1. Comes even halfway close to what you need. At worst you'll waste 10% of your time with a potential gain of saving 50% of your time. I know there hundreds of calendars out there so you'll probably find one that fits your needs almost entirely i.e. with progressive rendering and all (drag and drop is something you'll probably need to do yourself).

  2. Has a license that suits your needs. Most of them have liberal licenses because it's such a common control.

  3. If the calendar has high adoption you'll be better off because it will have fewer bugs since it will have been tested in the wild but yours will continue to show bugs across the vast array of browsers months down the line. You really don't want so spend your time fixing bugs when you could spend that same time coding features. If the community is big it might even have cool features that you can get for free without even having thought of them (like shifting the start of the week from Mon to Sun for some countries).

You can focus the time saved building on drag and drop functionality and tweaking the calendar to your needs.

aleemb
Perfect tips, however this wasn't really my question... ;) +1 though
Ropstah
A: 

I agree with rest of the answers...you can use some library for that, for example jquery ui calendar:

http://jqueryui.com/demos/datepicker/

cheers

Marko