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



2013/8/5 [email protected] <[email protected]>

> Hi Sebastien,
>
> thanks for that! It definitely opens it up.
> I will let you know once we have been able to refactor the code to work
> for our use case.
>
> Thanks,
> Sebastian
>
>
> 2013/8/5 Maxim Solodovnik <[email protected]>
>
>> Thanks!
>> Will look through our code
>>
>>
>> On Mon, Aug 5, 2013 at 2:31 PM, Sebastien <[email protected]> wrote:
>>
>>> Hi Maxim,
>>>
>>> I did not had the time to write the release note yet... Please be sure
>>> to have read this:
>>>
>>> https://github.com/sebfz1/wicket-jquery-ui/wiki/%5Bchangelog%5D-wicket-jquery-ui-6.9.1
>>>
>>> Thanks & best regards,
>>> Sebastien
>>>
>>>
>>>
>>> On Mon, Aug 5, 2013 at 8:39 AM, Maxim Solodovnik 
>>> <[email protected]>wrote:
>>>
>>>> Found the new build!
>>>> Thanks! going to test it today and report back :)
>>>>
>>>>
>>>> On Mon, Aug 5, 2013 at 3:57 AM, Sebastien <[email protected]> wrote:
>>>>
>>>>> Hi Maxim, Hi Sebastian,
>>>>>
>>>>> I took care of your request, but I did it manually yesterday morning
>>>>> because I lost my Internet connectivity...
>>>>> So, the only difference is that I just named getCalendarModelBehavior,
>>>>> newCalendarModelBehavior for consistencies reasons.
>>>>>
>>>>> If I understood your needs, I am seeing a usage like:
>>>>>
>>>>>     class MyCalendar extends Calendar
>>>>>     {
>>>>>         public MyCalendar(String id, CalendarModel model, Options
>>>>> options)
>>>>>         {
>>>>>             super(id, model, options);
>>>>>         }
>>>>>
>>>>>         @Override
>>>>>         protected CalendarModelBehavior
>>>>> newCalendarModelBehavior(CalendarModel model)
>>>>>         {
>>>>>             return new TimeZoneCalendarModelBehavior(model) {
>>>>>
>>>>>                 @Override
>>>>>                 public TimeZone getTimeZone()
>>>>>                 {
>>>>>                     return
>>>>> TimeZone.getTimeZone("America/Los_Angeles"); //to be configured
>>>>>                 }
>>>>>             };
>>>>>         }
>>>>>     }
>>>>>
>>>>>     static abstract class TimeZoneCalendarModelBehavior extends
>>>>> CalendarModelBehavior
>>>>>     {
>>>>>         public TimeZoneCalendarModelBehavior(CalendarModel model)
>>>>>         {
>>>>>             super(model);
>>>>>         }
>>>>>
>>>>>         public abstract TimeZone getTimeZone();
>>>>>     }
>>>>>
>>>>> I may be interested with your implementation of the
>>>>> "TimeZoneCalendarModelBehavior", either to merge it into
>>>>> CalendarModelBehavior or to provide it as an alternative of
>>>>> CalendarModelBehavior, if a user wishes to achieve the same use case...
>>>>>
>>>>>
>>>>> On another topic, I read your conversation bellow and your legitimate
>>>>> concerns about licensing (1) and my availability (2).
>>>>>
>>>>> (1) - The whole code is ASF2 licensed and that will never change.
>>>>> Except the sample site, for readability reason, all files (java, html)
>>>>> *does* have the license header. Sure, wicket-jquery-ui relies on js
>>>>> libraries that may have different licensing, and it is up to the user to
>>>>> take care of this (and Maxim took care actually). Anyway, I will add a
>>>>> NOTICE / LICENSE file to the project...
>>>>>
>>>>> (2) - I usually answering mail with 24 hours max. Sometime more if I
>>>>> am on vacation, naturally. But I also know that, for now on, I am the only
>>>>> one who is (physically) able to maintain/deploy wicket-jquery-ui releases.
>>>>> I understand that it could be a problem to rely on only one man... I will
>>>>> send to Martin Grigorov (Apache Wicket commiter) the "keys" of the 
>>>>> project,
>>>>> in case of something happens to me... (for instance I found the love of my
>>>>> live, and go suddenly living somewhere, where there is no internet,
>>>>> electricity, etc :) ). wicket-jquery-ui has now thousand(s?) users, I am
>>>>> sure there will be someone who can took the relay...
>>>>>
>>>>> Thanks & best regards,
>>>>> Sebastien
>>>>>
>>>>>
>>>>> On Sat, Aug 3, 2013 at 5:32 AM, Maxim Solodovnik <[email protected]
>>>>> > wrote:
>>>>>
>>>>>> Dear Sebastien,
>>>>>>
>>>>>> could you please take a look at
>>>>>> https://github.com/sebfz1/wicket-jquery-ui/pull/52 ?
>>>>>>
>>>>>> Thanks in advance!
>>>>>>
>>>>>> ---------- Forwarded message ----------
>>>>>> From: [email protected] <[email protected]>
>>>>>> Date: Sat, Aug 3, 2013 at 10:21 AM
>>>>>> Subject: Pull request to jquery-wicket-ui for fixing some API to be
>>>>>> customizable
>>>>>> To: dev <[email protected]>
>>>>>>
>>>>>>
>>>>>> Hi Maxim,
>>>>>>
>>>>>> ignoreTimezone to true partially resolves the issue.
>>>>>>
>>>>>> With ignoreTimezone you can decide that the Calendar UI shows the
>>>>>> event in
>>>>>> either the Browser/OS/Client side timezone (ignoreTimezone=false) OR
>>>>>> the
>>>>>> the server side timezone (ignoreTimezone=true)
>>>>>>
>>>>>> We neither want both, we want the events to be displayed in the
>>>>>> timezone of
>>>>>> the OpenMeetings user, and that can be configured different from the
>>>>>> browser/os and server timezone.
>>>>>>
>>>>>> The idea would be that the server does send the Date/Time in the
>>>>>> OpenMeetings user timezone, and we will set ignoreTimezone to true.
>>>>>>
>>>>>> Unfortunatelly this is currently not possible with wicket-jquery-ui
>>>>>> as the
>>>>>> needed API's are not overwritable / public.
>>>>>>
>>>>>> I have made a pull request to the wicket-jquery-ui to fix that:
>>>>>> https://github.com/sebfz1/wicket-jquery-ui/pull/52
>>>>>>
>>>>>> Can somebody contact sebfz? Maxim, you mentioned you are in contact
>>>>>> with
>>>>>> him?
>>>>>>
>>>>>> Thanks,
>>>>>> Sebastian
>>>>>>
>>>>>>
>>>>>> 2013/8/1 Maxim Solodovnik <[email protected]>
>>>>>>
>>>>>> > I actively talk with Sebastien (the author of wicket-jquery-ui).
>>>>>> > His project consist of different parts with different licences (for
>>>>>> example
>>>>>> > Kendo* plugins are GPLv3 licensed)
>>>>>> > I only took parts licenced under compitible licenses.
>>>>>> >
>>>>>> > I can write him a letter to add NOTICE, should I?
>>>>>> >
>>>>>> > For the changes to the FullCalendar I would:
>>>>>> > 1) read the documentation (it has 'ignoretimezone' option which
>>>>>> might help
>>>>>> > 2) take a look at the current issues, for ex. this one
>>>>>> > https://github.com/arshaw/fullcalendar/pull/92
>>>>>> > 3) propose the patch to the author
>>>>>> > 4) hacking ourselves :)
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > On Thu, Aug 1, 2013 at 8:48 AM, [email protected] <
>>>>>> > [email protected]
>>>>>> > > wrote:
>>>>>> >
>>>>>> > > Okay but it seems like it is Apache Licensed:
>>>>>> > > https://code.google.com/p/wicket-jquery-ui/
>>>>>> > >
>>>>>> > > But wicket-jquery-ui includes other libraries that are under the
>>>>>> MIT
>>>>>> > > license. So he would need a NOTICE file (According to our rules).
>>>>>> > >
>>>>>> > > Its really a bit messy, I think we should clean that up and add
>>>>>> the
>>>>>> > > FullCalendar to our NOTICE file to make sure nobody raises
>>>>>> concerns about
>>>>>> > > the legal status of our project.
>>>>>> > >
>>>>>> > > Sebastian
>>>>>> > >
>>>>>> > >
>>>>>> > > 2013/8/1 [email protected] <[email protected]>
>>>>>> > >
>>>>>> > > > I am afraid some of our changes that are required for instance
>>>>>> for
>>>>>> > making
>>>>>> > > > it timezone safe will be much easier if we simply do it.
>>>>>> > > > And also their use will be relatively limited to what we want
>>>>>> to do
>>>>>> > with
>>>>>> > > > it. So its unlikely that it will be useful for anybody else.
>>>>>> > > >
>>>>>> > > > We can then discuss how and when those changes will become part
>>>>>> of
>>>>>> > > > wicket-jquery-ui.
>>>>>> > > >
>>>>>> > > > For me it seems like the author of wicket-jquery-ui does not
>>>>>> care about
>>>>>> > > > the license at all. There is not even a License file or any
>>>>>> kind of
>>>>>> > > header
>>>>>> > > > in the source code of his file.
>>>>>> > > > So in theory that can literally mean that he can decide
>>>>>> tomorrow he
>>>>>> > will
>>>>>> > > > license it under whatever he wants it to be.
>>>>>> > > >
>>>>>> > > > That is a bit scary for us. We can't just include a library
>>>>>> without
>>>>>> > > having
>>>>>> > > > a correct attribution of the License.
>>>>>> > > >
>>>>>> > > > I know there was put a bit of effort into using this library
>>>>>> now, but
>>>>>> > if
>>>>>> > > > we release it and there will be doubts raised about this it
>>>>>> could mean
>>>>>> > we
>>>>>> > > > have to replace the entire library.
>>>>>> > > >
>>>>>> > > > Was anybody able to actively talk to the author of that
>>>>>> > wicket-jquery-ui
>>>>>> > > ?
>>>>>> > > > Cause if that guy does not respond to any emails its really
>>>>>> kind of
>>>>>> > > > dangerous to base our application on the hope he will not
>>>>>> suddenly
>>>>>> > change
>>>>>> > > > his mind and put the code under a license we don't like.
>>>>>> > > >
>>>>>> > > > Sebastian
>>>>>> > > >
>>>>>> > > >
>>>>>> > > >
>>>>>> > > >
>>>>>> > > >
>>>>>> > > > 2013/8/1 Maxim Solodovnik <[email protected]>
>>>>>> > > >
>>>>>> > > >> Hello Sebastian!
>>>>>> > > >>
>>>>>> > > >> we actually do not distribute the fullcalendar.js.
>>>>>> > > >> We are using wicket-jquery-ui which ships fullcalendar for as.
>>>>>> > > >>
>>>>>> > > >> Despite wicket-jquery-ui allows to replace almost any resource
>>>>>> with
>>>>>> > > custom
>>>>>> > > >> one, I would start from proposing our patch to the author
>>>>>> since it
>>>>>> > would
>>>>>> > > >> be
>>>>>> > > >> easier to maintain in the future. (Already was done with
>>>>>> > > wicket-jquery-ui,
>>>>>> > > >> wicket and some jquery libraries)
>>>>>> > > >>
>>>>>> > > >>
>>>>>> > > >>
>>>>>> > > >> On Thu, Aug 1, 2013 at 7:36 AM, [email protected] <
>>>>>> > > >> [email protected]
>>>>>> > > >> > wrote:
>>>>>> > > >>
>>>>>> > > >> > Hi,
>>>>>> > > >> >
>>>>>> > > >> > the OpenMeetings project would like to redistribute the
>>>>>> jQuery
>>>>>> > Plugin
>>>>>> > > >> > "Fullcalendar":
>>>>>> > > >> > http://arshaw.com/fullcalendar/
>>>>>> > > >> >
>>>>>> > > >> > As part of its distribution. Which itself should not be a
>>>>>> problem:
>>>>>> > > >> > http://www.apache.org/legal/3party.html#category-a
>>>>>> > > >> >
>>>>>> > > >> > But we also might need to modify some of the source code to
>>>>>> fit our
>>>>>> > > >> needs.
>>>>>> > > >> >
>>>>>> > > >> > Are we allowed to do that?
>>>>>> > > >> > Are there changes to NOTES files needed when we do that ?
>>>>>> > > >> >
>>>>>> > > >> > I've somebody knows an answer to that or pointers to the FAQ
>>>>>> where
>>>>>> > > this
>>>>>> > > >> > would be covered, I would much appreciate.
>>>>>> > > >> > But I think the FAQ don't cover that topic yet.
>>>>>> > > >> >
>>>>>> > > >> > Thanks,
>>>>>> > > >> > Sebastian
>>>>>> > > >> > --
>>>>>> > > >> > Sebastian Wagner
>>>>>> > > >> > https://twitter.com/#!/dead_lock
>>>>>> > > >> > http://www.webbase-design.de
>>>>>> > > >> > http://www.wagner-sebastian.com
>>>>>> > > >> > [email protected]
>>>>>> > > >> >
>>>>>> > > >>
>>>>>> > > >>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> WBR
>>>> Maxim aka solomax
>>>>
>>>
>>>
>>
>>
>> --
>> WBR
>> Maxim aka solomax
>>
>
>
>
> --
> Sebastian Wagner
> https://twitter.com/#!/dead_lock
> http://www.webbase-design.de
> http://www.wagner-sebastian.com
> [email protected]
>



-- 
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
[email protected]

Reply via email to