In my opinion, there is a design "annoyance" inherent in building an application that requires access to extended event properties. That being that, in order to build an application that allows a user to add, update, or delete application-specific information that's stored as an extended property, I have to build a UI that replicates 100% of the functionality already provided by Google's UI and then adds a couple of extra data fields. This is not optimal, and makes me think that I should try to avoid using the extended properties.
This problem was touched upon briefly here: http://groups.google.com/group/google-calendar-help-dataapi/browse_frm/thread/ad78d66e9db36d78?tvc=1&q=extended+properties Has anyone found a reasonable strategy for navigating this dilemma? A digression: I think that a HUGE part of the value that Google provides comes in the form of a concise, effective UI that developers would love to take advantage of. It would be nice if we could do more than just embed calendars in web pages and make little widgets. I am thinking, here, that the best way to solve the "extended properties UI dilemma" is to allow developers a way to modify the existing UI of particular calendar feeds, and provide a callback-based API for computing on those fields. Maybe this has been done; I'm not sure. Barring something like this, though, I am most interested to know how people have solved the EP/UI dilemma for themselves. A fast-and-dirty solution is particularly appealing for my current purposes. Any advice is much appreciated. Thanks, Brian --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Calendar Data API" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/google-calendar-help-dataapi?hl=en -~----------~----~----~----~------~----~------~--~---
