Extensibility in data objects

[hwsoderlund]

I am using the category functionality in RadScheduleView to map against our own CalendarEventType class. To do this effectively I would need a UniqueIdentifier property on the Category class. At the moment I am forced to put the ID into the Category.CategoryName property and then put the actual name in the Category.DisplayName property. This works fine, but it is still a hack.

I have the same problem with the TimeMarker class. These will also be dynamically constructed, so I need some sort of ID to keep track of which time marker is selected. The name of the marker needs to be translated dynamically, so the value of the Name property will not be constant. I can of course work around this, but it will be an even uglier hack.

In general I feel that we need more control over the data containers used in RadScheduleView. With the appointments you have nailed a near perfect solution. We can either inherit from Appointment (or AppointmentBase I think), or implement IAppointment ourselves. In this way, we can work with our own data classes and have all the properties and methods that we want. Ideally, I would like to have the same extensibility with the TimeMarker and Category classes. But at least we need some sort of UniqueIdentifier property where we can put our IDs.

At the moment I am not using Resources at all, so I do not know how that works. But eventually we will need similar functionality there.

Best regards,
/Henrik

[Valeri Hristov]

We already have the functionality in the resources - you could implement the IResource interface and plug it into your IAppointment implementation. There is some more work that has to be done, but I hope that for the official release we will properly clear this area. Most probably we will create similar interfaces for the Category and the TimeMarker classes, thus allowing the developers to store them into a database.

You should be able to replicate the Category/TimeMarker functionality with simple resources, but again you would have to write code.

Greetings,
Valeri Hristov
the Telerik team