Thanks  - you helped me to boil down available options here.

I think you are perfectly right that creating the middle layer
directly in JS would involve a lot of hard work. However, we are a bit
lucky since we are building on top of ASP.NET which makes it possible
develop the layer in C#.

I am also grateful for your thoughts about how to handle the user
interaction.

I guess the Add maneuvering is pretty straightforward but a more
complicated user interaction is associated with Delete/Edit since we
have to get the unique id for the event first (as you well pointed
out).

We have not decided to swap our existing custom calendar yet – but I
will keep you posted once we start off.

I would love to see any demo of the user interaction…




On Jul 21, 8:24 pm, Joey Kippen <[email protected]> wrote:
> If you have not created the middle layer of JS to interact with the Gcal
> API, this could take some time. I understand your problem with wanting to be
> able to click on the embedded calendar to edit events. In response to your
> question, no, I have not seen an application that does this, yet.
>
> As I have not finished my interface on this area, I cannot tell you what I *
> have* done, but I can tell you how I will proceed and maybe you will want to
> do the same. There is an example on the code.google.com with the JS getting
> an event by searching for either full content or title. I have been studying
> the classes and interactions very carefully, so I will be implementing an
> interface in which a person can enter the title, time, location, etc., or
> any combination thereof and search for the event in that way. After getting
> the ID/link for the event, I will load the information that I will have
> editable into the interface. After all the changes are made, the user will
> click on an update button/image/whatever to signal the JS to update. The JS
> will then take the ID/link that it grabbed earlier, grab the event object
> again, load the new information, and update.
>
> My interface, right now, has the options for the embedded calendar to the
> left of the calendar so that the user can easily view the calendar while
> they are creating new events/calendars (done), editing (done for calendars),
> and deleting events/calendars (also done for calendars). Since I have not
> done the deletion for events yet I will be working on that next because I
> will have to locate the event before deleting it. So once the deletion is
> done, I will already have the ability to find the events I want. I will
> probably be implementing popups later but I like to get all the
> functionality done before making it pretty.
>
> As per your situation, creating a middle layer of your own would be fine if
> you are willing to put the time into it. Again, there are a lot of different
> problems that you might run into. There are actually several problems with
> the JS that google has not, or atleast I have not seen them, documented. I
> have however implemented work arounds for all the ones that I have run into.
> I am working on top of PHP right now but it does not matter because my
> interface is totally in JS. The PHP API was lacking on so many sections that
> I used JS instead. In essence, what I am creating would be completely
> platform independant. That is one of the many reasons for using the JS
> version of the API. Plus the embedded calendar is easily updated and
> refreshed using JS, no page reloads!
>
> Anyway, long response but there you have it. If you have any other
> questions, let me know.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to