On Thu, May 9, 2013 at 1:12 PM, Martin Grigorov <[email protected]> wrote:
> On Thu, May 9, 2013 at 9:45 PM, Igor Vaynberg <[email protected]>wrote:
>
>> On Thu, May 9, 2013 at 12:32 PM, Martin Grigorov <[email protected]>
>> wrote:
>> > On Thu, May 9, 2013 at 5:37 PM, Igor Vaynberg <[email protected]
>> >wrote:
>> >
>> >> we should write components that work with multiple types.
>> >>
>> >
>> > But this will mean that we will have to re-write it to javax.time for the
>> > version of Wicket that will use JDK 8.
>> > Your suggestion doesn't sound attractive to me anymore :-/
>>
>> no, it just means we *add* handling for javax.time types when they
>> become available.
>>
>
> having support for both joda and javax.time sounds a bit too much
>
> additionally https://issues.apache.org/jira/browse/WICKET-466 is since
> 2007. Everyone knows the issues with j.u.Date/Calendar.
> The fact that JDK development is slow doesn't mean that we should be slow
> too. It is 6 years since this request has been made. Isn't it time to drop
> support for j.u.Date/Calendar ?
there are a lot of issues with j.u.Date. no one here is going to
dispute that. but, even with all these issues it is still a widely
used class, and will continue to be long after jdk8 is released.
i do not care if internally wicket used joda or anything else to
represent time. we can encapsulate whatever mechanism we want. but,
externally we should support j.u.Date as well as joda, etc.
for example, jpa codebases which need to be portable or jee apps can
only map j.u/s.Date and j.s.Timestamp because those are the only
temporal types jpa has support for. if we do not support these
directly then the users will either have to convert their domain to
perform conversion in getters/setters or use a model adapter to bind
to those types. either way, its a hassle, especially since its really
easy for us to support these types directly.
-igor
>
>
>>
>> >>
>> >> for example this is what code of a DateLabel might look like:
>> >>
>> >> @Override
>> >> public void onComponentTagBody(MarkupStream markupStream, ComponentTag
>> >> openTag) {
>> >>
>> >> String body = "";
>> >> Object date = getDefaultModelObject();
>> >> if (date != null) {
>> >> if (date instanceof ReadablePartial) { body = ... }
>> >> else if (date instanceof ReadableInstant) { body = ... }
>> >> else if (date instanceof Date) { body = ...}
>> >> else if (date instanceof Timestamp) { body = ... }
>> >> else {
>> >> throw new IllegalStateException("Object of type :" +
>> >> date.getClass().getName() + " is not supported");
>> >> }
>> >> }
>> >> replaceComponentTagBody(markupStream, openTag, body);
>> >> }
>> >>
>> >> we are not using a converter because DateLabel carries a format string
>> >> as a property.
>> >>
>> >> such a component is convenient because you dont need to worry if you
>> >> are using it with older api that has Date or a newer one that has Joda
>> >>
>> >> we cannot go solely on threeten because version 1.0 is not coming
>> >> until jdk8 and only with jdk8.
>> >>
>> >
>> > I don't get the "only with jdk8" part.
>> >
>> http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.threeten%22%20AND%20a%3A%22threetenbp%22
>> > threetenbp is the backport for JDK 7. It is version 0.8.1 at the moment
>> so
>> > API changes may be expected, but it can be used now.
>>
>> right. but can we have a production version with a pre 1.0 dependency?
>> as far as semver goes pre 1.0 is the wild west - anything can change.
>> i think thats a bit dicy. and even if we do that, we should still
>> suport java.util.Date and java.sql.Timestamp. these types are in wide
>> use currently and will be for a while.
>>
>> -igor
>>
>>
>> >
>> >
>> >>
>> >> -igor
>> >>
>> >> On Thu, May 9, 2013 at 12:03 AM, Martin Grigorov <[email protected]>
>> >> wrote:
>> >> > Hi Dan,
>> >> >
>> >> > I have no much experience with this matter so I cannot help much.
>> >> >
>> >> > The new Joda-Time is http://threeten.github.io/
>> >> >
>> >> > Question to other devs: do you think it is OK to migrate
>> wicket-datetime
>> >> > module to JDK 1.7 version of ThreeTen for Wicket 7 ?
>> >> > I find this task interesting to me so I'll gladly work on it if other
>> >> devs
>> >> > think that the API break is worth it.
>> >> >
>> >> >
>> >> >
>> >> > On Thu, May 9, 2013 at 12:46 AM, Dan Retzlaff <[email protected]>
>> >> wrote:
>> >> >
>> >> >> Hi all,
>> >> >>
>> >> >> I'd like to know what conventions you've established for your sites
>> that
>> >> >> deal with users in many time zones.
>> >> >>
>> >> >> Do you simply replace the converters (Date, SqlDate, SqlTime,
>> >> >> SqlTimestamp)?
>> >> >>
>> >> >> Do you avoid MessageFormats in StringResourceModels? (I don't see a
>> way
>> >> to
>> >> >> configure its MessageFormat.)
>> >> >>
>> >> >> We currently bypass this stuff and do our formatting with application
>> >> >> utility methods, and adapting input into users' timezones as manual
>> >> steps,
>> >> >> e.g. with Joda-Time's DateTime#withZoneRetainFields().
>> >> >>
>> >> >> I'd like to sweep this stuff under the rug with some
>> application-level
>> >> >> configuration, e.g. of converters. But before I embark, I was hoping
>> to
>> >> >> hear from someone who's already gone on this journey.
>> >> >>
>> >> >> And related: maybe you have some golden rules time zone handling to
>> >> share?
>> >> >> A couple of mine are:
>> >> >> 1. Avoid "date" types in SQL tables because it's hard to correctly
>> >> compare
>> >> >> to "now" across timezones.
>> >> >> 2. Anything that shifts millis to adjust for timezones is a red flag
>> >> >> (including the aforementioned #withZoneRetainFields() sadly).
>> >> >> 3. java.util.Date is evil and you should avoid it whenever possible.
>> >> >> Calendar is marginally better, but Joda-Time is the way to go.
>> >> >>
>> >> >> Thanks,
>> >> >> Dan
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Martin Grigorov
>> >> > Wicket Training & Consulting
>> >> > http://jWeekend.com <http://jweekend.com/>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [email protected]
>> >> For additional commands, e-mail: [email protected]
>> >>
>> >>
>> >
>> >
>> > --
>> > Martin Grigorov
>> > Wicket Training & Consulting
>> > http://jWeekend.com <http://jweekend.com/>
>>
>
>
>
> --
> Martin Grigorov
> Wicket Training & Consulting
> http://jWeekend.com <http://jweekend.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
