Re: Pull request to jquery-wicket-ui for fixing some API to be customizable

[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

[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

["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