Hi Sebastien, > newRequestHandler() should be public, otherwise you can't modify the output really. Well... I should have thought about this ;) But maybe you do not have to override it, please see bellow...
>What was your major idea about timezone safe Calendar, is the basic idea that every date/time on server side is always handled as if its in the timezone of the server? So in other words: Any incoming date/time has to be converted into the timezone of the server first, before doing anything with it? I did not had a precise idea on this because there is many way to achieve this and I do not know your usecases/contraints exactly. But, if I had to implement this, I would have l explored several ways: At a first point, the strategy: should the *all* events be stored in a GMT (or UTC, Coordinated Universal Time) timezone, or should they be stored with the "correct" time with the user's timezone information. That's may be a strange question but I am pretty sure google's calendar opted for the first strategy. Then, it is easier to slice/display the same event in different timezone. The second point, is how the user timezone is handled. Or the timezone information is sent by the browser or it is stored with the user account (server side then)? Or you have a mix of both (the best). In my POV, the timezone to be used is the one stored with the user account. But, you can also use the browser's timezone to compare if both are the same. If not, you can display a message like "Hey, your timezone is currently set to Paris/France, but it seems that you are now in Tokyo/Japan, do you wish to update your timezone?". Then the third point, when (at that stage) the timezone information should be used/applied? Should the timezone be used to retrieve the events or should it be used to slice event dates after there have been retrieved, in a GMT/UTC format? Probably both, depending of choices in point #1 & #2, you may convert the user timezone to GMT/UTC, query the DB, and then slice events to the user timezone. In that case, the first conversion should be done in CalendarModelBehavior. But there is not need to rewrite #newRequestHandler for this. If I supply a protected CalendarModelBehavior#setStartDate/setEndDate(model, date) you are be good enough with that. To slice the events to the user timezone after the events-load, if CalendarModel extends ICalendarVisitor then it is easy to update the event dates according to the user timezone. I do not pretend it is the solution you have to put in place, maybe I miss something according to your usecases/contraints, but that's the way I would have think about this... > I also see that you finetune the access rights on class and method level quite heavily. Yes, exactly to prevent user to miss-use the API. I agree that you may have some flexibility in your case. But depending of your choices, maybe you will *not* have to override #newRequestHandler So, I: - changed #newRequestHandler visibility to protected - changed CalendarModel#setStart & CalendarModel#setEnd visibility to public - added CalendarModelBehavior#setStartDate & CalendarModelBehavior#setEndDate(model, date) - deployed 6.9.2-SNAPSHOT Please tell what you think about this (if my explanations was clear enough ;)) I will probably release 6.9.10 in the coming days (next friday at latest), so if you need something else, that's the good moment... Best regards, Sebastien On Sat, Aug 10, 2013 at 1:38 AM, [email protected] < [email protected]> wrote: > Hi Sebastien, > > we opted now to refactor our code to always display the UI in the timezone > of the browser, so we don't have this issue anymore. > However I was looking at your code and realized that still there are a > couple of issues that make it impossible to show the Calendar in any other > timezone then user or the server timezone: > In the class CalendarModelBehaviour the method: private IRequestHandler > newRequestHandler() > should be public, otherwise you can't modify the output really. > > That is the major issue. > > What was your major idea about timezone safe Calendar, is the basic idea > that every date/time on server side is always handled as if its in the > timezone of the server? So in other words: Any incoming date/time has to be > converted into the timezone of the server first, before doing anything with > it? > > I also see that you finetune the access rights on class and method level > quite heavily. > Often classes are protected private or just private. For instance the > methods setStart/setEnd in the CalendarModel. > Having those finetuned access rights on an API is basically a good thing > cause you can modularize your components and integrators only use the > desired APIs, so you can change the core without affecting others. But its > quite easy to overachieve that goal. > > Happy to hear more from your side, great work with that component! > > Cheers! > Sebastian > > >
