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 :-/
>
> 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.
>
> -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/>
