You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openmeetings.apache.org by "seba.wagner@gmail.com" <se...@gmail.com> on 2013/08/03 05:21:01 UTC
Pull request to jquery-wicket-ui for fixing some API to be customizable
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 <so...@gmail.com>
> 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, seba.wagner@gmail.com <
> seba.wagner@gmail.com
> > 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 seba.wagner@gmail.com <se...@gmail.com>
> >
> > > 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 <so...@gmail.com>
> > >
> > >> 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, seba.wagner@gmail.com <
> > >> seba.wagner@gmail.com
> > >> > 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
> > >> > seba.wagner@gmail.com
> > >> >
> > >>
> > >>
> > >>
> > >> --
> > >> WBR
> > >> Maxim aka solomax
> > >>
> > >
> > >
> > >
> > > --
> > > Sebastian Wagner
> > > https://twitter.com/#!/dead_lock
> > > http://www.webbase-design.de
> > > http://www.wagner-sebastian.com
> > > seba.wagner@gmail.com
> > >
> >
> >
> >
> > --
> > Sebastian Wagner
> > https://twitter.com/#!/dead_lock
> > http://www.webbase-design.de
> > http://www.wagner-sebastian.com
> > seba.wagner@gmail.com
> >
>
>
>
> --
> WBR
> Maxim aka solomax
>
--
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com
Re: Pull request to jquery-wicket-ui for fixing some API to be customizable
Posted by Sebastien <se...@gmail.com>.
Hi Sebastian
I try to let open as much as I think the user can customize, but you are
right, it is hard to get the full picture of all possible use-cases... But
when I think it can be dangerous, error prone or confusing, I prefer to
restrict... (I may sometime be a little bit strict, however a simple
request and I unlock if I see no drawbacks...)
Looking at the code again, even #newRequestHandler is more designed to be
for internal purpose, I will leave it protected (as you demonstrate a
possible use-case earlier! ;))
Thanks & best regards,
Sebastien.
On Sat, Sep 28, 2013 at 12:04 AM, seba.wagner@gmail.com <
seba.wagner@gmail.com> wrote:
> Hi Sebastien,
>
> I can check that. But I don't think we need it to be open.
>
> We basically reworked all of our code so that there is no more requirement
> to display the Calendar in a different timezone then the timezone of the
> browser/OS.
>
> However from an integration point of view I would be very careful on how
> much you want to restrict the usage of your API. Having only one designed
> way to use is good, but it is quite hard to really have an overview about
> all available use-cases to judge what is the best scenario for an API to
> use. The more people adapt your libary, the bigger the success, the bigger
> the chances you find more active contributor that improve the quality and
> features :)
>
> Thanks for heads up!
> Sebastian
>
Re: Pull request to jquery-wicket-ui for fixing some API to be customizable
Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
Hi Sebastien,
I can check that. But I don't think we need it to be open.
We basically reworked all of our code so that there is no more requirement
to display the Calendar in a different timezone then the timezone of the
browser/OS.
However from an integration point of view I would be very careful on how
much you want to restrict the usage of your API. Having only one designed
way to use is good, but it is quite hard to really have an overview about
all available use-cases to judge what is the best scenario for an API to
use. The more people adapt your libary, the bigger the success, the bigger
the chances you find more active contributor that improve the quality and
features :)
Thanks for heads up!
Sebastian
2013/9/28 Sebastien <se...@gmail.com>
> Hi Maxim, Sebastian,
>
> Sorry to wake up this thread...
>
> I have a todo for wicket-jquery-ui 6.11.0 which is to (maybe) restore
> CalendarModelBehavior#newRequestHandler() visibility to private (instead of
> protected).
> I don't think you had to override it, but could you just double check? If
> it is not the case (I mean you did not override it), I think it should
> remains for internal/private use...
> Your thought/opinion is welcome, of course.
>
> Thanks in advance & best regards,
> Sebastien.
>
>
>
> On Mon, Aug 12, 2013 at 5:45 AM, Maxim Solodovnik <so...@gmail.com>wrote:
>
>> java.util.Date is actually container for "milliseconds from 01.01.1970"
>> :))
>>
>>
>> On Sun, Aug 11, 2013 at 11:50 AM, seba.wagner@gmail.com <
>> seba.wagner@gmail.com> wrote:
>>
>>> Hi Sebastien,
>>>
>>> thanks for those updates, I don't think we require anything from your
>>> side at the moment.
>>>
>>> About *storing in a GMT (or UTC ... )*
>>> Basically you can't store any kind of TimeZone information together with
>>> the Date object in a database.
>>> If you try to save an object java.util.Date or java.util.Calendar in a
>>> database it will simply cut away the timezone information. This behaviour
>>> is the same across all major database vendors, so that even ORMs like
>>> OpenJPA do note it their docs:
>>>
>>> http://openjpa.apache.org/builds/2.2.2/apache-openjpa/docs/ref_guide_pc_scos.html#ref_guide_pc_calendar_timezone
>>>
>>> The reason for that is that databases only have the field dateTime which
>>> is YYYY-MM-DD HH:MM:SS.sss
>>> There is no space reserved in the database for the timezone.
>>>
>>> So the general solution might be that the date that you store in the
>>> database is always in the timezone of the (database) server. (And it makes
>>> a lot of sense to have database server and application server in the same
>>> timezone).
>>> If you mix the date/times in your database to store some in UTC and some
>>> in local time, simply queries might just return wrong values as the
>>> database does not know that it needs to consider the timezone different
>>> between certain fields.
>>> So I am not saying that nobody might save the dateTime in GTM or UTC in
>>> a database but whom-ever does it might create more issues then solving.
>>> I have seen a couple of such things, for instance in the PHP world it
>>> seems quite common that you convert everything into milliseconds since 1970
>>> instead of using appropriate date/time database fields :)))
>>>
>>> Just my 2 Cents :)
>>>
>>> Sebastian
>>>
>>>
>>>
>>> 2013/8/10 Sebastien <se...@gmail.com>
>>>
>>>> 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, seba.wagner@gmail.com <
>>>> seba.wagner@gmail.com> 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
>>>>>
>>>>>
>>>>>
>>>
>>>
>>> --
>>> Sebastian Wagner
>>> https://twitter.com/#!/dead_lock
>>> http://www.webbase-design.de
>>> http://www.wagner-sebastian.com
>>> seba.wagner@gmail.com
>>>
>>
>>
>>
>> --
>> WBR
>> Maxim aka solomax
>>
>
>
--
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com
Re: Pull request to jquery-wicket-ui for fixing some API to be customizable
Posted by Sebastien <se...@gmail.com>.
Hi Maxim, Sebastian,
Sorry to wake up this thread...
I have a todo for wicket-jquery-ui 6.11.0 which is to (maybe) restore
CalendarModelBehavior#newRequestHandler() visibility to private (instead of
protected).
I don't think you had to override it, but could you just double check? If
it is not the case (I mean you did not override it), I think it should
remains for internal/private use...
Your thought/opinion is welcome, of course.
Thanks in advance & best regards,
Sebastien.
On Mon, Aug 12, 2013 at 5:45 AM, Maxim Solodovnik <so...@gmail.com>wrote:
> java.util.Date is actually container for "milliseconds from 01.01.1970" :))
>
>
> On Sun, Aug 11, 2013 at 11:50 AM, seba.wagner@gmail.com <
> seba.wagner@gmail.com> wrote:
>
>> Hi Sebastien,
>>
>> thanks for those updates, I don't think we require anything from your
>> side at the moment.
>>
>> About *storing in a GMT (or UTC ... )*
>> Basically you can't store any kind of TimeZone information together with
>> the Date object in a database.
>> If you try to save an object java.util.Date or java.util.Calendar in a
>> database it will simply cut away the timezone information. This behaviour
>> is the same across all major database vendors, so that even ORMs like
>> OpenJPA do note it their docs:
>>
>> http://openjpa.apache.org/builds/2.2.2/apache-openjpa/docs/ref_guide_pc_scos.html#ref_guide_pc_calendar_timezone
>>
>> The reason for that is that databases only have the field dateTime which
>> is YYYY-MM-DD HH:MM:SS.sss
>> There is no space reserved in the database for the timezone.
>>
>> So the general solution might be that the date that you store in the
>> database is always in the timezone of the (database) server. (And it makes
>> a lot of sense to have database server and application server in the same
>> timezone).
>> If you mix the date/times in your database to store some in UTC and some
>> in local time, simply queries might just return wrong values as the
>> database does not know that it needs to consider the timezone different
>> between certain fields.
>> So I am not saying that nobody might save the dateTime in GTM or UTC in a
>> database but whom-ever does it might create more issues then solving.
>> I have seen a couple of such things, for instance in the PHP world it
>> seems quite common that you convert everything into milliseconds since 1970
>> instead of using appropriate date/time database fields :)))
>>
>> Just my 2 Cents :)
>>
>> Sebastian
>>
>>
>>
>> 2013/8/10 Sebastien <se...@gmail.com>
>>
>>> 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, seba.wagner@gmail.com <
>>> seba.wagner@gmail.com> 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
>>>>
>>>>
>>>>
>>
>>
>> --
>> Sebastian Wagner
>> https://twitter.com/#!/dead_lock
>> http://www.webbase-design.de
>> http://www.wagner-sebastian.com
>> seba.wagner@gmail.com
>>
>
>
>
> --
> WBR
> Maxim aka solomax
>
Re: Pull request to jquery-wicket-ui for fixing some API to be customizable
Posted by Maxim Solodovnik <so...@gmail.com>.
java.util.Date is actually container for "milliseconds from 01.01.1970" :))
On Sun, Aug 11, 2013 at 11:50 AM, seba.wagner@gmail.com <
seba.wagner@gmail.com> wrote:
> Hi Sebastien,
>
> thanks for those updates, I don't think we require anything from your side
> at the moment.
>
> About *storing in a GMT (or UTC ... )*
> Basically you can't store any kind of TimeZone information together with
> the Date object in a database.
> If you try to save an object java.util.Date or java.util.Calendar in a
> database it will simply cut away the timezone information. This behaviour
> is the same across all major database vendors, so that even ORMs like
> OpenJPA do note it their docs:
>
> http://openjpa.apache.org/builds/2.2.2/apache-openjpa/docs/ref_guide_pc_scos.html#ref_guide_pc_calendar_timezone
>
> The reason for that is that databases only have the field dateTime which
> is YYYY-MM-DD HH:MM:SS.sss
> There is no space reserved in the database for the timezone.
>
> So the general solution might be that the date that you store in the
> database is always in the timezone of the (database) server. (And it makes
> a lot of sense to have database server and application server in the same
> timezone).
> If you mix the date/times in your database to store some in UTC and some
> in local time, simply queries might just return wrong values as the
> database does not know that it needs to consider the timezone different
> between certain fields.
> So I am not saying that nobody might save the dateTime in GTM or UTC in a
> database but whom-ever does it might create more issues then solving.
> I have seen a couple of such things, for instance in the PHP world it
> seems quite common that you convert everything into milliseconds since 1970
> instead of using appropriate date/time database fields :)))
>
> Just my 2 Cents :)
>
> Sebastian
>
>
>
> 2013/8/10 Sebastien <se...@gmail.com>
>
>> 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, seba.wagner@gmail.com <
>> seba.wagner@gmail.com> 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
>>>
>>>
>>>
>
>
> --
> Sebastian Wagner
> https://twitter.com/#!/dead_lock
> http://www.webbase-design.de
> http://www.wagner-sebastian.com
> seba.wagner@gmail.com
>
--
WBR
Maxim aka solomax
Re: Pull request to jquery-wicket-ui for fixing some API to be customizable
Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
Hi Sebastien,
thanks for those updates, I don't think we require anything from your side
at the moment.
About *storing in a GMT (or UTC ... )*
Basically you can't store any kind of TimeZone information together with
the Date object in a database.
If you try to save an object java.util.Date or java.util.Calendar in a
database it will simply cut away the timezone information. This behaviour
is the same across all major database vendors, so that even ORMs like
OpenJPA do note it their docs:
http://openjpa.apache.org/builds/2.2.2/apache-openjpa/docs/ref_guide_pc_scos.html#ref_guide_pc_calendar_timezone
The reason for that is that databases only have the field dateTime which is
YYYY-MM-DD HH:MM:SS.sss
There is no space reserved in the database for the timezone.
So the general solution might be that the date that you store in the
database is always in the timezone of the (database) server. (And it makes
a lot of sense to have database server and application server in the same
timezone).
If you mix the date/times in your database to store some in UTC and some in
local time, simply queries might just return wrong values as the database
does not know that it needs to consider the timezone different between
certain fields.
So I am not saying that nobody might save the dateTime in GTM or UTC in a
database but whom-ever does it might create more issues then solving.
I have seen a couple of such things, for instance in the PHP world it seems
quite common that you convert everything into milliseconds since 1970
instead of using appropriate date/time database fields :)))
Just my 2 Cents :)
Sebastian
2013/8/10 Sebastien <se...@gmail.com>
> 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, seba.wagner@gmail.com <
> seba.wagner@gmail.com> 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
>>
>>
>>
--
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com
Re: Pull request to jquery-wicket-ui for fixing some API to be customizable
Posted by Sebastien <se...@gmail.com>.
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, seba.wagner@gmail.com <
seba.wagner@gmail.com> 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
>
>
>
Re: Pull request to jquery-wicket-ui for fixing some API to be customizable
Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
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 seba.wagner@gmail.com <se...@gmail.com>
> 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 <so...@gmail.com>
>
>> Thanks!
>> Will look through our code
>>
>>
>> On Mon, Aug 5, 2013 at 2:31 PM, Sebastien <se...@gmail.com> 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 <so...@gmail.com>wrote:
>>>
>>>> Found the new build!
>>>> Thanks! going to test it today and report back :)
>>>>
>>>>
>>>> On Mon, Aug 5, 2013 at 3:57 AM, Sebastien <se...@gmail.com> 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 <solomax666@gmail.com
>>>>> > 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: seba.wagner@gmail.com <se...@gmail.com>
>>>>>> 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 <de...@openmeetings.apache.org>
>>>>>>
>>>>>>
>>>>>> 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 <so...@gmail.com>
>>>>>>
>>>>>> > 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, seba.wagner@gmail.com <
>>>>>> > seba.wagner@gmail.com
>>>>>> > > 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 seba.wagner@gmail.com <se...@gmail.com>
>>>>>> > >
>>>>>> > > > 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 <so...@gmail.com>
>>>>>> > > >
>>>>>> > > >> 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, seba.wagner@gmail.com <
>>>>>> > > >> seba.wagner@gmail.com
>>>>>> > > >> > 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
>>>>>> > > >> > seba.wagner@gmail.com
>>>>>> > > >> >
>>>>>> > > >>
>>>>>> > > >>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> 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
> seba.wagner@gmail.com
>
--
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com
Re: Pull request to jquery-wicket-ui for fixing some API to be customizable
Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
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 <so...@gmail.com>
> Thanks!
> Will look through our code
>
>
> On Mon, Aug 5, 2013 at 2:31 PM, Sebastien <se...@gmail.com> 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 <so...@gmail.com>wrote:
>>
>>> Found the new build!
>>> Thanks! going to test it today and report back :)
>>>
>>>
>>> On Mon, Aug 5, 2013 at 3:57 AM, Sebastien <se...@gmail.com> 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 <so...@gmail.com>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: seba.wagner@gmail.com <se...@gmail.com>
>>>>> 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 <de...@openmeetings.apache.org>
>>>>>
>>>>>
>>>>> 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 <so...@gmail.com>
>>>>>
>>>>> > 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, seba.wagner@gmail.com <
>>>>> > seba.wagner@gmail.com
>>>>> > > 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 seba.wagner@gmail.com <se...@gmail.com>
>>>>> > >
>>>>> > > > 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 <so...@gmail.com>
>>>>> > > >
>>>>> > > >> 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, seba.wagner@gmail.com <
>>>>> > > >> seba.wagner@gmail.com
>>>>> > > >> > 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
>>>>> > > >> > seba.wagner@gmail.com
>>>>> > > >> >
>>>>> > > >>
>>>>> > > >>
>>>>>
>>>>
>>>
>>>
>>> --
>>> 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
seba.wagner@gmail.com
Re: Pull request to jquery-wicket-ui for fixing some API to be customizable
Posted by Maxim Solodovnik <so...@gmail.com>.
Thanks!
Will look through our code
On Mon, Aug 5, 2013 at 2:31 PM, Sebastien <se...@gmail.com> 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 <so...@gmail.com>wrote:
>
>> Found the new build!
>> Thanks! going to test it today and report back :)
>>
>>
>> On Mon, Aug 5, 2013 at 3:57 AM, Sebastien <se...@gmail.com> 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 <so...@gmail.com>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: seba.wagner@gmail.com <se...@gmail.com>
>>>> 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 <de...@openmeetings.apache.org>
>>>>
>>>>
>>>> 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 <so...@gmail.com>
>>>>
>>>> > 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, seba.wagner@gmail.com <
>>>> > seba.wagner@gmail.com
>>>> > > 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 seba.wagner@gmail.com <se...@gmail.com>
>>>> > >
>>>> > > > 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 <so...@gmail.com>
>>>> > > >
>>>> > > >> 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, seba.wagner@gmail.com <
>>>> > > >> seba.wagner@gmail.com
>>>> > > >> > 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
>>>> > > >> > seba.wagner@gmail.com
>>>> > > >> >
>>>> > > >>
>>>> > > >>
>>>>
>>>
>>
>>
>> --
>> WBR
>> Maxim aka solomax
>>
>
>
--
WBR
Maxim aka solomax
Re: Pull request to jquery-wicket-ui for fixing some API to be customizable
Posted by Sebastien <se...@gmail.com>.
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 <so...@gmail.com>wrote:
> Found the new build!
> Thanks! going to test it today and report back :)
>
>
> On Mon, Aug 5, 2013 at 3:57 AM, Sebastien <se...@gmail.com> 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 <so...@gmail.com>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: seba.wagner@gmail.com <se...@gmail.com>
>>> 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 <de...@openmeetings.apache.org>
>>>
>>>
>>> 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 <so...@gmail.com>
>>>
>>> > 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, seba.wagner@gmail.com <
>>> > seba.wagner@gmail.com
>>> > > 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 seba.wagner@gmail.com <se...@gmail.com>
>>> > >
>>> > > > 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 <so...@gmail.com>
>>> > > >
>>> > > >> 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, seba.wagner@gmail.com <
>>> > > >> seba.wagner@gmail.com
>>> > > >> > 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
>>> > > >> > seba.wagner@gmail.com
>>> > > >> >
>>> > > >>
>>> > > >>
>>>
>>
>
>
> --
> WBR
> Maxim aka solomax
>
Re: Pull request to jquery-wicket-ui for fixing some API to be customizable
Posted by Maxim Solodovnik <so...@gmail.com>.
Found the new build!
Thanks! going to test it today and report back :)
On Mon, Aug 5, 2013 at 3:57 AM, Sebastien <se...@gmail.com> 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 <so...@gmail.com>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: seba.wagner@gmail.com <se...@gmail.com>
>> 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 <de...@openmeetings.apache.org>
>>
>>
>> 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 <so...@gmail.com>
>>
>> > 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, seba.wagner@gmail.com <
>> > seba.wagner@gmail.com
>> > > 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 seba.wagner@gmail.com <se...@gmail.com>
>> > >
>> > > > 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 <so...@gmail.com>
>> > > >
>> > > >> 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, seba.wagner@gmail.com <
>> > > >> seba.wagner@gmail.com
>> > > >> > 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
>> > > >> > seba.wagner@gmail.com
>> > > >> >
>> > > >>
>> > > >>
>>
>
--
WBR
Maxim aka solomax
Re: Pull request to jquery-wicket-ui for fixing some API to be customizable
Posted by Sebastien <se...@gmail.com>.
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 <so...@gmail.com>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: seba.wagner@gmail.com <se...@gmail.com>
> 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 <de...@openmeetings.apache.org>
>
>
> 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 <so...@gmail.com>
>
> > 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, seba.wagner@gmail.com <
> > seba.wagner@gmail.com
> > > 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 seba.wagner@gmail.com <se...@gmail.com>
> > >
> > > > 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 <so...@gmail.com>
> > > >
> > > >> 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, seba.wagner@gmail.com <
> > > >> seba.wagner@gmail.com
> > > >> > 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
> > > >> > seba.wagner@gmail.com
> > > >> >
> > > >>
> > > >>
>
Fwd: Pull request to jquery-wicket-ui for fixing some API to be customizable
Posted by Maxim Solodovnik <so...@gmail.com>.
Dear Sebastien,
could you please take a look at
https://github.com/sebfz1/wicket-jquery-ui/pull/52 ?
Thanks in advance!
---------- Forwarded message ----------
From: seba.wagner@gmail.com <se...@gmail.com>
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 <de...@openmeetings.apache.org>
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 <so...@gmail.com>
> 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, seba.wagner@gmail.com <
> seba.wagner@gmail.com
> > 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 seba.wagner@gmail.com <se...@gmail.com>
> >
> > > 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 <so...@gmail.com>
> > >
> > >> 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, seba.wagner@gmail.com <
> > >> seba.wagner@gmail.com
> > >> > 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
> > >> > seba.wagner@gmail.com
> > >> >
> > >>
> > >>
> > >>
> > >> --
> > >> WBR
> > >> Maxim aka solomax
> > >>
> > >
> > >
> > >
> > > --
> > > Sebastian Wagner
> > > https://twitter.com/#!/dead_lock
> > > http://www.webbase-design.de
> > > http://www.wagner-sebastian.com
> > > seba.wagner@gmail.com
> > >
> >
> >
> >
> > --
> > Sebastian Wagner
> > https://twitter.com/#!/dead_lock
> > http://www.webbase-design.de
> > http://www.wagner-sebastian.com
> > seba.wagner@gmail.com
> >
>
>
>
> --
> WBR
> Maxim aka solomax
>
--
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com
--
WBR
Maxim aka solomax